Which queue. How urgent. Is this tool call safe. Does this answer break policy. Inside every production agent sit dozens of small, bounded decisions, and today each one goes to a frontier model that writes a paragraph you then parse. On 15 September 2026 a new model class arrived that answers typed questions with calibrated probabilities, in one pass, for a few thousandths of a cent. Six open-source clones followed within two days. Five independent teams have already measured whether the probabilities can be trusted. This is what they found, and what it changes for a technology leader this quarter.
TypeSafe AI's Jev is the first of what the company calls System One models. You send it a piece of state (a ticket, a tool call, a claim form) and a set of questions, each with a declared answer type: pick one of these options, score this on a rubric, or is this statement true. It returns a probability for every allowed answer to every question, all evaluated in parallel. It cannot produce text, and it cannot produce an answer outside the options you declared.
The agent asks a frontier model "is this ticket urgent?" and gets a paragraph back. Your code extracts the answer, hopes the format held, and has no honest measure of how sure the model was.
Seconds of latency, cents per call, a schema that breaks a few percent of the time.
Ten questions about the same ticket, one call, a probability distribution for each. Roughly a quarter of a second. Roughly two thousandths of a cent. The output cannot fall outside the schema.
Independent tests recorded zero type errors across more than 13,000 calls.
The bill and the latency budget of most agent systems are dominated by decisions that never needed a paragraph. Moving them to a model built for decisions is not a model swap. It is a new layer in the architecture, sitting between your code and the expensive generative model, and it changes what the expensive model is for.
The launch numbers (193x faster, 444x cheaper) come from the vendor's own workflows against its own wrapper, and the vendor says so. The claim your architecture actually depends on is narrower: when the model says 0.9, is it right about nine times in ten? If yes, you can set a threshold, automate above it, and send the rest to a person. If no, you have built an escalation path on sand.
| Independent test | Task | What it found |
|---|---|---|
| Agent tool-call risk | 60 tool calls labelled readonly, destructive, privileged or exfiltration, including disguised ones | 92% accurate. Never wrong when it said it was certain. Caught 11 of 12 disguised destructive calls. |
| Pre-registered intent test | Two public intent datasets, 150 and 77 classes | Well calibrated on one, systematically overconfident on the other. |
| Unseen support tickets | 900 generated tickets the model cannot have trained on | Strong on queue and sentiment. Near chance on a priority rule that was not in the text, while claiming 74% confidence. |
| Phishing shadow eval | 2,000 emails against Claude Haiku 4.5 | Lost badly when asked one question. Won when the judgment was split into five narrow questions combined in code. |
| Public leaderboard | 534 decisions, 42 systems | Jev leads. An open-weight clone on a 4B model trails by under one point. |
Calibration is real where the answer is in the text, and unreliable where it is not. On semantic judgments about content the model can see, the probabilities held up well enough to route on. On decisions that depend on your organisation's rules, it was confidently wrong. That is not a flaw to wait out. It is a design constraint: put the rule in the state or in the code, never in the model's imagination.
The phishing result is the most important number in this briefing. The same model on the same emails went from 62.6% to 95.0% accuracy, and from losing to a frontier model to matching it, with nothing changed except the questions. One fuzzy question became five narrow ones, and the answers were weighted in code by someone who understood phishing.
One question, one number, no idea what drove it. Accuracy is mediocre and the model's confidence on the answer means little because the question itself was ambiguous.
Python depth, team leadership, system design, each as its own score. Your engineers own the weights, can audit them, and can change them without touching a model. The senior judgment moves from the prompt into the decomposition.
This rewards a specific kind of engineer: the one who can turn a domain expert's instinct into a set of questions a machine can answer honestly. That is the human-plus-AI seam this whole tree is about. The model does not replace the person who knows what "urgent" means for your business. It makes their definition run at ten thousand decisions a second.
Within 48 hours of launch there were six open-source reproductions. Within a week a public leaderboard ranked 42 systems against the same call shape, and the best open-weight entry, a 4-billion-parameter model that runs on one GPU, sat under a point behind Jev. Nobody has reproduced TypeSafe's training method, because it is unpublished. Everybody has reproduced the interface.
Design for portability from day one. Keep the call shape (state, questions, probabilities) as your internal contract. Keep thresholds and weights in your code, not in a vendor console. Keep an open-weight clone in the cascade as the backstop, the same spare-generator logic this tree applies to every rented model. TypeSafe's own launch post says it "cannot prove" the price is unsubsidised. Plan as if it is.
If you have a fixed label set and thousands of labelled historical decisions, a small fine-tuned encoder running on CPU will be cheaper and probably more accurate on your own labels. The System One model earns its place where labels shift, where you have no history, where you need many questions at once, or where the calibrated probability is the product. Do not rip out a working classifier to adopt a category.
The decisions that make or break service businesses here are exactly this shape: which adviser, is this claim complete, is this the document we asked for, does this message need a person today. At list price a decision costs a few hundredths of a cent in rand. The whole shadow evaluation your team should run first costs less than a coffee.
Send the fields the question needs, not the customer record. The vendor recommends it for accuracy; POPIA requires it for a US-hosted API. The same design serves both. Where the state cannot be reduced to non-personal fields, run the open-weight clone in-country.
Replay a month of decisions your people already made. Measure accuracy and calibration per question, not per model, because yes/no questions ran underconfident and multiple-choice ran overconfident on the same inputs. Only then set thresholds, and pin the model version when you do.
List every place an agent or workflow asks a generative model a bounded question. Queue, priority, risk, relevance, policy. That list is the candidate set.
Pick high-volume, low-blast-radius ones with a month of logged human outcomes. Measure before you route anything.
Name the engineer who sits with the domain expert and turns "urgent" into five questions and a set of weights. This is the scarce skill, not API access.
Per action, per question, tuned on our own logs, with an explicit "none of these" option and a human path for low confidence. Written down, in code.
Can each state be reduced to non-personal fields? If not, is the open-weight clone in-country the answer for that decision?
If the vendor's price doubles or the API goes dark, does the cascade fall back to an open model we run? Have we tested that path once?
For most mid-sized teams the move this quarter is not to put a one-week-old API on the safety path of a production agent. It is to run the shadow evaluation, learn the question-design skill on three real decisions, and build the cascade with the backstop in place. If the numbers hold on your traffic, promote it. If they do not, you have spent a few rand and learned exactly where your decisions live.
The deep version for your engineers: the three primitives, the confidence formula, the four patterns, the full independent evidence table, the clones ranked, and the decision guide.
Open the leaf →The ladder of autonomy and the guardrails that move a task from red to green. A typed-decision model is the cheapest guardrail in that toolbox.
Read briefing →The routing layer is one of the five. The decision model is what the router calls first, and the backstop logic applies to it too.
Read briefing →The residency half of the state-filtering discipline: what may cross the border, what stays, and where the checkpoint lives.
Read briefing →A model that returns honest probabilities instead of prose is a new layer in the stack, and it is already commodity at the weights. The value moved to the questions you ask it and the thresholds you own. Build those, keep a backstop, and let the expensive model do only the work that needs a paragraph.