Your agent asks a big language model dozens of small questions before it gives the user one answer. Is this request urgent? Is this tool call safe? Does this need the expensive model or the cheap one? Each answer is one word, and you still wait while the model writes it out, one piece at a time.
Jev is a model built for exactly those questions. TypeSafe AI released it this month, and it does not write text at all. You give it a question and the list of allowed answers, and it gives back a pick with a probability. It is much faster and much cheaper than an LLM on this kind of work, and LangChain, Pydantic and Cloudflare all added support for it within days.
So it’s worth understanding what it actually does inside, and where it will hurt you.
Fast Thinking for Software
The name “System One” comes from Daniel Kahneman’s book Thinking, Fast and Slow. System One is the fast, automatic part of your mind. You see a face and you know it is angry, without reasoning your way there. System Two is the slow part that does long division and plans a trip.
LLMs are System Two machines. They build every answer piece by piece, and they are good at long, open work: writing code, explaining, planning. TypeSafe’s bet is that most of what an agent does between those long tasks is System One work. Classify this ticket. Route that request. Block or allow the command. For that work, a text generator is the wrong shape of tool.
The name Jev comes from William Stanley Jevons, the economist who noticed that when steam engines started burning less coal per job, the world ended up burning more coal in total. TypeSafe’s argument is the same. Make a decision much cheaper, and people will put decisions in places they never would before.
The Triage Nurse and the Doctor
Think about an emergency room. The triage nurse sees every patient first and decides fast: how urgent, which department, wait or go in now. The doctor comes later and works out the real diagnosis, which takes much longer.
You would never ask the doctor to do triage for every person at the door. It is slow and expensive, and the doctor’s skill is wasted on a question with a handful of possible answers. Jev is the triage nurse of your agent. The LLM stays the doctor.
The analogy breaks at one important point. A good nurse knows when a case does not fit any category and calls for help. Jev does not. When the right answer is not on your list, it still picks one, and often with high confidence. The algorithm below shows exactly why.
How an LLM Answers a Question
To see what Jev changes, start with how an LLM answers “is this ticket urgent?”.
The LLM runs a loop. It reads your prompt and everything it has written so far, and it predicts the next token, a small piece of a word. It adds that token to the text. Then it reads everything again and predicts the next one. It repeats this until it decides the answer is finished.
Two things follow from that loop. Every step has to wait for the step before it, so a longer answer always takes longer. And many models write a block of reasoning before the answer, so even a one-word decision can cost a paragraph of loops. You pay for all of that, for a word you already knew was going to be “yes” or “no”.
How Jev Answers the Same Question
Jev has no loop. Its algorithm, at a high level, looks like this.
Step one: you close the answer space. Before anything runs, you define the question and every allowed answer. “Which department: billing, technical, or other?” The model can only ever answer from that list. This is the part you design, and it is where most of your quality comes from.
Step two: one read. Jev reads the context, which TypeSafe calls the state, together with your question and the list of answers. It reads all of it at once. It never writes anything back.
Step three: score every answer at the same time. Each allowed answer gets a score for how well it fits the state. The answers do not compete in sequence. They are all scored in the same pass.
Step four: turn scores into a distribution. The scores become probabilities that add up to a whole, spread across your answers. The pick is the answer with the most weight.
Step five: measure confidence. Confidence is how concentrated that distribution is. If almost all the weight sits on one answer, confidence is high. If the weight is spread over two or three answers, confidence is low, even when there is still a top pick.
That is the whole difference between an essay and a multiple-choice sheet. The LLM writes its way to an answer. Jev looks at all the boxes and says how strongly each one should be ticked.
TypeSafe has not published Jev’s architecture. Open models built on the same idea do it like this: an encoder reads the whole input at once, each answer choice gets its own marker inside the input, and the model scores the markers. That is how the idea works in general, and it may differ from what TypeSafe built.
Three Question Shapes
Every Jev question is a variation of that same algorithm.
A Choice question is the algorithm exactly as above. You get the pick, the full distribution, and the confidence.
A Noul question is a yes-or-no question. It is a choice between two answers, reported as one probability: how likely the answer is “yes”.
A Score question uses ordered levels, like low, medium and high. Here the order matters, so Jev does one more step. It takes the average of the levels, weighted by the probability of each one. If the model is torn between medium and high, the score lands between them. That gives you a smooth rating instead of a hard jump from one level to the next.
You can ask many questions about the same state in one call, and Jev scores all of them in parallel. Asking about urgency, department and customer mood together costs about the same wait as asking one.
This design also explains the claim that Jev “can’t hallucinate”. The model can only put weight on answers you listed, so it can never return a broken type or an answer from outside your list. That is a real guarantee, but a narrow one. A confident wrong pick from a valid list is still a wrong answer.
How It Learns to Be Honest
A probability is only useful if it means something. When Jev says it is fairly sure, it should be right about as often as “fairly sure” suggests.
Think of a good weather forecaster. On all the days they say rain is likely, it should in fact rain on most of them, and on the days they say it is unlikely, it mostly should not. A forecaster who says “likely” every day is useless even if they are sometimes right. This match between stated confidence and real outcomes is called calibration.
TypeSafe trains for it with a method it calls Reinforcement Learning for Calibrated Decisions, or RLCD. The model makes a decision with a probability. That probability is compared with what really happened. The model is rewarded when its confidence matches reality, and it loses reward both when it is too sure and when it is too timid. TypeSafe has not published the full details of how it does this.
When calibration works, you can put the probability straight into your code as a rule: act alone above some confidence, ask a human below it. That is the practical payoff of the whole design.
Where It Fits in Your Agent
Picture a coding agent on a normal workday. A developer asks it to rename a variable across the repo. Before real work starts, the agent has to decide whether this is simple or hard, and which model should handle it. Then it wants to run a shell command, and something has to decide if that command is safe. Then it produces a diff, and something has to check the diff against the team’s rules.
Every one of those is a Jev-shaped question.
Model routing. Ask Jev whether a request is simple or complex. Send simple ones to a small fast model and hard ones to your strongest model.
Tool-call gates. Before the agent runs a risky tool, ask a yes-or-no question: should this be blocked? It is cheap enough to leave on for every single call.
Evals at scale. Use Jev as a judge that scores every reply your system sends against your policy, instead of a small sample that a person reviews by hand.
Tagging big datasets. Huge piles of tickets or documents, where an LLM batch job would take hours and a real budget.
The rule is short. If you already know every possible answer before you ask, the question belongs to Jev. If the answer is text a person will read, it belongs to an LLM.
Where Jev Breaks
This is the section to read twice. Jev is very new, and the early independent tests found real limits. Each of them comes straight out of the algorithm.
It picks something even when nothing fits. In step four, the probabilities must add up to a whole across your answers. There is no hidden “none of these” slot. So a message that belongs to no category still gets all its weight pushed onto one of your answers. One independent tester sent messages that fit no category at all, and Jev answered them with near-total confidence anyway. Always add an escape answer like “other” or “not enough information”. Even then, do not assume it will choose it.
Its confidence is uneven. In the same tests, very high confidence was reliable. The middle range was not, and there Jev was right much less often than it claimed. Score questions came out worse calibrated than Choice or yes-or-no ones. Check the probabilities on your own data before you trust a threshold.
Text can steer it. In step two, Jev reads the whole state as information. It has no way to know which part came from you and which part an attacker planted. A security engineer asked Jev whether to block a command that deletes a user’s SSH keys, and it leaned toward blocking. Then the engineer added a fake tool output claiming the command was already approved, and the decision fell to about a coin flip. The fix is to keep tool outputs and fetched web content out of the state for safety decisions, so that text never gets a vote on what the agent runs next.
It reads literally. Jev answers exactly the question you wrote. Because the answer list is part of what it reads, even the order of your options can move the result. Write the conditions out in full, and keep the order fixed.
It cannot work things out. An LLM can write down intermediate steps and use them. Jev has one read and no place to write, so arithmetic, counting and comparing dates are outside what it can do. Compute those in normal code first, and give Jev the result.
For anything that matters, put deterministic checks and a human approval step behind Jev.
A First Jev Setup
Start where a mistake is cheap. Pick one decision your agent already makes with an LLM, like routing or ticket tagging. Save a few hundred real inputs together with the answers the LLM gave.
Run the same inputs through Jev, with an escape answer added. Compare the two sets of answers, and look hard at the cases where Jev was very confident and wrong. Those cases tell you more than any benchmark, because they come from your data.
For every call, keep a record of the state, the question, the option order, the model version and the confidence. Pin the model version so it does not change under you. When an answer shifts next month, you will want to know why.
Put a Nurse at the Door
Jev does not replace your LLM. It takes the small, repeated decisions off it, the way a hospital puts a triage nurse at the door so the doctor has time for the slow work.
That makes it one useful building block of a good agent, and only one. The harder part is still the system around it: which decisions you hand over, which checks sit behind them, and when a human has to look.
Anyone familiar with DMN! How about using that construct (with documented context around decision rules) to drive decisions?