Is Jev Really 193x Faster?

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

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 Fable one-decision row timed the first byte of the answer, which understates a thinking model. The October rerun below corrects it.

The top row and the bottom row sit 59-fold apart, and nothing about the model changed between them. The comparison did.

Is Jev 1.14 faster than 1.13?

Not in our timing: on 17 October 2026, over the same route, Jev 1.14 took 514 milliseconds of server time on a single decision and Jev 1.13 took 505. We alternated the two versions call by call, eleven times each. Both billed exactly the same tokens, so the cost did not move either.

The October rerun, same route, 17 October 2026

Medians. Server time with the network subtracted for single decisions, measured to the end of the response; wall clock for the six-judgment rows, as in September. Eleven runs per Jev version on one decision, five for Flash Lite and Haiku, three for Fable; five Jev runs and three Fable runs on six judgments. The ticket was rewritten for this rerun, so treat any comparison across the two dates as rough.

Across the two dates, on tickets of similar length, the baselines moved more than Jev did. Claude Haiku 4.5 took 1,537 milliseconds against 928 in September, which turns its 1.9x into 3.0x, while Jev held within 30 milliseconds of its September time. A single-call multiple is a reading on the day as much as on the model.

The Fable row grew for a second reason, and it corrects our own September table. We measured server time then as the wait for the first byte of the answer. On a long request OpenRouter sends bytes before the answer is ready, so a thinking model looked faster than it was. Our September wall clock for that row was 1.3 seconds longer than the network explains. This time we timed the whole response: Fable needs 5.4 seconds for one decision, and the gap to Jev is 10.5x rather than 5.4x.

The six-judgment comparison came in at 48x, against 100.7x in September. Fable thought before the first question and skipped thinking on the other five, the same failure that removed the GPT-5.6 Terra row further down. Six calls took 29.4 seconds and cost $0.051, against 74.42 seconds and $0.16251 in September.

Batching behaves the same on both versions. One, six, thirteen and twenty questions about the same ticket all came back in about half a second, 496 to 552 milliseconds of server time. Cost per judgment fell elevenfold, from $0.0000196 to $0.0000018.

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

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.

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.

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.

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.

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.

In October the same thing happened to Claude Fable 5.1, the baseline that had thought properly in September. Asked six short questions about a ticket with reasoning effort set to high, it thought on the first and answered the other five with zero reasoning tokens. A reasoning budget of 2,048 tokens did not change that. It answered "high" in three tokens. That is why the October workflow row reads 48x.

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.

The gap is wider on images. Reading a screenshot of an AI search answer, Jev 1.14 took about half a second against 1.4 to 3.9 seconds for three vision models, 3 to 7 times faster with no loss in accuracy.

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

Keep reading