Jev vs LLMs: when a decision model beats a text model

Sep 20, 2026 · 8 min read

On 15 September 2026 a company called TypeSafe AI released a model that cannot write a sentence. Jev does not generate text at all. You give it the state of your program and a set of typed questions, and it gives back an answer to each one with a probability attached. The whole exchange takes between 70 and 500 milliseconds.

That sounds like a step backwards until you look at what production AI actually spends its day doing. Much of that work is deciding rather than writing. Which queue does this ticket belong in. Is this message abusive. Is this invoice a duplicate. Should the agent be allowed to run this command. Every one of those has a fixed set of possible answers, and a text model that types out JSON one token at a time is an awkward way to get them.

What Jev actually is

TypeSafe calls it a System One model, after the fast and intuitive half of how people are said to think. The company was started about two years ago by Diogo Almeida, a former OpenAI researcher who worked on ChatGPT, with co-founders Erik Gafni and Sasha Sheng. The Register reports it has raised $40 million. Jev is in early access behind a waitlist, and the weights and architecture have not been published.

You can ask it three kinds of question. A Choice picks one option from a list of up to 255. A Score rates something against levels you define. A Noul returns the probability that a statement is true. Every answer comes back as a typed value with a confidence number, and every question in a request is answered together in one pass, so asking ten questions takes roughly as long as asking one.

It was trained only on synthetic data, using a method TypeSafe calls reinforcement learning for calibrated decisions. The stated goal is honest probabilities rather than answers a person would rate highly, which is what most chat models are tuned for.

How that differs from an LLM

• An LLM writes an answer. Jev selects one from a list you defined in advance.
• An LLM gives you text that you have to parse, and sometimes that text is malformed. Jev returns a value that cannot break the schema.
• An LLM runs one token at a time, so the longer the answer, the longer the wait. Jev answers everything in a single pass.
• An LLM's stated confidence is a number it wrote in a sentence. Jev returns a probability it was trained to calibrate.

The last point is the one developers keep mentioning. Nikhil Mudholkar, CTO of Bryo AI, compared the two on business email classification and found Gemini slightly more accurate but 10 to 20 times more expensive. His reason for choosing Jev was not speed. In his words, it is the only one that hands back a real probability, which makes it usable for automating a workflow.

The numbers, and what they actually compare

On its published evaluation, Jev matched the cheaper frontier model almost exactly, 67.8 against 67.9, while costing about one seventy-sixth as much per case and answering in 0.4 seconds instead of 10.1. The two larger reasoning models scored about six points higher and cost between 200 and 440 times more per case.

Three things are worth knowing before you quote those figures. The headline multiples of 193.6 times faster and 444.6 times cheaper are measured against the slowest and most expensive baseline in the set. Against the nearest frontier peer the gap is closer to 25 times faster and 76 times cheaper, which is still large but is a different claim.

Second, the answer key was not written by people. Reference labels came from averaging the responses of two other frontier models, so the first column measures agreement with a model consensus rather than verified correctness. Third, an average across four workflows hides the spread. On invoice processing Jev scored 61.8 while the comparison models scored 74.7 and 78.4.

Independent testing so far is small, and it points the same way on speed and price. One evaluation measured Jev at roughly 25 times faster and 580 times cheaper than Claude Fable 5.1 on extraction, and called the result good but not perfect. Nobody outside the company has reproduced the accuracy claims at scale yet, and the weights are not public, so the published tables are still the main source for most of these numbers.

What people are building with it

The first week of early access produced a useful set of examples. One developer triaged 1,700 emails for 18 cents. Another scanned a website for low-quality AI text in 243 milliseconds at a cost of about $0.00015 per check. A third drove a browser agent that completed every benchmark task at a fraction of the model cost of a frontier route.

Guardrails are turning into the most common use. Vercel replaced the model behind a safety classifier that checks commands, and engineer Pranit Sharma reported results five to eighteen times faster and more accurate than before. The same pattern covers checking a tool call before an agent runs it, spotting a jailbreak attempt in an input, and checking whether an answer is actually supported by the sources it cites.

The other strong fit is anything you run over a large pile of data. Classifying, scoring, ranking and extracting fields across millions of records is exactly the work where a fraction of a cent per decision changes what is affordable. TypeSafe's own documentation lists support ticket triage, financial crime alerts, insurance claims, product data cleanup, content moderation and candidate scoring among its examples.

There is also a category that simply was not possible before. At 70 milliseconds you can put a model inside a loop that runs ten times a second. The company's launch demo had Jev playing Doom, which is a stunt, but the point behind it is real. Software can now ask a model a question in the middle of a frame.

Where it is the wrong tool

Jev cannot write. That rules out anything a person will read, any code, and any written explanation of why a decision went the way it did. If you need an audit trail in sentences, you still need a language model to produce it.

• The set of answers has to be known in advance. Open-ended questions are out.
• A Choice tops out at 255 options. Above that there is a two-stage approach, and TypeSafe says it is slower.
• There is no thinking time to buy. A reasoning model can spend longer on a hard case; Jev answers in one pass either way, which caps how hard a problem it can take on.
• You still have to do the design work. Someone has to define the questions, the labels and the thresholds, and check the errors against real data from your own system.

About the claim that it cannot hallucinate

This is true in a narrow and useful sense, and misleading in a broad one. The guarantee is about shape. The output cannot fail to match the schema, so structured output errors and tool call errors go to zero. That is worth something real: in the same evaluation, one small frontier model returned invalid structured output 45.5 per cent of the time, and another produced tool call errors 17 per cent of the time.

It constrains the shape of the output. It does not constrain the judgment.

A wrong answer picked from a valid list is still a wrong answer. One engineer writing about the launch called the hallucination framing a semantic dodge for exactly this reason, and also pointed out that an ordinary LLM forced to emit a single token can capture some of the speed benefit without a new model at all. Both criticisms are fair, and neither one makes the cost difference go away.

The pattern that makes it work in production

The useful design puts a gate in front of the expensive path rather than swapping one model for a cheaper one. Ask the decision model first, act automatically on the confident answers, send the middle band to a bigger model, and put the genuinely uncertain cases in front of a person. If the probabilities are honest, you have just cut the volume reaching your expensive path by most of its size.

That whole design rests on calibration, which is also the claim with the least public evidence behind it. TypeSafe has not published calibration curves or reliability figures, and its own documentation tells you to test with your own data and adjust as you go. Treat the thresholds as something you measure, not something you inherit from a blog post.

What to take from it

Whether or not Jev in particular is the model you end up using, the split it draws is a good one to hold in your head. Deciding and writing are different jobs. Most teams have been paying frontier prices and waiting frontier seconds for both, because a chat model was the only tool on the shelf.

The practical exercise is to go through your own pipeline and mark every place a model is asked a question whose answers you could list on a whiteboard. Those are the decision points. If they are frequent, if they are on a path where latency matters, or if you skipped a check because it would have cost too much to run on everything, a model of this shape is worth a test. Everything that needs a sentence stays where it is.

That is roughly how we think about our own stack. Working out whether an answer covered a required point is a decision. Writing the report a person reads is not, and the two do not need the same model, the same cost, or the same amount of time.