Language models have been superhuman at conversation for a few years now, and yet most real automation still stalls at the same place: the model writes something, your code has to parse it, validate it, and hope it did not drift. TypeSafe AI argues the problem is the output format itself, and has released Jev as an answer.

Jev is what they call a System One model: a model built for fast, structured judgement rather than text generation. In their announcement post, founder Diogo Almeida, who previously worked at OpenAI on the instruction-following research behind ChatGPT, describes two years in stealth building a separate stack for this: a new architecture, a parallel sampler, and a training method they call Reinforcement Learning for Calibrated Decisions (RLCD). The model is currently in early access.

Decisions, Not Strings

This is the whole idea. An LLM emits a string, and a string can be anything: a chat response, code, a refusal, a hallucination, or, if you are lucky and prompt carefully, the structured value you actually wanted. Either way your software has to parse and validate it, and there is always some residual risk that the model goes off the rails.

Jev inverts that. The set of possible outputs and their structure are fixed before the query runs, so the model cannot produce a type error, and there is no text-generation step in the middle to parse back out. According to the TypeSafe documentation, you evaluate typed questions against a state, and a single call can carry several of them, each answered in parallel and in isolation.

• Choice — pick from a fixed set of options, returning the value, the probabilities, and a confidence score
• Score — rate the state against criteria, returning the score with probabilities and confidence
• Noul — evaluate a truth statement, returning a value between 0 and 1

The Shape of a Query

The exact API is behind early access, but the conceptual shape is simple enough to sketch, and it is the part worth internalising: state in, typed answers with probabilities out, no string in between.

state     →  the structured context your program already has
question  →  Choice(options) | Score(criteria) | Noul(statement)

result    →  { value, probabilities, confidence }

# many questions per call, each answered in parallel and in isolation
# your code branches on value, sorts by probability, routes on confidence
                

Why Calibration Is the Real Point

The speed and price numbers get the attention, but calibration is the claim that actually changes what you can automate. TypeSafe make the argument sharply: if a model can do a task 95% of the time but never tells you when it is in the other 5%, you cannot automate that task. You are forced to put a human on all of it.

LLMs are known to be overconfident and inconsistent about their own certainty, even when you explicitly ask them for a confidence estimate. Jev is trained so that every answer carries a calibrated probability, meaning higher confidence really should correspond to higher accuracy, and so that similar inputs return similar answers. That is what makes a threshold a legitimate engineering control rather than a guess.

• Act automatically when confidence is above your threshold
• Escalate to a human review queue when it is below
• Combine independent decisions instead of relying on one long chain of reasoning
• Tune the threshold per task, according to the cost of being wrong

The Numbers, and How to Read Them

TypeSafe publish their own figures, and are candid that they are their own figures. Their headline comparison of 193.6x faster and 444.6x cheaper comes from four workflow evaluations they have published, scored against the average of two other frontier models as the reference answer. They note the workflows were written by their own model capabilities team, that some bias could exist, and that using another vendor as the reference likely understates their competitors. That is a more honest framing than most launch posts, but it is still vendor-run evaluation, and it deserves independent replication before anyone plans a system around it.

• Latency: 70–500 ms end to end, against seconds for frontier LLMs, which they put at 40x–200x faster for System One shaped queries
• Input price: $0.042 per million tokens, against roughly $0.20 to $10 per million for frontier LLMs
• Output price: free, against output tokens that typically cost about 5x input tokens elsewhere
• Sampling: all outputs produced in one query, rather than one token at a time conditioned on the last

Where It Fits, and Where LLMs Still Win

This is not a replacement for language models, and TypeSafe do not pitch it as one. Giving up string generation buys speed, price and type safety, and costs you everything that makes strings useful. The two are complementary, and the interesting part is that Jev is well suited to supervising the thing it does not replace: scoring, judging, verifying and guardrailing LLM prompts, reasoning traces and outputs.

System One work is classification, routing, scoring, extraction and branching — the fuzzy if-statements that sit inside ordinary software, where hand-written rules are too brittle but a full chat model is too slow and too loose. Real-time interfaces where latency is visible to the user, and enrichment jobs over very large volumes of data, both fall in the same category. Open-ended work does not: chatbots, copilots and coding agents need a human in the loop, and problems where correctness can be checked cheaply, such as proofs or kernel optimisation, still favour a model that can generate, test and iterate. Strings also remain unbeatable for getting a prototype working quickly.

What I Take From It

Most of what I build in healthcare is not generation. It is judgement under uncertainty — triage, risk scoring, eligibility checks, flagging a case for a clinician to look at. Those systems live or die on two properties that Jev is explicitly designed around: the output has to be a typed value the surrounding software can act on, and the model has to be honest about when it does not know, so the uncertain cases route to a person instead of being silently decided.

So the framing lands for me, independent of whether this particular model holds up. Whether the calibration survives contact with messy real-world data, distribution shift, and the long tail of edge cases is exactly the sort of question that needs external evaluation rather than a launch post — mine included. I would want to see it tested on data it was never trained near before trusting a threshold to it.

Closing Thoughts

The useful idea here is not really the model, it is the reframing: that a large amount of what we currently ask language models to do is not writing at all, it is deciding, and that decisions want a different interface than prose. Constrain the output space, answer many small questions in parallel, and attach an honest probability to each one. If the calibration claims hold up under independent scrutiny, that is a genuinely different building block to design systems around. Worth watching — see typesafe.ai and the documentation for the details.