Jev is a new kind of model that returns a confidence number instead of text, which makes it fast and cheap for classification tasks. I think it's genuinely useful, but a number alone doesn't tell you why something was flagged, and any process where a wrong call is expensive still needs a human checkpoint behind that score, not instead of it.
A new model came out last week called Jev that doesn't write text back to you at all. You give it a document and a question, and it hands you a floating point number: how confident it is that something is true, which option out of a list is right, or where something sits on a scale you define. It's fast and it's cheap, and I think it's a genuinely useful shape of model. I also think it makes the hardest part of my job easier to skip past, which is the part where you decide what to do when the machine isn't sure.
What Jev actually does
Simon Willison wrote it up well: you send Jev a piece of text or a structured record, plus one or more questions, and it comes back with numbers instead of sentences. A yes/no statement gets a confidence between 0 and 1. A multiple choice question gets a probability across the options. A rating scale gets a score somewhere along the range you defined. No explanation, no reasoning, just the number. Because there's no text generation happening, it's much faster and much cheaper than a normal large language model doing the same job, and you can throw dozens of questions at one document in parallel.
That's a good fit for anything that's really a classification task in disguise. Spam detection, tagging support tickets, ranking search results, deciding which of a hundred candidates deserves a closer look. I read the piece thinking about the automations I've actually built, and the honest answer is that a lot of what I do already boils down to exactly this kind of question. Is this message a complaint. Is this a genuine appointment request. Does this document look like an invoice from a supplier we already recognise. I just never had a model that was purpose built to answer only that question, cheaply, at volume.
Where I've already been asking this question
When I built invoice reading for Vimal Electric Corporation, the distribution business I run, the hard part was never reading the text off the page. It was deciding when to trust what got read. Every supplier lays their invoice out differently. A lot of copies come in as scans or phone photos, not clean PDFs, and once the numbers are extracted they still need to land correctly in our own system, which is its own separate piece of work. The rule I settled on was simple: if the automation isn't confident it read something correctly, it doesn't guess, it flags the invoice for a person to look at. An automation that quietly enters the wrong amount is worse than one that asks for help, because nobody notices the wrong entry until it's already caused a problem downstream.
That rule is exactly the kind of thing Jev is built to power. Instead of me writing my own rough confidence heuristic, I could ask a model directly whether it's confident that a figure on an invoice is the total amount due, get back a number, and route anything below a threshold to a person. On paper that's an upgrade. In practice, the number Jev gives you is still a black box. It tells you it's confident or it isn't, but not which part of the invoice made it uncertain, not whether the scan was blurry or the supplier used a layout it hadn't seen before. My rule for invoices was never really about generating a confidence score in the first place. It was about building a habit of not trusting the machine blindly, and a slicker score doesn't replace that habit, it just makes it easier to forget you still need it.
The black box problem is the whole point, not a footnote
Willison raises this directly in his post: Jev is even more of a black box than a normal language model. At least with a regular model you can ask it to explain itself, even if you can't fully trust the explanation. With Jev, you put in all the text you want and you get back a number and nothing else. If it marks something as spam, or scores a candidate low, you have no way to ask it why. He mentions running an experiment where he asked it to rate whether cities were
good places, out of curiosity, and got results he found strange and unexplainable. That's a fun example on cities. It stops being fun the moment someone uses the same kind of scoring to shortlist job applicants, or to decide which customer complaint gets escalated and which one doesn't. A number with no reasoning attached hides whatever bias went into producing it, and you can't interrogate a float.
What I'd actually check before using something like this
If I were plugging a decision model like Jev into a client's workflow, here's what I'd want settled before it touched anything that mattered.
- What happens to anything that scores near the threshold, not just clearly high or clearly low
- Whether a person ever sees the borderline cases, or whether the system just picks a side and moves on
- Whether the cost of a wrong call is a minor inconvenience or something a customer notices
- How often someone actually reviews what got flagged, not just whether a review step exists on paper
- Whether the scoring criteria get revisited as the business changes, or just left running
That last one matters because it's the same discipline I already apply to anything live. Every month I check the failure logs on automations I run, whether logins or APIs have changed underneath me, whether volume and running cost have shifted, and what the people using the system are asking for next. A decision model doesn't remove that routine. It just adds one more thing that can quietly drift without anyone noticing, because a wrong number doesn't announce itself the way a broken workflow does.
Cheap and fast changes the temptation, not the risk
What worries me slightly about Jev isn't the model itself, it's the price. When something is this cheap to run, it's cheap enough to skip the step where you ask whether you should be running it at all. I still start every new automation the same way: a call to map how the process actually gets done today, by the people doing it, then one small first version that's running within days so real use can answer questions a meeting never will. A model that returns confidence scores instead of paragraphs fits neatly into that first version. It doesn't replace the part where someone decides what the threshold is, what happens below it, and who's accountable when the number is wrong.
