TL;DR
- Jev is a classifier and scorer. State and typed questions in; a yes/no, a label from a set you declared, or a score on a short rubric, each with a probability. It cannot produce a sentence.
- The value is the gate: auto-act above a threshold, escalate the rest. On closed tickets I auto-accepted 77% of answers at 97% accuracy. Language-model
confidencefields do not give you this. - Use it when the step is already a closed set, a miss is cheap, and the option set contains only moves that can still change the state. Leave it for prose, a soft rubric, leftover UI controls, or a decision you need to explain in sentences.
- Type safety is not correctness. Jev cannot invent a fifth option. It can still pick the wrong one of the four.
- The architecture is a cascade: Jev judges, code acts, a language model or a human takes the low-confidence remainder.
I sent TypeSafe's Jev a support ticket and three typed questions. It answered in 409 milliseconds and billed $0.000018. It did not write a word.
That is the interface. TypeSafe launched Jev as the first of what it calls System One models — its name for fast, structured decisions, after Kahneman's System 1. Unstructured state in, typed probabilistic decisions out. Software does not want a paragraph. Software wants a value it can branch on.
I already wrote that most agent steps do not need a frontier model. That post still assumed the step was generation — a smaller language model, forced into JSON. The harness is where the margin lives removed the model from a loop entirely. Jev is a third option on that same axis: keep a model, change the interface. The step becomes what it always was: a classification.
What I actually called
I called it through OpenRouter, not chat/completions. The model slug ~typesafe/jev-latest resolved to typesafe/jev-1.13-20260917.
State:
Help! My payouts have been failing for 3 days and I am losing sales. Please help now.
Questions: is this urgent (noul), which team (choice: billing / technical / general), how frustrated (score: Calm / Frustrated / Very angry).
| Question | Answer |
|---|---|
is_urgent |
0.98 |
department |
billing, probability 1.00, confidence 0.99 |
frustration |
1.23 — 76% Frustrated, 24% Very angry, confidence 0.65 |
Probability is the share of mass on that option. Confidence is how peaked the distribution is. A 1.00 probability with 0.99 confidence is a single spike. Frustration at 1.23 with 0.65 confidence is a split between two adjacent labels.
432 input tokens, 73 output tokens, 409 ms. One request, three answers in parallel. No prose to parse.
A language model can be coerced into the same JSON. The difference is the contract. Jev cannot return "please escalate to finance-ops" when the options were billing, technical, and general. TypeSafe's API treats that as a type error it cannot emit.
Three primitives, not a chat surface
Every Jev question is one of three shapes. TypeSafe documents them as Noul, Choice, and Score.
| Primitive | Ordinary name | Returns |
|---|---|---|
noul |
Binary classifier | P(yes) between 0 and 1 |
choice |
Multiclass classifier | One of up to 255 declared options, plus a distribution and a confidence |
score |
Ordinal classifier | A value on a 2–10 rubric, plus a distribution and a confidence |
Noul is TypeSafe's word for a yes/no proposition. The name is a coinage, not a typo.
The label set is yours, per request. This is not a frozen topic model that only knows billing and spam. You hand it this ticket and these three teams. Next request, a different state and a different enum.
That is also the limit. If the right answer is not in the list, Jev will still pick something on the list. Schema matching is guaranteed. Semantic correctness is not. TypeSafe is explicit: calibration is measured across groups of predictions. It does not guarantee that one answer is correct.
The number is the product
The value is not "almost as accurate, much cheaper." Plenty of small models can say that. The thing you cannot buy from a language model is a probability that is low when the answer is wrong.
On route, refund policy, and next-tool — closed sets with written options — that number behaved like a gate. At 0.70 I would have auto-accepted 34 of 44 labeled answers and been right on 33. Coverage 77%. Auto accuracy 97%. Seven of the eight misses sat below the gate. The one high-confidence miss was a hole in my labels: a quote request, gold other, prediction billing. TypeSafe already tells you to add an other.
Ben Greenberg saw the same shape on 306 policy decisions: Jev's Choice-alone errors sat at 0.2–0.3, Claude Sonnet 5's at 0.9–1.0. Laurie Voss makes the complementary point: a language model's verbalized confidence stays high whether it is right or not, and Jev's number does not tell you how to fix the system.
A language model's self-reported confidence field did not give me a gate. On the same tickets, misses did not sit low. Threshold Jev. Do not threshold the paragraph that says it is sure.
I will not cite TypeSafe's 193× / 445× peak. Those are their harness. On my closed slice Jev was 28× cheaper than Terra and 47× cheaper than Sonnet 5. Directionally the same bet: the expensive model is a luxury tax on an enum.
The cascade
state + typed questions
|
v
Jev
|
+-- high confidence --> code acts
|
+-- low confidence --> language model, or a human
Code keeps arithmetic, permissions, and side effects. Jev supplies the semantic judgment. A language model writes, plans, and handles the open remainder.
Ask the whole question as one Choice. Use Nouls to explain or to gate, not to reconstruct the decision. Greenberg tried the homemade-judge version: Choice alone was 99.3%; Choice plus diagnostic Nouls was 100%; the Nouls stacked as a final judge were worse.
Browser Use's Jev Ultrafast is the cascade in public: Jev picks the operation and the element, a small language model types only when the operation is type. The rule that makes it work is the same rule that kills the value when you skip it — only supported operations and empty targets are offered.
Where the value dies
The number is only useful if the question is honest.
A soft rubric is not a Jev job. A three-level "how good is this reply" score was 50–58% for every model I ran. Until the levels are as crisp as allow / deny / insufficient, you are not buying a gate. You are buying a coin flip with extra steps.
A dirty option set is the other way the value dies. Leave a filled username in the Choice and Jev will type it again, at high confidence. Leave a cart icon next to Add to cart and it will open the empty cart. Chrome, here, means leftover UI: controls that cannot progress the goal. The 0.70 gate from the tickets would have auto-accepted both loops. The cheap judge became an expensive no-op.
TypeSafe's jaggedness page for jev-1.13 lists arithmetic, dates, and prompt injection as failures. Most of those did not reproduce on the ten probes I tried. The one that did: instructions that fight the criteria. Jev answered the question. The language models answered the criteria. Send both in the same direction. Keep arithmetic and retrieval in code either way.
Jev belongs on a step when all four are true: the output is already a closed set, a miss is cheap to undo, you need a number you can threshold, and the option set contains only moves that can still change the state.
It does not belong when the answer is prose, the rubric is soft, the Choice still contains chrome, a wrong pick is expensive, or you need an audit trail in sentences.
So what
If you work on agents, a large share of the bill is not writing. It is choosing. Which tool. Whether to retry. Whether this output passed. Those calls are currently priced as if they were essays.
Jev is a bet that those calls should look like functions: a typed answer, a number, a branch. That bet is right for the high-volume, reversible, closed-set layer. It is worth nothing on a step that still needs language, or on a Choice you have not cleaned.
The remaining question is not whether Jev can return a probability. It is whether the enum you hand it is small enough that the number still means something.
Top comments (0)