Build1 publisher3 min readPublished
A strict enum schema on the baselines erased most of Jev's 14x decision-latency lead
TypeSafe's Jev answers typed questions in one forward pass with no token stream, and a dev.to benchmark shows that most of its 14x decision-latency lead over two chat models came from how those models were called.
The Engineer · Build desk
What happened
- A dev.to post times agent loop steps and finds a one to three second pause and a few hundred tokens spent to transmit a value between 1 and 30 before each small action.
- In a 20-second three-lane demo with the same three-option question, Jev made 86 decisions, claude-haiku-4.5 made 6 and gemini-3-flash 3, all called the way agent loops usually call them.
- The cost gap survived the reconfigured comparison: 5x cheaper than the constrained Gemini call and 16x cheaper than the constrained Haiku one.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision The cheap change needs no new vendor. Pin the enum, cap the tokens and turn the thinking off on the model you already call, and by the post's own measurement most of the gap closes.
- constraint A judge that answers without explaining cannot take over the steps that produce writing, so the split between decision steps and text steps has to be maintained by hand as the loop changes.
- exposure With no self-hosted option, adopting the judge puts page DOM, command output and pending shell commands in front of a third-party API. That makes this a security review before it is a latency decision.
- contradiction The 14x demo and the 3x fixed run describe the same three models, so which figure applies to a team depends on how its router calls are configured now.
Jev's speed comes from answering in a single pass. It takes a state plus typed questions - yes/no, pick-one, rate - and returns answers with confidences in a single forward pass [5]. The author's plugin, jev-use, routes the steps that only produce a decision to Jev and leaves the language model everything that produces writing [9][3]. In the 20-second lane demo, 86 decisions works out to about 233 ms each, against roughly 3.3 s per claude-haiku-4.5 decision and 6.7 s per gemini-3-flash one [1][2].
The 14x that falls out of those counts [3] is the figure the post declines to stand behind. The author re-ran both baselines with strict JSON-schema enum output and thinkingBudget: 0 for Gemini, 40 fresh states per arm, twice, and the latency lead came back at 3x [15][16]. Per decision, the two chat models got about 4.8 times faster from configuration alone [4].
Both settings do the obvious thing. An enum schema restricts the output to the option set, and a zero thinking budget removes the deliberation pass; the post names that fix up front - constrain the output to an enum, cap the tokens, turn the thinking off - and says it is "worth most of the gap" [20]. The author also says to take the demo recording as a feel for decision latency and not as a model comparison [14].
For the 3x to mean anything in your loop, decision steps have to be a large share of wall clock, and your states have to resemble the ones in the harness: a CI run summary, a page DOM, a shell command waiting for approval [7]. The sample is 80 states per arm [5], gathered by the author of the plugin that routes to Jev [9]. That does not disqualify the numbers, but it does make them a claim about his states. The scripts in bench/examples/ are re-runnable with your own key [19].
The escalation branch is the part I would keep even if the latency lead were zero. Anything Jev can't or shouldn't decide comes back with escalate: true and a typed reason, and unreachable never resolves to a default answer [11]. On the question of whether a shell command is safe to run, the author wrote that "a judge that can't be reached hands the question back, it does not wave the command through" [12]. A pick returns the option, a confidence and that flag; 0.93 and false in the post's worked example [22]. The answer sits inside the option set by construction instead of being parsed back out of prose [18].
The cost gap survived the reconfigured comparison: 5x cheaper than the constrained Gemini call and 16x cheaper than the constrained Haiku one [17]. Three questions about one state ride one call and latency is flat in the number of questions, so there is no reason to ask them one at a time [10]. The constraints are stated in the post: Jev is API-only through TypeSafe direct, OpenRouter or the Vercel AI Gateway, with no self-hosted path [6]; "It answers, it does not explain" [8]; and it was four days old when the post ran, as is the tooling around it [4][21].
What to watch
- A self-hosted Jev path would remove the data-residency question that API-only access forces today.
- An independent re-run of bench/examples on someone else's states would show whether the 3x latency lead and the 5x and 16x cost gaps transfer.
- Whether agent frameworks start shipping enum-constrained, zero-thinking defaults on their own routing calls.