What are typed parallel decisions?

An output interface in which the shape of the answer — every field and every legal value — is declared before the model runs, and the model fills all of those fields in a single query rather than decoding them as text one token at a time. Each field comes back as a typed value with a probability attached, so the surrounding code reads a value instead of parsing a string.

How is this different from JSON mode or constrained decoding?

Constrained decoding is still autoregressive: the model emits tokens one after another, and the sampler masks out any token that would break the schema. That makes the string valid but does not remove the string, the serial dependency between tokens, or the parse step at the end. Jev removes all three by never producing text in the first place.

Why does calibration matter more than raw accuracy here?

Because automation needs a threshold to branch on. A model that is right 95% of the time but gives no honest signal about the other 5% cannot be wired into code without a human checking everything. A calibrated probability on each field lets the workflow act on the confident answers and route the uncertain ones elsewhere — which is why TypeSafe's training method targets calibration by name.

Are the speed and cost numbers independently verified?

No. Every figure in the announcement — the 70–500 ms end-to-end range, the 40× to 200× speedup, the $0.042 per million input tokens — is measured and published by TypeSafe, on workflows its own team built, against reference answers drawn from GPT-6 Astra and Fable 5.1. The post states these caveats itself. The mechanism is clear; the size of the advantage is a vendor claim until it is reproduced outside the company.

Agent· 2026-09-18

TypeSafe releases Jev — Typed parallel decisions — What does it mean?

TL;DR

What is it: TypeSafe AI released Jev in early access on September 15, 2026 — the first of what it calls System One Models, a class that gives up generating text and instead returns typed values, all sampled in parallel, each carrying its own probability.
Why it’s needed: Most of the work inside an agent is not writing prose but making a decision — classify this, route that, score it, branch here — and today every one of those decisions is decoded as text and then parsed back into a value, which is both the slowest link in the loop and the place where your code can be handed something that is not in the type.
vs previous: The incumbent fix is constrained decoding: keep emitting one token at a time, but mask the vocabulary so the string is forced to match a JSON schema — Jev instead fixes the output shape before the model runs and samples every field at once, so there is no string to parse afterwards and, TypeSafe says, no type error left to catch.

Jargon

System One Model: TypeSafe's name for this model class, borrowed from Kahneman's two systems of thinking: System 1 is the fast, automatic judgement, System 2 the slow deliberate one. A System One Model is built only for the fast judgement — classify, route, score, branch — and gives up open-ended writing in exchange.
Autoregressive decoding: The standard way a language model produces output: one token at a time, each token conditioned on the tokens before it. Because step n+1 cannot start until step n finishes, the wall-clock time grows with the number of tokens. LAV walks this in One Token at a Time.
Constrained decoding: Also called grammar-constrained decoding, or JSON mode. Still autoregressive, but at each step the sampler masks out every token that would break the target grammar, so the finished string is guaranteed to parse. It makes the string valid; it does not remove the string. See the jailbreak that abuses it.
Calibration: A model is calibrated when its stated confidence matches how often it is actually right — of the answers it marks 0.7, about 70% should be correct. An uncalibrated model that is right 95% of the time but never signals which 5% it got wrong cannot be automated around, because there is no threshold to branch on.
RLCD: Reinforcement Learning for Calibrated Decisions — TypeSafe's training method, named as the counterpart to RLHF (which optimizes for answers human raters prefer) and RLVR (which optimizes for answers a program can verify). RLCD instead optimizes for decisions whose attached probabilities are honest.
Cardinality: The number of legal values a field can take. Jev supports choices up to a cardinality of 255. Above that, TypeSafe says it runs a two-stage system — score the options independently, then make an explicit choice — which is where its demos show an occasional slowdown.
MTok: One million tokens, the unit model APIs price against. Jev lists $0.042 / MTok on input and charges nothing for output; the frontier models TypeSafe compares against list $0.20 to $10 / MTok on input, with output priced higher still.

The news. On September 15, 2026, TypeSafe AI opened early access to Jev, which it describes as the first "System One Model" — a new architecture, a parallel sampler, and a training method it calls Reinforcement Learning for Calibrated Decisions. Jev does not generate strings: you declare the shape of the answer in advance, and it returns typed values with a probability on each one, in one query, not token by token. TypeSafe's own framing: "Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out." TypeSafe reports end-to-end times of 70–500 ms against 3–329 s for the frontier models tested, and prices input at $0.042 per million tokens, output free. Read the announcement →

Picture the two ways to place an order at a diner.

The first way is to say it out loud. You produce the order one word at a time, and the cook cannot start on the second word until you have said the first. At the end, someone has to turn your sentence back into things the kitchen actually stocks — and because you were speaking freely, nothing stopped you from asking for a dish that is not on the menu. That is autoregressive decoding with a parser bolted on the end: the model emits text, your code reads the text, and the reading can fail.

The second way is a printed form. Every line is already there — the dish, the size, the side, how done you want it — and each line accepts only the values printed next to it. You tick all four at once, because no tick has to wait for another tick. A printed form cannot receive an item that is not on it. There is no blank line to write on, so there is nothing to interpret afterwards. And beside each tick there is a number: how sure you are about that particular line.

Jev is the form. The output shape is declared before the model runs, so the set of legal answers is fixed by construction rather than checked afterwards — which is the same promise LAV's Structured Outputs step makes, moved from the parser into the sampler. The confidence number beside each line is not decoration either: it is what lets the surrounding code branch. A field at 0.98 you act on; a field at 0.62 you send to a human.

Program statestructured input, not a chat log

Declared typeevery legal value, fixed up front

Parallel sampleall fields in one query

Typed valueseach with its own probability

It is worth being precise about what "parallel" buys here, because it is easy to read it as "the model does less work".

A language model decodes text in order because each token is conditioned on the token before it. That is a genuine dependency, and it is why the elapsed time of a reply tracks its length. The fields on an order form do not have that dependency — which side you want does not depend on how done you want the steak — so once the form is fixed in advance, every line can be sampled in the same single pass through the model. The saving is not that Jev does less work; it is that none of the work waits on the work before it. This is the same distinction LAV draws in Parallelizing Tool Calls: independent calls that run at the same time shorten the elapsed time of a tick without reducing the total work done in it.

The second consequence is quieter and probably matters more. Because nothing is written as free text, the probabilities come out directly rather than being asked for. A chat model that you prompt for a confidence score has to write that score as tokens, and those tokens are generated by the same process that produced the answer — which is why models asked to rate themselves tend to be overconfident. Jev's probabilities are the sampler's own, one per field, and the training method is aimed squarely at making them honest. LAV's From Logits to Probabilities step is the background here: the numbers were always in the model, and the usual interface throws them away at the moment it picks a token.

Dimension	Existing LLMs	Jev (System One)
Output	A string. Flexible enough to be a chat reply, code, a refusal — or a value your parser rejects. Must be parsed and validated before software can use it.	A typed value from a shape declared in advance. TypeSafe says schema matching is guaranteed by construction.
Sampling	Sequential — one token at a time, each conditioned on the last.	Parallel — every field returned in a single query.
End-to-end time	~3–329 s on the workflow calls TypeSafe tested (vendor-measured)	~70–500 ms (vendor-measured, from the team's own West Coast laptops)
Price	~$0.20–$10 / MTok input, output ~5× input (TypeSafe's comparison figures)	~$0.042 / MTok input, output tokens free (published price)
Confidence	Asked for a confidence score, models tend to be overconfident and inconsistent (TypeSafe's characterisation).	A calibrated probability on every field — the stated aim being that higher confidence means higher accuracy.

Hold three things fixed: one tick of the same workflow, the same set of independent questions asked about it, and the same declared output shape. TypeSafe publishes two end-to-end ranges measured that way — 3 to 329 seconds for the frontier models it tested, and 70 to 500 milliseconds for Jev.

Take the corner that flatters the language model most: the frontier model at its fastest published time against Jev at its slowest. That is 3 s ÷ 0.5 s = 6×. Now take the opposite corner, 329 s ÷ 0.07 s, and it is roughly 4,700×. TypeSafe's own headline figure, 40× to 200×, sits between those two corners, which is what a range quoted across a mix of queries should do. Even the corner picked to make the language model look best is still 6× faster, and none of that gap comes from Jev being a smarter model — it comes from deleting the wait between one token and the next.

The price moves for the same reason. Jev lists $0.042 per million input tokens, with output tokens free; the models TypeSafe compares against list $0.20 to $10 per million input tokens. On the input side alone that is 0.20 ÷ 0.042 ≈ 4.8× at the cheap end and 10 ÷ 0.042 ≈ 238× at the expensive end. The output side is not a ratio at all — it is a line item Jev does not have, because it never emits the text.

Every number above is TypeSafe's own, measured on TypeSafe's own workflows, and the announcement is unusually direct about what that means. The speed figures were run from the team's laptops on the US West Coast. The workflow evaluations were built by TypeSafe's own model-capabilities team; the post states the workflows were not chosen to flatter the model and are not in its training distribution, while also allowing that "some bias could exist". The reference answers are the average of GPT-6 Astra and Fable 5.1, which the post notes tilts the comparison toward OpenAI's and Anthropic's models.

The zero-hallucination figure deserves its own sentence, because it is not a measurement. TypeSafe says schema matching is guaranteed by construction, so it entered 0% into its charts on that basis rather than from an experiment; the numbers it is plotted against come from traffic on OpenRouter, a service that routes requests across many models. The guarantee is narrow and worth stating precisely: it means the value you get back is always in the declared type. It does not mean the value is right. A form with every box ticked legally can still be the wrong order — which is exactly what the confidence number is there to tell you, and why the calibration claim is the one that actually carries the weight.

There is also a stated ceiling. Jev handles choices up to a cardinality of 255; past that, TypeSafe runs a two-stage system that scores options independently and then makes an explicit choice, which is where its own demos show the slowdown. None of this makes the mechanism wrong. It means the size of the gap is a vendor claim until somebody outside TypeSafe runs the same workflows.

So what changed? Not the intelligence — TypeSafe's claim is that Jev reaches similar levels on this class of task, not higher ones. What changed is the interface: the model stopped answering in a medium that software has to interpret. If you are building workflows rather than open-ended agents, that is the part of the stack you have been writing defensive code around all along — the parse, the re-validate, the retry when the JSON comes back malformed. The interesting question the release leaves open is not whether typed decisions are faster. It is how much of what we currently call an agent is really a chain of small decisions wearing a chat interface.

Goes deeper in: AI Agents → Tool Use → Structured Outputs

Related explainers

Grammar-constrained decoding jailbreak — the incumbent way to force structure onto a string, and the attack that exploits it
Uno's LoRA diffusion adapter for block-parallel decoding — the other route out of one-token-at-a-time, which keeps the text and parallelises the tokens
Full JSON Schema 2020-12 in MCP tool I/O — declaring an output shape up front, at the protocol layer instead of the model layer

Frequently Asked Questions

Check what you knowMap your AI & GPU knowledge across every track — free, role-based