TypeSafe AI launched Jev on 15 September 2026 with a headline of "193.6x faster, 444.6x cheaper" and a promise that it "can't hallucinate". Read the primary sources rather than the reposts and a narrower, more interesting product appears: a frontier-trained classifier for software, not a better large language model, with every number so far reported by the vendor.
This is a snapshot of a product that was one day old when I wrote it, in early access, with no paper and no independent benchmarks. Treat every figure as "as of September 2026" and check TypeSafe's current pages before relying on any of it.
The picture to hold in your head
Jev is a model that never writes text. You hand it a block of state, such as an invoice, a security alert, a support ticket or a game frame, together with a fixed set of typed questions, and it returns an answer to every question at once: a choice from a list you declared, a score on a scale you declared, or a probability that a statement you wrote is true. Each answer carries a probability distribution and a confidence number. That is the whole product.
The contrast TypeSafe draws is with how a large language model (LLM) answers the same question. An LLM generates tokens one after another, each token conditioned on the previous ones, and even when you force it into a JavaScript Object Notation (JSON) schema it still has to spell the answer out. Jev, according to TypeSafe, produces all its outputs in a single parallel pass, which is why adding more questions to a call "barely changes the response time".
TypeSafe calls this category a "System One model", borrowing the fast, intuitive System 1 from Daniel Kahneman's Thinking, Fast and Slow, as opposed to the slow, deliberate System 2 that reasoning LLMs imitate. The framing is marketing, but it is accurate marketing: Jev is meant to be the reflex, and your code, or a real LLM, is meant to be the deliberation. Everything below is either a fact about that reflex or a claim about how good the reflex is.
What is known for sure
These are the facts that come from TypeSafe's own launch material, its documentation, or reporting that quotes the company directly. None of them depend on believing a benchmark.
- Who. TypeSafe AI is led by Diogo Almeida, a former OpenAI researcher. The Register reports the company has raised 40 million US dollars and spent about two years in stealth. The launch post is dated 15 September 2026.
- What you send. One call carries a state and a list of typed questions. The documentation says every question is "evaluated in parallel and in isolation against the same state in one go", and recommends that each question ask "one specific, well-scoped thing", with the combining logic living in your code.
- What you get back. Three primitives, and only three, described in the table below.
- Limits and price. A Choice may have at most 255 options. Input is priced at 42 US dollars (USD) per billion tokens, which is 0.042 dollars per million tokens, and output is free. End-to-end latency is quoted as 70 to 500 milliseconds.
- Availability. Early access from a waitlist. No weights, no paper, no architecture description beyond the phrase "new architecture" and a training method named Reinforcement Learning for Calibrated Decisions (RLCD), which the launch post contrasts with the reinforcement learning from human feedback (RLHF) and reinforcement learning from verifiable rewards (RLVR) used to train LLMs.
- What it gives up. String generation, entirely. Jev cannot explain an answer, summarise a document or fill a free-text field. The launch post says so plainly.
| Primitive | You declare | Jev returns |
|---|---|---|
| Choice | A list of options (up to 255) | The chosen option, a probability per option, a confidence |
| Score | An ordered set of levels or a rubric | A score, a distribution over the levels, a confidence |
| Noul | A statement about the state | A single probability, 0 to 1, that the statement is true |
"Noul" is TypeSafe's coinage for the yes/no primitive. The confidence number is not a separate model output. The confidence docs define it as "a statistic computed from the probability distribution the answer already gives you", a single number that is high when the distribution is concentrated and low when it is spread out, and they invite you to derive your own measure from the raw probabilities instead.
That is the entire verifiable surface: an input shape, three output shapes, a price, a latency range and a waitlist. Everything else in the coverage is a claim.
The headline claims, decoded
The launch page makes six claims that travelled far in a day. Each one is true in a narrow reading and misleading in the reading most people took away.
| Claim | Literal meaning | How much survives |
|---|---|---|
| "193.6x faster, 444.6x cheaper" | Jev vs. the slowest and priciest baselines in TypeSafe's own four-workflow eval | |
| "70 to 500 ms end to end" | Measured latency of one call | |
| "0% type errors, can't hallucinate" | Output always matches your declared schema | |
| "Calibrated probabilities" | The returned probabilities match real-world frequencies | |
| "Frontier intelligence" at Terra level | Ties one mid-tier model on average agreement with two frontier models | |
| "New architecture, RLCD" | A training method and an architecture exist and are not disclosed |
The multipliers are real but chosen. TypeSafe publishes the numbers behind them on its evals page. Four internal workflows, security incidents, agent trace review, invoice processing and customer service routing, were decomposed into decision graphs and run through Jev and through a set of LLMs. The rows that matter are these, all in "workflow" mode, meaning the LLMs (the GPT family is short for generative pre-trained transformer) answered the same typed questions through TypeSafe's harness rather than one big prompt:
| Model | Agreement with reference | Cost per case (USD) | Seconds per case |
|---|---|---|---|
| Jev | 67.8% | 0.0004 | 0.4 |
| GPT-5.6 Terra | 67.9% | 0.0304 | 10.1 |
| GPT Sol | 74.1% | 0.0836 | 23.3 |
| Claude Opus 5 | 73.1% | 0.1761 | 37.8 |
| Claude Sonnet 5 | 67.8% | 0.1174 | 78.1 |
| Claude Haiku 4.5 | 53.6% | 0.0195 | 12.5 |
Divide Sonnet 5's time by Jev's and you get roughly 195x. Divide Opus 5's cost by Jev's and you get roughly 440x. Those are the two headline numbers: each is Jev against the single baseline that makes the ratio largest. Against Terra, the model TypeSafe itself picks as the intelligence peer, the same arithmetic gives about 25x faster and 76x cheaper. Still remarkable, and a good deal less than the poster.
"Accuracy" here means agreement with two other models. The evals page states that "the reference labels are generated via an average of the responses of GPT-6 Astra and Claude Fable 5.1, both at high thinking". There is no human ground truth anywhere in the eval. Jev's 67.8% means it agrees with the two-frontier-model consensus about two thirds of the time, and so does Terra. Whether the consensus was right is a separate question the eval cannot answer. TypeSafe also flags, to its credit, that the workflows "were made by individuals on our model capabilities team, so some bias could exist" and that the results sit "on the higher end of real world gains".
The average hides a real gap on the hardest task. On invoice processing Jev scored 61.8% against Terra's 74.7%, Opus 5's 78.4% and Sol's 79.1%. Its best workflow was customer service at 76.0%. So "Terra-level" is true of the mean across four tasks that TypeSafe chose, and false on the one that looks most like extracting structured facts from a messy document.
The eval's most useful finding is not about Jev. Every LLM in the table scored higher, cost less and ran faster in workflow mode than when given the same policy as a single prompt. Haiku 4.5 went from 18.1% as a prompt to 53.6% as a decision graph. Decomposing a judgment into small typed questions is a technique you can apply today with whatever model you already pay for, and TypeSafe's own data says it is worth doing regardless of whether Jev exists.
"Can't hallucinate" is a statement about types. The launch post is explicit: "Our number is not empirical. Schema matching is guaranteed." Jev cannot return a category you did not declare or a malformed value, because it only ever selects among the outputs you gave it. It can still select the wrong one, confidently. This is the same guarantee that constrained decoding already gives you: OpenAI's Structured Outputs documentation promises that responses "adhere to your supplied JSON Schema" and says nothing about the content being right, for exactly the same reason. Sean Goedecke calls the hallucination line "a semantic dodge", and Anthony Maio puts it more precisely: the model "constrains the shape of the output. It does not constrain the judgment." Both are right. A wrong answer that type-checks is still a wrong answer, and if your option list has no "none of these", the probability mass has to land on something.
"Calibrated" is asserted, not demonstrated. Calibration has a precise meaning: among all the answers a model gives with probability 0.8, about 80% should turn out true. It is the property that would let you set a threshold and trust it. The word is in the name of the training method and in the launch copy, and it is absent from the documentation, which publishes no calibration curves, no Brier scores and no reliability diagrams. The docs' threshold advice, route to a human below 0.5, act automatically above 0.9, ends with "test with your own data, and adjust as you observe results". That is sound advice, and it is also an admission that the calibration is yours to verify.
The latency is the claim that has already been checked. Mike Taylor at Every ran eleven experiments during early access, including 777 judgments over 37 documents that returned in under 0.7 seconds, and 1,709 judgments in total for less than a cent. On a small defect-detection test Jev found six of seven planted problems where Fable 5.1 found all seven, at roughly 25 times the speed and about 580 times lower cost. One person's afternoon is not a benchmark, but it is the only measurement so far that TypeSafe did not run itself, and it matches the vendor's latency and price and shows the expected accuracy gap.
What is still not known
The list of unknowns is longer than the list of facts, and most of it is the kind of thing a paper would settle.
- What the model is. Nothing about size, architecture, pretraining data or whether it is a distilled or re-headed LLM. "Parallel sampler" and "new architecture" are the only words offered. Goedecke's guess is that the novelty is mostly in inference strategy, and that a model with no test-time compute will cap out around non-reasoning LLM quality. The invoice numbers are consistent with that guess.
- What RLCD is. No reward function, no training procedure, no ablation. It could be a genuine advance in producing calibrated heads, or a rebranding of standard classifier training with a calibration loss. There is no way to tell.
- Whether the probabilities are calibrated, on any distribution, let alone yours. This is the claim the whole product rests on, since without it the confidence number is a decoration, and it is the one with the least evidence.
- How it behaves under shift. A classifier that is well calibrated on TypeSafe's four workflows may be badly calibrated on your tickets. Maio's warning about composition applies too: a chain of individually reasonable thresholds can compound into an unreasonable pipeline, and nobody has measured that yet.
- Context limits, rate limits, regions, data retention. None of it is public. The Doom demo runs at about ten calls per second and, by TypeSafe's own aside, costs about seven US dollars an hour, which tells you the rate limit is at least that.
- Whether the economics hold. The Register notes the name reads as a nod to the Jevons paradox, the idea that making a resource cheaper increases total consumption of it. That is a bet about demand, not a fact about the model.
Where it slots next to what you already have
If the claims hold, Jev is not competing with your chat model. It is competing with the three ways teams already get typed decisions out of software, and it is worth being precise about what each one costs.
| Approach | Needs your labelled data | Latency | Cost per decision | Probabilities | Zero-shot on a new question |
|---|---|---|---|---|---|
| Fine-tuned classifier (BERT-style) | Native, calibration is your job | ||||
| LLM, single constrained token + logprobs | Token logprobs, crude | ||||
| LLM, structured output (JSON schema) | Self-reported, unreliable | ||||
| Jev (as claimed) | Native, calibration unverified |
The middle row of the table is the one Goedecke's post is about, and it deserves more attention than it gets. If you prefill an LLM's response so that the only thing left to generate is a single token chosen from a fixed set, you get one forward pass, a probability per option from the logprobs, and no parsing. He reports a two to three times speed-up over ordinary structured output on a small open model doing exactly this. It does not reach Jev's claimed latency, because a general LLM still has to process the whole prompt through a much larger network, but it is available this afternoon, on the model you already have, with no waitlist.
Where Jev would genuinely change things is the shape of the code around it. Because every question in a call is answered in parallel and the marginal question is nearly free, the natural pattern is a decision graph: many small typed questions, combined by ordinary code, with an LLM reserved for the steps that need text.
The thresholds in that diagram are the ones TypeSafe's docs suggest as a starting point. Every arrow labelled with a probability is a place where the calibration claim is load-bearing. If the probabilities are honest, this pipeline is cheap, fast and mostly unattended. If they are not, it is a machine for confidently mis-booking invoices at ten decisions a second, and nothing in the returned JSON will tell you which of the two you built.
What to watch
The gap between "interesting" and "trustworthy" will close, or not, on a short list of things, none of which have happened yet.
- A calibration curve from someone other than TypeSafe, on a dataset with human labels, ideally on a domain far from the four launch workflows. This is the single result that matters most.
- An eval with human ground truth. Agreement with two frontier models is a proxy that quietly rewards agreeing with frontier-model mistakes.
- A paper or technical report on RLCD. Until then, "calibrated" in the method's name is a promise about intent.
- General availability with published limits, so the latency and price can be measured under real load rather than in a demo.
- A single-token logprobs baseline in TypeSafe's own eval. The current table compares Jev with LLMs generating full structured answers, which is the slowest fair comparison. The cheapest fair one is missing.
The thing I would not wait for is permission to use the underlying idea. Decomposing a judgment into small typed questions and combining them in code made every model in TypeSafe's table better, faster and cheaper, before Jev entered the picture. That part is not a claim. It is the one result in the launch that anyone can reproduce with the model they already have, and it is the reason the shape of Jev matters even if the numbers turn out to be soft.
References
- TypeSafe AI, Introducing System One Models and Jev — TypeSafe AI Blog
- TypeSafe AI, Workflow evals — evals.typesafe.ai
- TypeSafe AI, Documentation: overview — docs.typesafe.ai
- TypeSafe AI, Documentation: confidence — docs.typesafe.ai
- Thomas Claburn, TypeSafe AI debuts model for machines that plays Doom — The Register
- Sean Goedecke, Jev means structured output is interesting again
- Anthony Maio, Jev: The Language Model That Won't Talk — Substack
- Mike Taylor, Mini-Vibe Check: TypeSafe's Jev Judged Everything I've Written in 0.7 Seconds — Every
- OpenAI, Structured Outputs — OpenAI developer docs
- Thinking, Fast and Slow — Wikipedia
- Jevons paradox — Wikipedia