Jev, GPT-6 Astra and Fable 5.1: marketing vs reality

Three models are currently being compared to each other in the same conversations. GPT-6 Astra and Claude Fable 5.1, both marketed as state of the art at software engineering, both priced at $10 per million input tokens. And Jev, from Typesafe AI, launched on 19 September 2026, claiming to be 193.6 times faster and 444.6 times cheaper than them.

That third claim is doing something odd, and it is worth unpicking carefully, because the comparison it invites is not the comparison it supports.

What Typesafe AI actually launched

Jev is the first of what Typesafe calls System One models, and the architecture is genuinely novel rather than a repackaging. The pitch is unstructured state in, typed probabilistic decisions out.

• It is not autoregressive. Instead of generating a token at a time, it samples the whole structured output in parallel. That is where the speed claim comes from: 70 to 500 milliseconds end to end, against seconds to minutes for a frontier LLM.
• It is trained with RLCD, Reinforcement Learning for Calibrated Decisions, rather than RLHF. The stated goal is honest probabilities on a decision rather than an answer a human rater liked.
• It emits typed values, not strings. Typesafe say type errors are mathematically impossible and hallucination is zero, because the output cannot be malformed by construction.
• It is priced differently in kind. $0.042 per million input tokens, with output tokens free, against $10 and $50 for the two frontier models.

The problem being solved here is real and I run into it constantly. Using a large language model as a classifier inside an application is slow, costs more than the decision is worth, and forces you to parse and validate whatever comes back before you dare act on it. A component that returns a typed decision in under a tenth of a second is a genuinely useful thing to exist.

The comparison invites a category error

Here is the sentence that reframes the entire discussion. Jev cannot write code. It gives up string generation entirely. It is not a coding model, not a chat model, and not capable of producing a written explanation of anything.

Typesafe are upfront about this in their own announcement, and credit where it is due. But the numbers that travel are 193.6 times faster and 444.6 times cheaper than GPT-6 Astra and Fable 5.1, and a number like that, attached to those two names, reads to most engineers as a claim about a better model. It is not. It is a claim about a different category of component that was measured on the narrow slice of work the two overlap on: making a structured decision.

Jev is not competing with Claude Code or Codex. It is competing with the if-statement you currently implement by asking an LLM to return JSON.

Once you see it that way the comparison becomes useful rather than confusing. If you have a classifier, a router, a moderation gate or a scoring step sitting in a request path, a specialised typed decision model is an obvious thing to evaluate. If you are trying to ship a feature in a Laravel codebase, Jev has nothing to offer you and does not claim to.

What "mathematically impossible to make type errors" really means

This claim is true, and it is narrower than it sounds. Both halves matter.

Constraining a model's output so it can only produce values matching a schema is a real and well-understood technique, and the guarantee is genuine: you will never receive a malformed response, never write parsing glue, never handle the case where the model wrapped its JSON in an apology. If you have built LLM features in production, you know how much code that eliminates.

But type-correct is not the same as correct. A schema guarantees the shape of an answer, never its truth. A confidently typed RiskLevel.Low on a customer who is about to default is type-safe, calibrated, sub-100ms, and wrong. The compiler cannot help, because nothing about it is malformed.

Where the numbers come from

The benchmarks, the speed multiples and the cost multiples are all published by Typesafe, measured on their own workflow evaluations, and demonstrated through simulator-based examples rather than production deployments. System One is their own coined category rather than an established one, and at the time of writing no independent party has reproduced any of it on a neutral harness.

None of that makes the claims wrong. It is exactly what every launch looks like on day one, and Typesafe themselves note their figures represent the higher end of real-world gains. It does mean the correct posture is promising rather than proven. If the decision matters, run it on your own data before believing a multiple with a decimal point in it.

Meanwhile, for actually writing code

Which brings us to the two models that do write code, where the marketing has its own gap between claim and evidence.

That last row is the problem in one line: the two labs reported their flagship coding result on different benchmarks run on different harnesses, and those incomparable numbers are the ones quoted side by side everywhere.

The third row is the finding I would actually act on. On the same index, Astra scores 62 inside Codex and Fable 5.1 scores 62 inside Claude Code. Level. The gap between these two models is smaller than the gap between a model on a benchmark rig and the same model inside the tool you type into every day.

And on DeepSWE, widely considered the closest proxy for real developer work, Astra lands around 73 to 74%, only slightly above its predecessor and behind both Gemini 3 Flash and Meta's Muse Spark 1.3. The enormous gains are concentrated in abstract reasoning and mathematics, which is not what most of us are paying for.

The only randomised trial found the opposite

METR ran a randomised controlled trial with experienced open-source developers on their own large repositories, randomly allowing or forbidding AI tools across 246 real issues. Beforehand the developers predicted a 24% speed-up. Afterwards they estimated they had been sped up by 20%. Measured, they were 19% slower with AI than without it.

Two caveats, which I would rather state than have quoted back at me. The study used frontier models from early 2025, several generations behind anything discussed here. And it studied experts on codebases they knew intimately, the scenario where an assistant has least to add. Both cut the same way, so the effect is probably smaller now.

The durable finding is not the 19%. It is the roughly forty point gap between perceived and measured, in the direction the marketing pointed. Feeling faster is not evidence of being faster, and a tool that produces plausible code quickly is exceptionally good at producing that feeling.

It compiles, and that is the problem

The same distinction that qualifies Jev's type-safety claim applies to every line of AI-written code in a typed codebase. Type checking proves internal consistency. It cannot prove intent. A perfectly typed function can read the wrong column, drop the tenant scope, or swallow an error, and nothing goes red.

GitClear's analysis of millions of real commits shows what that looks like at scale: churn up from 4.5% to 5.7% year on year, refactoring down about 40%, copy-pasted code up 17%, duplicated blocks up eightfold, and copy-pasted lines exceeding moved lines within commits for the first time. Senior engineers report 20 to 35% more time in review where juniors lean heavily on assistants.

The reason it gets through review is that AI-written code is well formatted, syntactically clean and properly commented, so it reads as high quality. The defects that drive churn are exactly the ones those qualities conceal.

Choosing between them, honestly

Three tools, two entirely different jobs. The marketing puts them on one axis because a single number comparing yourself to the best-known models is the most effective thing you can publish. The engineering reality is that Jev replaces a slow, expensive decision in your application, and the other two help you write the application around it.

Whichever you reach for, the discipline is identical and unglamorous. Define what a correct answer looks like before you start, measure whether you got more of them, and do not accept a vendor's multiple, a benchmark score or your own sense of momentum as a substitute for that. On the one occasion anyone checked properly, the feeling and the measurement were forty points apart.