TypeSafe says its Jev model runs 193x faster and 444x cheaper than a frontier language model. The comment threads called that marketing. We measured it on 18 September 2026. The number that comes back depends entirely on what you put on the other side of the comparison.
Swap one classification call and you get 1.7x. Collapse a six-step workflow into one call and you get 100x. Neither is a trick. The multiple is a property of the comparison, not of the model. Once you can see which knob moves it, you can work out what Jev would do to your own bill.
The short answer
Jev answered a single yes-or-no question in 477 milliseconds of server time. A cheap chat model took 790 milliseconds for the same question and a mid-sized one took 928. That is 1.7x and 1.9x, and it is the honest number for anyone planning to replace one classification call.
Then we ran the comparison the way TypeSafe runs it. Six judgments about one support ticket, made one after another by a model that thinks before it answers, against the same six judgments asked in a single Jev call. 74.42 seconds became 0.739. That is 100.7x faster and 7,499x cheaper, and it is also honest.
The same model, four comparisons, 18 September 2026
| What sits on the other side | Baseline | Jev 1.13 | Faster by |
|---|---|---|---|
| Gemini 3.1 Flash Lite, one decision | 790 ms | 477 ms | 1.7x |
| Claude Haiku 4.5, one decision | 928 ms | 477 ms | 1.9x |
| Claude Fable 5.1 thinking, one decision | 2575 ms | 477 ms | 5.4x |
| Claude Fable 5.1 thinking, six-step workflow | 74.42 s | 0.739 s | 100.7x |
Server time with the network subtracted for the first three rows, wall clock for the workflow row because the sequential calls include the round trips a real workflow would pay. Three runs each, median reported.
The top row and the bottom row sit 59-fold apart, and nothing about the model changed between them. The comparison did.
Where 193x comes from
TypeSafe's figures come from four evaluations it ran in house, on workflows it chose, against GPT-6 Astra and Claude Fable 5.1 with thinking turned on. Its launch post says the numbers are on the higher end of what it saw rather than a typical result.
Two details in that setup do most of the work. The baseline is a model that deliberates for several seconds before answering. The task is a workflow made of several linked judgments rather than one. A workflow costs a call per step; Jev costs one call for all of them.
Read the method in the launch post of 15 September 2026 before the multiple. The accuracy half of those evaluations scores each model against the average of two other models rather than against a correct answer. That is a separate problem we took apart in our own 108-claim accuracy run. The speed half does not have that problem. A stopwatch does not need an answer key.
The claim is aggressive and it is not fabricated. Every vendor picks a flattering comparison. Work out which parts of this one you would inherit and you have your own number.
How we measured it
Speed comparisons between hosted models are usually measurements of distance. A model whose servers sit further from you looks slower. Our first pass made that mistake and reported one route as faster than another when the only difference was geography.
So every model in this study was reached over the same route. Each request was split into the part spent travelling and the part spent thinking. We took the round-trip time from the connection handshake and subtracted it from the time to the first byte of the answer. What is left is server time: how long the model itself took.
The task was one question a real pipeline asks constantly. Here is a support ticket. Is it a billing problem, a technical problem or a request for a refund? One question, one answer, no writing.
One decision, server time with the network removed
| Model | Server time | Wall clock | Slower than Jev by |
|---|---|---|---|
| Jev 1.13 | 477 ms | 673 ms | 1.0x |
| Gemini 3.1 Flash Lite | 790 ms | 1164 ms | 1.7x |
| Claude Haiku 4.5 | 928 ms | 1293 ms | 1.9x |
| Claude Fable 5.1, thinking | 2575 ms | 3882 ms | 5.4x |
Wall clock includes the round trip, which was about 60 milliseconds for every row. Median of three runs.
Half a second against one and a half. Real, useful, and nowhere near 193x. If your plan is to move one classification call off a chat model, this is your row.
Notice what the honest number does to the pitch. A 1.7x speedup is worth having and it is not worth rebuilding a pipeline for. The reason to reach for a different instrument is almost never the stopwatch on a single call. That is why we check a draft against four or five models at once rather than racing one of them.
Six judgments in one call
Then we rebuilt the comparison the way TypeSafe frames it. One support ticket, six judgments about it. The category, the urgency, whether it needs a human, whether the customer is asking for money back, the sentiment, and whether it has been escalated before.
A chat model does that as six calls, one after another, each paying its own round trip and its own thinking time. Jev does it as one call, because the questions are independent and it evaluates them together.
Six judgments about one support ticket
| Approach | Latency | Cost |
|---|---|---|
| Six sequential calls to Claude Fable 5.1, thinking on | 74.42 s | $0.16251 |
| The same six judgments in one Jev call | 0.739 s | $0.00002167 |
| Difference | 100.7x faster | 7,499x cheaper |
One ticket, six judgments, three runs each. The cost gap here is wider than TypeSafe's own claim. That is because Fable 5.1 is at the expensive end of the models anyone would use as a baseline.
Our cost multiple came out larger than the 444x TypeSafe advertises, and that is not us being generous. We picked an expensive baseline. A cheaper model on the other side would have produced a smaller gap and a fairer one for most people.
The latency figure is where the batching does its work. We asked Jev 1, 6, 13 and 20 questions about the same document and the median time barely moved, from 0.660 seconds to 0.579. Cost per judgment fell elevenfold. A marginal question costs roughly fifteen tokens of input and no extra waiting.
What moves the multiple
Four things decide whether you see 1.7x or 100x, and you can read your own number off them before writing any code.
How many judgments collapse into one call
Six sequential calls become one, and six round trips and six thinking passes become zero. If your workflow is a single decision this knob is off and the multiple stays near 2x. If it is a chain of eight, it is most of your answer.
Whether the baseline thinks first
A model with extended reasoning turned on spent 2575 milliseconds where the same question took a fast model 790. Turning thinking on more than tripled the baseline and therefore tripled the multiple, before anything else changed.
What the baseline costs per token
Cost ratios move faster than speed ratios because model prices span two orders of magnitude. Our 7,499x came from comparing against a model priced at $10 per million input tokens. The same measurement against a cheap model would have shown a fraction of that.
Whether anything has to be written
Jev returns a value from a list you supplied. The moment one field of your output needs a sentence, that field goes back to a language model at language model prices. The multiple applies only to the share of the work that stayed typed.
The honest end of that range has been measured. A proof-of-concept routes the typed fields of a pipeline to Jev and leaves the free text on a language model. It reported 15.9 percent faster and 30.1 percent cheaper on support ticket triage in September 2026. It came to 1.958 seconds against 2.329, and $0.000263 against $0.000377 per ticket. That is the number for a pipeline that still has to write.
Run those four against your own workload and the answer stops being a slogan. A single classification against a cheap baseline lands near 2x. A chain of judgments against a deliberating, expensive one lands in three figures. Most systems sit in between.
Every model comparison hides the same second half: faster than what, on which task, against which baseline. A number with that half stripped off is not evidence, for the same reason a claim checked by one model is not checked.
The baseline that never thought
One row nearly went into the table above and should not have. We ran GPT-5.6 Terra with its reasoning effort set to high, intending a second thinking-model baseline, and it returned 618 milliseconds of server time. That would have been a 1.3x row: a deliberating model barely slower than Jev, which would have undercut the entire workflow finding.
The response reported zero reasoning tokens. On a task that small the model found nothing to think about. What we had measured was a fast model with an expensive setting that did nothing. Fable 5.1 on the same question reported 438 reasoning tokens, which is what a thinking baseline looks like.
The row is out of the study. We are describing it because a table with that row in it would have looked more rigorous than the table without it. It would have been wrong. If you are running this comparison yourself, read the reasoning token count on every thinking-model row before you believe it. Setting the flag is not the same as the model using it.
What other people measured
Other people timed it in the same week, and they disagree with each other in exactly the way this article predicts.
Mike Taylor, writing at Every on 15 September 2026, ran eleven experiments and reported a median of 0.35 seconds per passage for Jev against 8.83 seconds for Claude Fable 5.1 at high effort. The estimated cost was about 580 times lower. That is roughly 25x on speed. His baseline was a deliberating model, like TypeSafe's, on a passage-level task rather than a workflow. So his number sits between our 5.4x and our 100.7x.
People running open reimplementations on their own hardware report 200 to 500 milliseconds per decision. One developer routing an agent through the hosted model measured 145 and 271 milliseconds end to end, including the network. Those figures come from people who think the marketing is overstated, which is what makes them worth citing. They also suggest our 477 milliseconds carries some overhead from the route we used, so the underlying model is likely faster than we measured.
Line the readings up and the pattern is clean. Single decision against a fast model, under 2x. Single decision against a deliberating model, 5x. Passage-level task against a deliberating model, 25x. Multi-step workflow against a deliberating model, 100x and up. Nobody is lying. Everybody is measuring a different thing and dropping the second half of the sentence.
Which number to use
If you are replacing a single classification call in an existing pipeline, plan on 1.7x to 1.9x on latency. Expect somewhere between eight and sixty times cheaper, depending on which model you are taking the work off. That is the conservative case and it is the one most teams are actually in.
If you are collapsing a chain of judgments that runs today as separate calls, the three-figure numbers are reachable. The saving is the round trips and the thinking passes you stop paying for. Price any part that has to be written in words at language model rates, and apply the multiple only to the rest. A pipeline that is half typed decisions and half prose does not get a 100x anything.
And the speed question is separate from whether the answer is right. We measured that too, on 108 claims across six domains, and the result was more interesting than the stopwatch: the widely repeated calibration advantage is not there. A real accuracy gap shows up on the hard claims. A faster checker that is wrong just publishes the mistake sooner, which is the failure our whole argument about single-model checking is built around.
Frequently Asked Questions
Is TypeSafe's 193x faster claim real?
Yes, for the comparison TypeSafe makes. Its figure comes from in-house evaluations of multi-step workflows against frontier models with extended reasoning turned on. Its launch post describes the numbers as being on the higher end rather than typical. When we reproduced that shape, six sequential judgments about a support ticket against one batched Jev call, we measured 100.7x faster and 7,499x cheaper. When we compared a single classification call instead, we measured 1.7x. Both are correct measurements of different things.
How fast is Jev on a single decision?
477 milliseconds of server time in our test on 18 September 2026, against 790 for Gemini 3.1 Flash Lite and 928 for Claude Haiku 4.5. That is 1.7x and 1.9x. Developers running open reimplementations on their own hardware report 200 to 500 milliseconds per decision. TypeSafe's documentation says most queries finish in about 100 milliseconds. So the underlying model is probably faster than our figure, which includes the overhead of the route we reached it through.
Why do Jev speed benchmarks disagree so much?
Because they use different baselines. Four things move the multiple: how many separate judgments collapse into one call, whether the baseline model thinks before answering, and what the baseline costs per token. The last one is whether any of the output has to be written as text. Published readings range from about 1.7x to over 190x, and the range is almost entirely explained by those four choices rather than by disagreement about Jev itself.
Why is Jev so much cheaper than a language model?
It does not generate text. Input is billed at $0.042 per million tokens and output is free, because there is almost no output to bill. The model returns a value chosen from a list you supplied rather than a sequence of tokens it composes. A language model bills you for every token it writes, and a model with reasoning turned on bills you for the tokens it writes while thinking, which you never see.
Does batching questions into one Jev call actually help?
It is where most of the advantage lives. We asked the same document 1, 6, 13 and 20 questions and the median response time barely moved, from 0.660 seconds down to 0.579. Cost per judgment fell about elevenfold across that range. Each extra question adds roughly fifteen input tokens and no measurable waiting, because the questions are evaluated together rather than one after another.
How do I know a thinking model baseline actually thought?
Read the reasoning token count in the response, not the flag you set in the request. We ran GPT-5.6 Terra at high reasoning effort on a single classification and it returned zero reasoning tokens, meaning reasoning never engaged. Its 618 millisecond result would have looked like a fast thinking model and would have been meaningless. Claude Fable 5.1 on the same task reported 438 reasoning tokens, which is what a valid thinking baseline looks like.
How do you compare hosted model latency fairly?
Reach every model over the same route and subtract the network. Take the round-trip time from the connection handshake and subtract it from the time to the first byte of the response. What remains is server time. Without that step you are partly measuring how far each vendor's servers sit from your machine. Our first pass reported one route as faster than another when the only real difference was geography.
Can Jev replace a language model in my pipeline?
Only for the parts that return a typed value from a fixed set of options. As soon as one field needs a sentence, that field goes back to a language model at language model prices. The overall saving shrinks to whatever share of the work stayed typed. A public proof-of-concept routes only the typed fields of a support ticket triage pipeline to Jev. It reported 15.9 percent faster and 30.1 percent cheaper in September 2026, 1.958 seconds against 2.329 per ticket. That is the realistic end of the range for a pipeline that still has to write.
Is Jev less accurate than the models it replaces?
Not on the task we measured. Over 108 hand-labelled grounding claims across six domains, Jev answered 96.3 percent correctly against 94.4 percent for Gemini 3.1 Flash Lite and 93.5 percent for Claude Haiku 4.5. The separation came entirely from the hardest claims. It cannot settle whether a claim is true in the world, though. Asked to adjudicate facts with no source in front of it, it declines rather than guessing.
Keep reading
Is There a Most Accurate AI Model?
The honest answer is no. The ranking changes with the task, the benchmark, and the month, and even the leader still hallucinates.
Why AI Is Confidently Wrong
Models sound certain every time, even when wrong, and the confident tone you trust in people is worthless here. Here is the fix.
Should You Stop Using ChatGPT?
Researchers found AI made experts measurably worse on hard tasks. Here is when to trust ChatGPT, and when it is just telling you what you want to hear.
AI Hallucination Rates in 2026: What the Data Actually Shows
A sourced reference of the 2026 hallucination-rate numbers. What each benchmark measured. Which models did best and worst. And where the widely quoted figures get misread. Built to be linked and kept current as new data lands.
TrueStandard vs Parafact
Both verify claims before you publish. The real difference is what one model can miss, and whether your long-form draft fits inside the check at all.
A faster wrong answer is still wrong
Speed is the easy half of a checker. TrueStandard runs your draft past four or five models in parallel and shows you every claim they disagree on. The claims one model waves through are the ones that reach your readers.
Start Verifying →