Gritt has spent the season pulling apart numbers that were technically true and operationally useless, so it is worth saying plainly that this week he found one worth being excited about. A model that returns typed decisions instead of prose, at a price that makes a whole category of work affordable to automate properly - we have run it, and it does what it says. He still does the division, because the 444.6x on the homepage is measured against the priciest row in TypeSafe’s own table and the honest figure is nearer 76x. Read it for the capability; keep the multiple for the board deck. — Muximus
TypeSafe AI announced a new type of AI model named Jev.
Its homepage leads with “193.6x Faster, 444.6x Cheaper,” and both numbers are real arithmetic. They are also arithmetic against the most expensive and one of the slowest configurations in the company’s own benchmark table. Against the model TypeSafe itself nominates as its closest match on intelligence, the figure is about 76 times cheaper - extraordinary, plannable, and roughly a sixth of what the homepage says.
That is the verdict, and the rest of this is the receipt. There is a second finding buried three pages deep in the launch material that matters more than either number, and it does not require TypeSafe’s product at all.
Start with what the company did on 15 September. After two years in stealth, TypeSafe shipped a model that charges nothing for output tokens and $0.042 per million for input. The reason output is free is not generosity and it is not a subsidy play.
It is that there is almost no output.
The model, Jev, does not write sentences. It takes a block of state and a set of typed questions declared in advance, and hands back values with probability distributions attached - a yes-or-no with a probability, one option picked from a list, a score on a rubric. Its founder, Diogo Almeida - who TypeSafe says co-invented RLHF and InstructGPT, and who writes in the launch post that at OpenAI he “helped build the methods that made language models useful at following instructions and talking with people” - calls it “a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.” The training method has a name of its own, Reinforcement Learning for Calibrated Decisions, set in the launch post against RLHF, which optimizes for what human raters prefer, and RLVR, which optimizes for what a program can verify.
Stop selling sentences and the output line on the invoice goes away.
That is the boring description of something that is not boring at all. A whole class of work that operators have been paying a language model to do - the classify, score, route, extract and branch jobs buried inside every real system - never needed prose in the first place, and until this month there was nothing else to point at it.
VarOps has had early access and has run it on exactly that kind of work: it is fast enough and cheap enough to end the habit of reaching for a language model as an intelligent if-statement. That habit is one this column has been circling for the better part of a year, and this is the first time the alternative has been something to use rather than something to argue about.
Which raises the only question that decides whether any of this lands on a given business, and to TypeSafe’s credit the company answers it in its own comparison table instead of leaving the buyer to guess. Strings stay right, it says, for chatbots, copilots and coding agents, and for problems where correctness can be checked cheaply enough to generate and test until something passes. What it claims for Jev is narrower: “smart if-statements” - classify, route, score, extract, branch - plus map-reduce over large data, real-time paths where latency is the constraint, and scoring or guardrailing what other models produce. That is a vendor drawing its own boundary, in public, before anyone made it. Hold onto the line; it comes back at the end.
Credit where it’s due
Three claims survive inspection, and an Overhyped column that could not say so would not be worth reading.
The pricing is published, and it checks out. Claude Fable 5.1 costs $10 per million input tokens, so TypeSafe’s “238x lower input price” lands at 238.1. The denominator is a named competitor’s published list price, which is the only kind of denominator worth quoting, and it is rarer on an AI homepage than it should be.
The mechanism behind the speed is a real architectural difference rather than a marketing word wearing a lab coat. LLMs generate one token at a time, each conditioned on the last. Jev evaluates every question in parallel and in isolation against the same state, in the docs’ phrasing, “in one go.” The documentation’s claim that adding questions “barely changes the response time” follows from that design, and it holds up in VarOps’s own use: on structured-output work the latency is the thing people notice first, and it is the part of the pitch that needs no argument.
And the type-safety guarantee is an actual guarantee, not a guarantee-shaped adjective. A model that can only return values declared in advance cannot return one that was not. TypeSafe states it more confidently than most vendors would risk. Under the bolded heading “No type errors,” the launch post says: “This would be an easy thing to falsify with just a single counter-example, but it is mathematically impossible.” Anyone who has written a retry loop around malformed JSON knows the size of that.
Then there is the thing that makes this launch genuinely unusual. TypeSafe publishes its own counter-evidence. Listing the claims a reader can verify, the post volunteers that its speed evals were “generally run from our laptops on the West Coast” and that on pricing, “we can’t prove it isn’t subsidized.” Then, under five separate claims, it adds a block headed “Nuance” - conceding that a demo’s deliberately short input “paints our model in an advantageous light,” and that one showcase ran against the LLMs’ non-reasoning modes - every one except Astra, which was set to its lowest reasoning setting - “to make the demo more bearable to watch,” with the addendum that the LLMs “look much worse at this task than with reasoning enabled.”
A vendor that hands over the ammunition is not the vendor to shoot at. TypeSafe hid nothing. What it did was describe two different products - one on the homepage, one in the fine print - and only one of them gets forwarded to a board.
The clearest case is the zero. The homepage says “Zero Hallucinations.” The launch post says Jev “can’t hallucinate.” The 0% on the chart arrives with this attached: “Our number is not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots.” So the zero is a statement about the shape of the answer, not its content. Jev cannot return a value outside the schema. It can absolutely return the wrong one from inside it - which is why the company’s own FAQ carries the question “Can Jev still get things wrong?” The guarantee is worth having. It is not the guarantee the banner implies, and the distance between those two is where the six-figure regret lives.
Which multiple a buyer gets
TypeSafe also published a workflow evals site, and it is far more useful than the homepage - which is its own small indictment of the homepage. It reports mean accuracy, cost and latency for nine model configurations across four business-automation tasks: security alerts, agent-trace review, invoice approval and customer service. Every figure on it is TypeSafe measuring its own model against rivals on tasks its own model-capabilities team built. The company discloses that. Read the numbers with it in mind.
Accuracy first, because accuracy decides which comparison is honest. Jev’s mean is 67.8%. GPT-5.6 Terra, the model the launch post names as “the most comparable at intelligence to Jev on average,” scores 67.9%. Sonnet 5 also scores 67.8%. Opus 5 scores 73.1%, and a configuration listed as sol scores 74.1%. Nowhere on TypeSafe’s own pages does it spell out which models sol and luna are, though its eval charts group every configuration by provider, and both sit in the OpenAI group with terra.
So the intelligence claim is exactly true as worded, and considerably narrower than the banner suggests. Jev ties the mid-tier model it says it ties. It runs five points behind Opus 5 and six behind the top of the field, on the vendor’s own benchmark.
Now the headline. The fine print concedes that 193.6x and 444.6x come from these evals and adds: “we expect that these are on the higher end of real world gains.” They do, and the table shows exactly how high.
What follows is VarOps dividing TypeSafe’s published per-case figures, which are rounded on the page, so every ratio here is approximate. The most expensive configuration in workflow mode is Opus 5 at $0.1761 per case - about 440 times Jev’s $0.0004. Sonnet 5 at 78.1 seconds per case is about 195 times Jev’s 0.4 seconds, which is where 193.6x lands. Two different rows, two different models, one headline. And a point in TypeSafe’s favor while the table is open: Sonnet 5 is not even the slowest configuration on it. DS v4 pro takes 86.5 seconds, which would have supported about 216x. The company left roughly twenty points of flattery on the table, which is more restraint than the category usually manages.
Now set Jev against Terra - the comparison TypeSafe itself nominated, at an accuracy difference of one tenth of a point that is a tie in any honest reading. Terra costs $0.0304 and takes 10.1 seconds per case. That puts Jev at roughly 76 times cheaper and 25 times faster.
Seventy-six times is the number a business case has to survive, and 444.6x is about six times larger than it. A buyer who sizes a project on the homepage figure has overstated the saving six-fold before a line of code is written. That is not a rounding argument. That is the difference between a project that pays for itself and a project that needed to.
Hype-o-Meter: the “tokens are free now” narrative rates 8/10 - the rare case where the thing is better than the pitch and the pitch is still wrong. The speed is real, the pricing is real, and the capability is real. The multiple doing the rounds is six times what a buyer will actually get, which is the only part worth arguing with.
Whether even 76x lands depends on the task
The mean is hiding a lot. Broken out, Jev’s accuracy runs from 76.0% on customer service down to 61.7% on security incidents and 61.8% on invoice processing.
Its standing against Terra inverts inside that range. On security incidents Jev scores 61.7% against Terra’s 51.2% - better by more than ten points. On invoice processing Jev scores 61.8% against Terra’s 74.7% and Opus 5’s 78.4%: last but one, ahead of only Haiku 4.5 at 42.9%. The aggregate tie is the average of two large differences pointing in opposite directions, which is what averages do to anyone who stops reading at the average.
None of that is a property of the model. It is a property of the model on a task, and four published tasks are the start of a shortlist, not a coverage guarantee. So: which of the four looks most like the decision that was going to be automated? If the answer is invoice approval, the 76x is notional and the accuracy cost is seventeen points against the best LLM on that task. If it is customer service, Jev outscored Terra, Opus 5 and Sonnet 5 at a fraction of the cost and the case makes itself. Same model, same week, opposite decisions.
The part that works on the model already in the stack
Here is the sentence that should have been the launch announcement. It is in the eval page’s methodology section, where nobody will find it:
“Averaged across the four example tasks, every model is more accurate, cheaper and faster in the workflow than it is with the same policy as a prompt.”
Every model. Eight LLM configurations - Jev excluded, since it has no prompt mode to compare against. TypeSafe ran each of them twice: once asked to solve the whole task from a prompt, once with the same policy decomposed into narrow typed questions and the branching logic moved into code. Averaged across the four tasks, decomposition won on accuracy, cost and time in every case.
The gains are not rounding. Haiku 4.5 goes from 18.1% to 53.6% - thirty-five and a half points from restructuring the request, on the same model, at lower cost. Luna gains 14.9 points, sol 10.7, Opus 5 8.3, Sonnet 5 7.4, Terra 6.3, DS v4 pro 5.8, DS v4 flash 5.1. And the cheaper half lands in the same breath: Opus 5 drops from $0.3417 per case as a prompt to $0.1761 as a workflow, Sonnet 5 from $0.2251 to $0.1174, Terra from $0.0750 to $0.0304.
Two honest limits, both from the page itself, because a take without its caveats is just a louder take. The win is reported as a four-task average, not a per-task law, and the per-task figures bear that out: on security incidents DS v4 flash actually did worse decomposed - 37.9% against 44.6% as a prompt. And the whole comparison ran on four tasks TypeSafe picked. What the table records is what happened on those four. That is a reason to run the test, not a promise about the result.
The method is documented plainly enough to copy, and the eval page walks an expense-claims policy through it. The policy as a team would actually write it: every claim comes with a receipt, and an unreadable one goes back to the employee; work out whether it is a meal, travel or equipment; a meal over $75 needs a manager’s sign-off when the description does not clearly match the receipt; everything else is approved. Decomposed, the model answers three questions and only three - can the receipt be read, which of three categories is it, and how closely does the description match the receipt on a four-level scale. The code, not the model, then applies the $75 threshold, routes the mismatched meal to manager review, and approves the rest.
That division is the entire technique. Every sentence of the policy becomes either a narrow typed question or a rule in code, and the thresholds live in the code, where they can be read, tested, versioned and argued about in a pull request instead of buried in a paragraph of English that somebody will quietly reword next quarter. As the docs put it: rather than “rate this startup pitch,” ask separately about market size, technical feasibility and differentiation, then combine them with your own formula, because “when priorities shift, change a coefficient in your code rather than rewriting a prompt.”
None of this needs Jev. It needs the model already on the invoice, asked differently. And the wrapper TypeSafe used to run the LLM half of its own comparison is on PyPI - system-one-adapter, MIT licensed and installable today - so the same prompt-versus-workflow test can be run on real work, on the model already being paid for, producing a number about that work instead of somebody’s benchmark.
One caveat to carry in. TypeSafe says the adapter “tends to be slower and more expensive than giving decisions without probabilities,” so the LLM rows in its chart run in a configuration TypeSafe chose. The company does not say whether the prompt-mode runs used the adapter too, which means the exact size of the prompt-versus-workflow gap is not auditable from outside. Which is, conveniently, another argument for measuring it in-house.
What this lets a team build that it could not build before
The cost and the speed are the headline. The thing that actually changes an architecture is quieter, and it is worth walking through, because it is not a faster version of something operators already do.
A request is one state plus as many typed questions as the job needs, and there are only three kinds of question. A Noul returns the probability that a statement is true. A Choice returns one option from a list you defined, plus the probability of every option. A Score returns a position on a scale whose levels you wrote, and it can land between two of them. Nothing else. No prose to parse, no schema to validate, no retry loop around malformed output.
Then the part that has no equivalent in a language model: every question in a request is evaluated in parallel and independently, against the same state, and one answer never becomes hidden context for another. Questions can be added or removed without changing the others’ results. So the natural unit of work stops being one careful question and becomes a batch of cheap ones.
TypeSafe has a name for what falls out of that, and a number attached. It calls the pattern speculative fan-out: ask every question the code might need, including the ones whose answers only matter for some inputs, and let the code throw away what it does not use. Per its own cookbook, batching thirteen questions into one call is 12.2 times cheaper and 10 times faster than thirteen separate calls, with no change in the answers - though the cookbook is explicit that the speed figure assumes the thirteen separate calls run one after another; fire them concurrently and the time gap shrinks, while the token cost does not. If the ticket is not a bug report after all, the severity answer is discarded and nothing was wasted, because asking it cost a few input tokens and nothing at all for output.
That inverts an instinct every team has built up over two years of LLM bills. The discipline has been: ask the minimum, trim the prompt, do not pay for what you might not need. Here the cheap move is to ask everything at once. A workflow that would have been four sequential model calls with parsing between them becomes one call and a block of ordinary branching code.
The second structural change is what the probabilities are for. Jev’s training method optimizes for calibration rather than for answers people prefer - TypeSafe’s own primer states it as a rule about rates: outcomes the model assigns a probability of 0.8 should occur about 80% of the time, across many predictions. Read that carefully, because the primer says so itself: those rates “describe groups of predictions, not a guarantee about any single answer.” A calibrated model can still be wrong on the case in front of you.
What calibration buys is a threshold that sorts reliably even when individual answers do not. Every Choice and Score answer carries a confidence score derived from how peaked the distribution is, and the docs give the pattern plainly: high confidence, act automatically; medium, ask the user to confirm or flag it for review; low, do not act at all - route it to a person or fall back to a different system. Their worked example puts a 0.5 floor under everything and raises the bar to 0.9 before a destructive action can go straight to confirm-and-execute instead of being sent back for verification, and the same page is careful to say those are illustrative rather than defaults: “Start with conservative thresholds, test with your own data, and adjust as you observe results.”
The sentence under all of it is one a lot of vendors would not print: “If an intelligent system, whether human or machine, cannot express honest uncertainty, the system cannot be trusted.”
That is the real unlock, and it is not about cost. A team can automate the confident slice of a decision and route the rest, and the boundary between those two lives in its own code as a number anybody can read, argue about in a pull request, and move when the evidence moves. That is a governable system. “Prompt the model and hope” is not.
Two limits to size the opportunity honestly. Jev reads text only - no images, audio or video yet - and there are two token budgets: 64,000 for the state plus every question combined, and 32,000, about 150,000 characters of English, for the state plus the single longest question. Neither is a small constraint if the plan involved documents or screenshots. Both are in the docs rather than the footnotes.
Where the benchmark is blind
One methodological fact governs every accuracy figure above, and TypeSafe states it in the open: “the reference labels are generated via an average of the responses of GPT-6 Astra and Claude Fable 5.1, both at high thinking, answering every question in the harness.”
The reference is not a verified answer. It is what two expensive models said. The launch post concedes which way that pushes - it “biases answers towards OpenAI and Anthropic’s models” - and adds that TypeSafe therefore likely underestimates its own model’s relative performance, and DeepSeek’s.
The consequence the disclosure stops short of drawing is the one that costs money. Where Astra and Fable 5.1 are both wrong, the benchmark scores the correct answer as an error. A blind spot the two frontier models share is invisible to this eval by construction, and shared blind spots are exactly where an automated decision goes expensive. The symptom is sitting in the ceiling: the best configuration in the table reaches 74.1%, so even the top scorer disagrees with the reference on a quarter of cases, and some of those disagreements are the reference being wrong.
That does not make “similar intelligence” a false claim. It makes it a claim about agreement. Agreement inherits its ceiling from the judges, and no price cut raises it.
What is still unverified, and it is narrower than the numbers suggest
The speed and the cost are not in doubt. Early access is out, developers are through the door, and the part anyone can confirm within an hour of getting a key - that structured decisions come back in a fraction of a second for a fraction of a cent - confirms cleanly. VarOps’s own runs land where TypeSafe says they land.
What remains open is the accuracy half, and it is worth being exact about which half that is. Every quality figure in this column is TypeSafe measuring its own model on four workflows its own team built; the company says those workflows sit outside its training distribution and were not built to flatter the model, and neither claim can be checked from outside. No independent reproduction of the 67.8% has been published. Neither has a rate limit, an SLA, or any statement of what free output pricing looks like at volume - and TypeSafe’s own position on durability is that it cannot prove the price is unsubsidized and expects it to fall rather than rise. That is a fair thing to say and not a thing anyone can bank a three-year plan on.
What would settle the open half is narrow and now genuinely cheap: run the four published workflows on your own account, MIT-licensed adapter for the LLM side, real access for the Jev column. Both halves of that are available this week, which is the sentence that could not have been written on Tuesday.
There is a smaller irony in the name. Jev is short for William Stanley Jevons, and TypeSafe says out loud that it expects his paradox to hold - that every order-of-magnitude fall in the cost of intelligence unlocks orders of magnitude more use for it, the way cheaper steam engines burned more coal rather than less. A company that names its model after the observation that cheap resources get consumed in greater quantity is not, on the record, forecasting a smaller bill.
Two moves
Sort the AI spending first, by who reads the output. Some of it produces prose a person reads: drafts, summaries, chat, code a developer reviews. The rest produces a judgment a program consumes and acts on - classify this ticket, score this claim, route this alert, extract these fields, take this branch. Only the second group can move to a decision model at all, and its size is the size of the opportunity. TypeSafe’s own comparison table draws that line, which is a useful thing to have made a vendor do.
Then, before pricing anything against a vendor’s multiple, restructure one of those workflows the way the eval describes and run it on the model already in the stack. Across four tasks and eight model configurations, TypeSafe measured gains between 5.1 and 35.5 accuracy points, with lower cost alongside. That experiment costs an afternoon, needs nobody’s permission, and returns a number about real work rather than somebody’s benchmark.
And when the multiple arrives - in a board deck, in a vendor pitch, in a forwarded homepage - the question that separates a measured number from a framed one is what the reference answer was. If the reference is a more expensive model’s own output, then the claim on the table is that the cheap model agrees with the expensive one. Often that is enough. But the error floor sits wherever the expensive model was already wrong, and no amount of cost saving moves it.
