The Jev + Claude Code Stack: How to Build Agents That Are 200x Faster and 400x Cheaper

You've probably seen the number floating around. "200x faster. 400x cheaper." It sounds like marketing copy written by someone who's never shipped a production agent in their life.

Here's the correction nobody's making: those numbers are real, but they're a ceiling, not a typical result. Jev's own published range is 20 to 200x faster and 40 to 400x cheaper depending on the task. The honest framing matters because if you build expecting the top of that range on every call, you'll ship something broken and blame the tool.

I'm going to show you what's actually happening under the hood, where the real multiplier comes from, and how to wire Jev into a Claude Code agent so the speed gain shows up in your architecture instead of in a tweet.

The Core Insight: Two Different Jobs Being Done By One Tool

Every agent you've built with Claude Code does two fundamentally different jobs, and it does both of them with the same tool. That's the actual problem.

Job one is generation. Write this function. Draft this email. Summarize this document. Generation needs a language model because the output space is unbounded. There's no fixed list of valid emails.

Job two is decision. Is this test passing or failing? Should this PR get merged or blocked? Is this customer support ticket urgent or not? Decisions have a bounded, typed answer space. Yes or no. One of five categories. A score from 0 to 1.

Claude Code, like every agentic coding tool right now, routes both jobs through the same generative model. You ask Claude "does this code pass review," and it generates text that happens to express a decision. That's expensive and slow for what is structurally a classification problem, not a writing problem.

Jev, built by Diogo Almeida (one of the original ChatGPT co-inventors, now running Typesafe AI on a $40M seed led by DCVC), was built specifically for job two. It never generates text. You give it unstructured state (a diff, a log, a transcript, a document) plus a set of typed questions, and it returns probability-scored answers to all of them in parallel. Not "here's what I think," but confidence-scored classification against a schema you defined.

The mechanism is called RLCD, reinforcement learning for calibrated decisions. It's trained to be right and to know how confident it should be about being right, which is a different optimization target than "produce fluent, helpful-sounding text."

That difference in training objective is where 70 to 500ms response times come from, against 3 to 329 seconds for chat models doing the equivalent classification task by generating reasoning text first. That's also where $0.042 per million input tokens with free output comes from. You're not paying for token generation because there isn't any. You're paying to run a classifier.

Where The Real Multiplier Actually Comes From

Here's the part most people writing about this stack get backwards. The 200x number doesn't come from Jev being 200x faster than Claude at the same task, measured head to head, one call versus one call.

It comes from decision density. In a real agent loop, most of the "thinking" a language model does isn't creative generation. It's checking things. Did the last step succeed? Is this the right file to edit? Does this response satisfy the constraint I was given? Should I retry, escalate, or continue?

Look at a typical Claude Code session doing something moderately complex, a multi file refactor with tests. I counted the decision points in a session I ran last week fixing a 340 line auth module: 31 distinct yes/no or categorical checks across the run. Things like "does this diff introduce a type error," "did the test suite pass," "is this the correct import path," "should this be flagged for human review."

Every one of those 31 checks, in a standard Claude Code run, gets routed through the full model. Claude generates a paragraph of reasoning, then a conclusion, for a question that has exactly two or three valid answers. You're paying full generation cost and full generation latency for a classification.

If you pull those 31 decisions out and route them to Jev instead, you're not making one call faster. You're removing 31 full-cost generation calls from the loop and replacing them with 31 calls that cost a fraction of a cent and return in under half a second. The multiplier compounds because it's happening at every decision point, not once.

This is the actual mechanism behind the ceiling numbers. A workflow with a high ratio of decisions to generations gets close to 200x. A workflow that's almost entirely generation (writing a long document from scratch, say) gets nowhere near it, because there's nothing to offload.

Building The Architecture

Here's how you actually wire this into a Claude Code agent. Three steps.

Step 1: Audit your decision points

Before touching code, go through an existing agent transcript and mark every place the model is being asked a bounded question instead of being asked to generate something. I use a simple template for this:

DECISION POINT AUDIT

Location: [where in the loop] Question asked: [verbatim] Answer space: [bounded / unbounded] Current cost: [tokens, latency] Candidate for Jev: [yes/no]

Example: Location: post test-run check Question asked: "Did the test suite pass, and if not, is the failure related to my change?" Answer space: bounded (pass / unrelated fail / related fail) Current cost: ~800 tokens, ~4.2s Candidate for Jev: yes

Run this against a real transcript, not a hypothetical one. You'll find the density is higher than you expect. In agent loops with a validation or review step, I typically find 25 to 40% of total model calls are decisions wearing a generation costume.

Step 2: Define the typed schema

Jev takes unstructured state and a set of typed questions. The request structure looks like this:

{ "context": "<diff, log, or document as raw text>", "questions": [ { "id": "tests_pass", "type": "boolean", "prompt": "Did all tests in this run pass?" }, { "id": "failure_category", "type": "categorical", "options": ["unrelated_flake", "related_to_change", "environment_issue", "none"], "prompt": "If tests failed, what category does the failure fall into?" }, { "id": "confidence", "type": "score", "range": [0, 1], "prompt": "How confident is this classification given the available context?" } ] }

You get back scored answers for every question in one round trip, in parallel, not sequentially. That parallelism is part of the speed gain too. A chat model answering three related questions usually does it as one long generation, sequentially reasoning through each. Jev scores them together.

Step 3: Route inside the loop

This is the part that actually changes your architecture. Instead of every decision point calling Claude, you insert a router:

def route_decision(question_type, context, schema): if question_type == "bounded_classification": result = jev.query(context=context, questions=schema) if result.confidence >= CONFIDENCE_THRESHOLD: return result.answer else: # fall through to Claude for ambiguous cases return claude_code.decide(context, schema) else: return claude_code.generate(context)

That fallback line matters more than it looks like it does. I'll come back to it.

A Full Worked Example: A Code Review And Fix Loop

Here's a before and after on something concrete: an agent that reviews a PR, decides if it needs changes, and if so, fixes and reruns.

Before, standard Claude Code loop:

1. Claude reads the diff, generates a review (full generation, ~1,400 tokens, ~11s)

2. Claude reads its own review and generates a verdict: approve, request changes, or escalate (~600 tokens, ~5s)

3. If request changes, Claude generates the fix (full generation, appropriate use of the model)

4. Claude reruns tests, then generates a pass/fail interpretation of the test output (~500 tokens, ~4s)

5. Claude generates a final categorical decision: merge, retry, or flag for human (~450 tokens, ~4s)

Total non-generation overhead across steps 2, 4, and 5: roughly 1,550 tokens and 13 seconds, on every single PR, for three decisions that each have three or fewer valid answers.

After, with Jev routing:

1. Claude reads the diff, generates the review. Unchanged, this is genuinely generative work.

2. Step 2 becomes a Jev call: context is the review text, questions are {verdict: categorical[approve, request_changes, escalate], confidence: score}. Response in ~300ms.

3. If request changes, Claude generates the fix. Unchanged.

4. Step 4 becomes a Jev call on the raw test output: {tests_pass: boolean, failure_related_to_change: boolean}. Response in ~250ms.

5. Step 5 becomes a Jev call: {action: categorical[merge, retry, flag_human], confidence: score}. Response in ~280ms.

Steps 2, 4, and 5 go from roughly 13 seconds and 1,550 tokens to roughly 0.83 seconds and effectively free output (you pay input only, at $0.042/M). On a team running 40 to 60 PRs a day through an agent like this, that's not a rounding error. It's the difference between an agent loop that feels sluggish in CI and one that returns before the person has switched tabs.

Notice what didn't change: the two actual generation steps, the review and the fix, stayed on Claude. That's the whole point. You're not replacing Claude Code. You're taking the classification weight off it.

Where This Genuinely Approaches The 200x Ceiling

The ceiling numbers are real in a specific and narrow band: high frequency, low ambiguity, tightly bounded decisions, run at volume. Think:

Triage queues. Is this support ticket urgent, standard, or spam, run against thousands of tickets a day. CI gating. Pass, fail, flaky, run on every commit across a large monorepo. Content moderation style filters. Does this output violate a fixed policy, run on every generation before it ships. Multi agent handoff routing. Which of five specialist agents should take this task, run at the top of every workflow.

These are cases where the decision is asked thousands of times a day, the schema barely changes, and the cost of a wrong classification is low enough that a confidence threshold and fallback catches the edge cases. That's where 200x is a real, measured number, not a marketing ceiling.

Where This Doesn't Help, And Where Forcing It Backfires

This is the part the "200x faster" tweets never mention, and it's the part that actually determines whether your stack works.

Jev cannot hallucinate free text, because it never generates any. But it can absolutely select the wrong option within a valid schema. If your categories are ambiguous, or your context is incomplete, Jev will still return a confidently scored answer, because giving you a confidence-scored answer is what it's built to do. A bad schema doesn't produce an error. It produces a wrong answer that looks exactly as clean as a right one.

I learned this the expensive way on a version of this content pipeline I ran for RankNow, where I initially set up a categorical decision with four overlapping categories (something like "high priority," "urgent," "needs review," "flag") that weren't actually mutually exclusive. Jev returned confident, fast, cheap answers that were internally inconsistent about a third of the time, because the schema itself was broken, not the model. Fixing that cost me about six hours of relabeling and rewriting questions, which is a real cost I'm naming rather than glossing over.

Don't use this stack for:

Anything where the "decision" is actually a judgment call requiring nuance a fixed schema can't capture (is this writing good, is this argument persuasive). Low volume, high stakes decisions where the setup cost of a typed schema exceeds what you'd save (a decision you make five times a month doesn't need this). Anything generative. Don't try to force Jev to write, summarize, or explain. That's not what it does, and trying to bend a classifier into a writer will just give you a worse writer than Claude. Early stage workflows where your categories are still changing week to week. A schema that's still being discovered isn't ready to be offloaded.

Setting Up Verification Given Jev's Real Limitation

Since the failure mode is a confidently wrong answer inside a valid schema rather than an obvious hallucination, you need a verification layer that doesn't rely on the output looking wrong, because it won't.

The fix is the confidence threshold from the routing code above, but tuned properly:

CONFIDENCE_THRESHOLD = 0.87 # tune per decision type, not globally

def route_decision(question_type, context, schema, decision_id): result = jev.query(context=context, questions=schema)

if result.confidence \< CONFIDENCE\_THRESHOLD:
    # escalate to Claude, which reasons through ambiguity better
    return claude\_code.decide(context, schema)

if decision\_id in HIGH\_STAKES\_DECISIONS:
    # sample a percentage even above threshold, for drift detection
    if random.random() \< 0.05:
        shadow\_check = claude\_code.decide(context, schema)
        log\_disagreement(result.answer, shadow\_check, decision\_id)

return result.answer

Two things matter here. First, the threshold isn't global. A merge/retry/flag decision and a spam/not-spam decision have different acceptable error rates, so they get different thresholds, set by measuring actual disagreement rates against Claude on a sample, not by guessing a round number.

Second, the shadow check on high stakes decisions. Even above threshold, running a small percentage of decisions through Claude in parallel (not blocking, just logged) is how you catch schema drift before it becomes a pattern of silent bad decisions. I run this at 5% on anything that touches a merge or a customer facing action. It costs almost nothing at that sampling rate and it's caught two schema drift issues in the last month that would otherwise have gone unnoticed for weeks.

Cost Modeling The Real Stack

Rough numbers, based on the PR review loop above, run at 50 PRs a day:

Old cost (decisions routed through Claude): roughly 1,550 tokens x 50 PRs x $50/M output-weighted average (mixed input/output) lands around $4 to $6 a day just on the classification overhead, before you count the actual generative review and fix work.

New cost (decisions routed through Jev, generation stays on Claude): the Jev portion drops to input-only cost at $0.042/M, which on the same volume is well under a dollar a day. The generative steps (review, fix) are unchanged because that work never moved.

The saving isn't in the total bill for the loop, it's specifically in the classification tax you were paying without realizing it was separable. On a workflow with heavy decision density run at real volume, that tax was often 25 to 40% of total spend for close to zero% of the actual value, since nobody's paying for an agent because it can tell pass from fail faster. They're paying for the fix.

Common Mistakes Building This Stack

1. Routing generation to Jev because it's cheap. It will return an answer. It will be a bad one, because you're asking a classifier to write. Cheap and fast isn't the same as correct for the wrong tool.

2. Setting one global confidence threshold. Different decisions carry different costs when wrong. A misrouted support ticket and a merged bad PR are not the same risk, and one threshold for both means you're either too loose on the risky one or too strict on the cheap one.

3. Skipping the schema audit and shipping ambiguous categories. Overlapping or unclear categories are the single biggest source of silent errors in this stack, and they won't show up as errors. They'll show up as a slow drift in decision quality that's hard to trace back to its source.

4. Never sampling for drift. Confidence above threshold doesn't mean correct, it means the model is sure. Sure and correct diverge over time as your inputs shift, and without a shadow check you find out from a downstream failure instead of a log line.

5. Treating the 200x number as a target instead of a description. It describes what happens in the narrow band of high volume, low ambiguity, bounded decisions. Building toward that number on a workflow that doesn't fit the band means bending your architecture around a stat instead of your actual problem.

The Actual Skill This Stack Requires

None of this is about Jev being a smarter tool than Claude Code, and it isn't a replacement for it either. The skill is decomposition. Looking at an agent loop you already built and asking, honestly, which parts of it are actually generation and which parts are classification wearing a generation costume.

Most people building agents right now route everything through one model because that's the default, and the default works well enough that nobody stops to check where the cost is actually going. The teams getting real multipliers out of this stack aren't the ones with a better prompt. They're the ones who did the decision audit first, found the 25 to 40%, and moved only that.

If you want to go deeper on this kind of agent architecture work, on getting Claude Code and complementary tools like Jev actually wired together instead of just stacked on top of each other, follow @cyrilXBT. I break down stacks like this one as I build and ship them, not after the fact.