Jev: The LLM That Doesn't Write, It Just Decides
Takes input like an LLM, answers like a classifier. It takes over the spots where we made LLMs act as if statements
If you've ever asked an LLM "Is this inquiry about billing or a bug? Answer in JSON", that's exactly the spot Jev is going after. Jev doesn't write text at all. It returns a probability for each choice you define. By the end you'll be able to pick which AI calls in your service could move to a decision-only model like this.
TypeSafe AI released it on 2026-09-15 and calls it a "System One Model": it only does the fast, intuitive kind of choosing (System 1).
LLM on the way in, classifier on the way out
input plain-language situation + program state + list of choices
output probability per choice {"approve": 0.91, "reject": 0.06, "escalate": 0.03}
It gave up on generating strings, so the types can't break. The official post says it's trained with RLCD (Reinforcement Learning for Calibrated Decisions), so the probabilities are calibrated. Calibrated means that when it says 0.9, it's right about nine times out of ten.
From the user's side it felt close to "a BERT that needs no training". That's not a claim about its internals. The post only says it's a new architecture and gives no details. It's how it feels to use.
Next to BERT and LLMs
| BERT-style classifier | LLM (structured output) | Jev | |
|---|---|---|---|
| Training per task | Required (fine-tuning) | Not needed | Not needed |
| When choices are set | Fixed at training time | In the prompt | Freely, per call |
| Output | Label probabilities | Text (JSON), sometimes broken | Typed value + probabilities |
| Trust in probabilities | Tends to be overconfident | Practically none | Claimed calibrated |
| Explains why | No | Yes | No |
| Latency | Very fast | Seconds | 70 to 500ms (official) |
| Cost | Self-hosted | Output tokens are pricey | Input $0.042 per 1M tokens, output free (official) |
Prices are from the official post. The authors themselves write that they can't prove it isn't subsidized, so I wouldn't count on these numbers lasting.
The real point: it can say "not sure"
This matters more than speed. If the probabilities are trustworthy, a threshold splits the work three ways.
case answer['confidence']
when 0.9.. then auto_apply!(answer['choice']) # apply automatically
when 0.5...0.9 then flag_for_review!(answer) # a human confirms
else escalate_to_human! # hand off to a human (or an LLM)
end
Set thresholds by the cost of being wrong. Read-only actions can go lower. Delete, charge or send stays at 0.9 or above. Never design it so everything auto-applies. When I wrote usage rules for wiring this into our code, that was the first line.
Where it fits and where it doesn't
Use it for: model routing (easy jobs to the cheap model, hard ones to the expensive one), UI automation (give it the button list, get a probability per button), natural-language checks you gave up on with regex, bulk classification like sorting inquiries.
Skip it for: work that needs a written reason (it gives none), image input (text only for now), more than 255 choices (the direct-choice limit).
Chrome's built-in LLM was "assist only, in the browser" (Chrome's built-in LLM is not a free API). Jev sits on the other side: on the server, doing the deciding itself, fast and cheap.
What I haven't verified
I haven't measured accuracy or calibration on my own data. Whether the 0.9 bucket really hits 90% (a reliability diagram), and how it compares with LLM structured output on speed, cost and accuracy for the same task, gets added once I've measured. Until then, the latency, price and calibration in the table are all official claims.
If you're running classification or routing through an LLM and the cost or latency hurts, feel free to ask negabaro. We can sort out together which calls move to a decision-only model and which stay with the LLM.
Key Concepts
Find AI calls whose answer is "one of a fixed set of choices". Those are the candidates
Define the choices at call time. No training needed
Split by confidence threshold into auto-apply, human check and hand-off
Match thresholds to the damage a wrong answer causes
Pros
- ✓ Output types can't break. It never generates strings
- ✓ Probabilities let it say "not sure", which makes hand-off designs easy
Cons
- ✗ No reasons, so it can't serve work that needs an audit trail
- ✗ Text only, choices capped at 255
- ✗ Latency, price and calibration are still official claims, not yet verified by me