Back to blog
AIAgentsArchitectureSystem One

System One models: the AI that decides instead of writing

System One models: the AI that decides instead of writing

A System One model is a class of model that returns typed, bounded decisions with calibrated probabilities instead of generated text. You send it state and a set of typed questions, and it returns answers your code can consume directly, with no parsing step and no prompt engineering to keep the output in shape.

What did TypeSafe actually launch?

On 22 September 2026, TypeSafe AI, a lab based in San Francisco, published Jev, which it calls the first public System One model. The name comes from Kahneman: System 1 is fast, automatic judgement; System 2 is slow deliberation. Chat models were built for the second. Jev is built for the first.

It answers three kinds of question:

PrimitiveWhat you askWhat comes back
ChoicePick one option from a defined setThe option, a probability for each option, and a confidence
ScoreRate the state against ordered levelsThe level, a probability per level, and a confidence
NoulIs this statement true?The probability that the answer is yes, from 0 to 1

It cannot write a sentence, and that is the deliberate trade: it gives up string generation and gains outputs that are structurally incapable of arriving malformed. TypeSafe supports up to 255 options in a single choice, and trains the model with a method it calls RLCD, Reinforcement Learning for Calibrated Decisions, aimed at making the confidence honest — so that answers given at 90 % turn out right about 90 % of the time.

Are the numbers real?

TypeSafe's own figures are end-to-end responses in 70–500 ms, input priced at $0.042 per million tokens with output free, and, on its internal workflow evaluation, 193.6× faster and 444.6× cheaper than a frontier model.

Those are the vendor's numbers, and they deserve the caveat the vendor itself supplies. TypeSafe states that it deliberately did not use public benchmarks, and advises readers to put no weight on them, preferring that each team build evaluations for its own use case. Jev is in early access behind a waitlist. There is no independent measurement to point at yet, so any figure you read today, including these, traces back to the company selling the model.

The "zero hallucinations" claim needs the same care. It is a type guarantee, not an accuracy guarantee: the model cannot return a value outside the schema you defined, but it can still pick the wrong option from inside it. Zero out-of-schema output is not zero wrong answers. That distinction is the whole thing, and it is worth getting right before anyone repeats the headline.

What does this change for an agent?

This is the part that holds regardless of which vendor ends up winning.

Most agents in production today use one general-purpose model for two very different jobs: writing things a person will read, and deciding things only the software will read. The second job is where the general-purpose model fits worst. Classify this ticket, route this request, score this lead, decide whether to escalate, pick the next tool — you get a paragraph where you needed an enum, you parse it, you add a retry for when the parse fails, and you still have no honest signal for how sure the model was.

Separating those two jobs is a sound architectural decision on its own merits:

Chat modelSystem One model
OutputA string you have to parseA typed value your code consumes
Failure modeMalformed or invented outputA wrong choice inside a valid set
UncertaintyImplicit in the wording, if present at allAn explicit probability, plus a separate confidence
Suited toWriting, reasoning, codeClassifying, routing, scoring, branching

The practical consequence is a second axis for control flow. When an answer carries a calibrated confidence, your code can act on it: proceed above a threshold, fall back to a larger model in the middle band, escalate to a person below it. That rule lives in your code, where you can read it, version it and test it, instead of inside a prompt.

Should you migrate anything today?

No, and nobody can honestly tell you otherwise while the model sits in early access with no public benchmarks behind it.

What is worth doing today costs less and lasts longer: count how many of your agent's calls are decisions rather than writing. That number is what tells you whether any of this matters to you, and producing it is a morning's work. Those calls are the ones paying the latency and the cost of a model built for a job they are not doing, and they are the ones you could move later — to a System One model once it is available and independently measured, to a small fine-tuned classifier, or to plain code that never needed a model in the first place.

We build agents and the backends underneath them, and we run that count before recommending anyone change a line. If it turns out your decisions belong in ordinary code, we will say so.