Replacing Your LLM with Jev: 10 Places Where the Migration Pays for Itself in a Week

The most expensive task in your pipeline is probably also the dumbest one: deciding whether a ticket is about billing or a bug. You're paying for a frontier model to do that.

This post assumes you already know what Jev is and how to call it. If you don't, start with Jev: the AI model that doesn't write anything and come back. The topic here is different: where replacing an LLM with Jev moves the bill enough to justify the work, what each case costs before and after, what the real payload looks like, and under what conditions the migration isn't worth it.

Ten Jev use cases. Each one with a number, not an adjective.

TL;DR

• What it is: a decision catalog. Ten tasks that run on an expensive LLM today and fit Jev's three primitives (Choice, Score, Noul).
• The combined math: one million calls in each of the ten cases costs $46,200 on the LLM and $523 on Jev. A factor of 88x, with the payload for each case described below.
• The break-even point: two days of dev time (call it $600) pay for themselves in ~180k calls of the most common case. Handling 25k tickets a day? The migration paid for itself by Friday.
• The pattern that matters: cascade. Jev up front filtering, the expensive LLM only on what's left: $6,480 versus $30,400 per million tickets, a number published by TypeSafe itself.
• Where it's not worth it: cutting classification costs with AI has a clear limit: generation, arithmetic and dates, decisions that need a written justification for audit, and low-volume complex reasoning.
• Useful links: Jev announcement, hands-on guide with the patterns, integration in the LangChain harness.

The 30-second test: does the question fit a choice, a score, or a yes/no?

The question of when to use Jev instead of an LLM fits into a three-question filter, and you can answer all three before your coffee gets cold.

1. Is the answer space closed and known before the call? If the answer is one of N options (up to 255), a score on a scale of 2 to 10 levels, or a yes/no probability, it fits. If the answer is text that only exists after the model writes it, it doesn't. There's no middle ground here: Jev doesn't generate. That constraint is what gives you the type guarantee.

2. Can the required state be assembled in code? Jev reads only what you send it. It doesn't fetch anything, doesn't call tools, doesn't know what day it is. If the decision depends on data you'd have to go get, that's your job: fetch it in code, build the state, ask. That's not a flaw, it's the architecture — and it's what forces you to know which data the decision actually depends on.

3. Does the volume justify it? The savings per call are on the order of three thousandths of a dollar. That's dust. At ten thousand calls a month you save thirty dollars and you spent two days migrating. The migration is a volume decision, always.

If all three answers are yes, keep going. If any of them is no, the Jev-or-LLM fight is already settled in the LLM's favor and the rest of this post is trivia.

You can answer those three questions on your own in half a minute. The hard part comes after: deciding where the cheap option breaks in production, which case migrates first, and which one stays.

You can learn that on your own. It's just slower, and there's nobody reviewing your confidence threshold before it turns into a production incident. That's the gap the Clã Beer and Code closes: implementation happening live, senior people looking at the trade-off the moment it shows up, and someone holding you to a pace so the migration actually leaves the draft stage. It's paid, it's a subscription, and it's this post in the form of an environment.

Where to replace an LLM with Jev: the 10 cases with the before-and-after math

Baseline first, because a cost table without explicit assumptions is advertising:

• LLM ("before" column): $4 input and $20 output per million tokens — the range of a mid-tier frontier model today. If you run top of the line ($10 / $50), multiply the "before" column by 2.5.
• Jev ("after" column): $0.042 per million input tokens, output free. You pay for the state plus the questions, and that's it.
• Unit: cost of one million calls, one call per item. The payload sizes for each row are described in that case's block.

Before going case by case, an honest caveat: if your pipeline already does prompt caching well, the "before" column drops. In case 1, with cache reads at $0.40/MTok, the $3,400 becomes $880 per million. That's still 22x the cost of Jev, but the pitch shifts from "absurd" to "worth it." If you haven't done that part yet, start with the most common token leaks — switching models to fix wasted context is changing the tire to fix an engine noise.

1. Ticket triage — $3,400 → $40

The canonical case. The subject plus the last three messages go in as state, and you ask everything at once:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

r = client.system_one(
    state={
        "ticket": {
            "subject": "Cobrança duplicada",
            "messages": [
                {"from": "customer",
                 "text": "Fui cobrado duas vezes no pedido A-104. Quero o estorno."},
            ],
        },
        "order": {"id": "A-104", "charges": [
            {"amount_brl": 249, "status": "captured"},
            {"amount_brl": 249, "status": "captured"},
        ]},
        "refund_policy": "Cobrança duplicada é elegível a estorno.",
    },
    questions={
        "fila": Choice(
            instructions="Qual time deve atender este ticket",
            criteria={
                "billing": "Pagamento, cobrança ou assinatura",
                "tecnico": "Bug, erro ou problema de integração",
                "vendas": "Preço, plano ou conta comercial",
            },
        ),
        "frustracao": Score(
            instructions="O quanto o cliente parece frustrado",
            criteria=["Calmo, só relatando", "Irritado mas civil", "Muito bravo"],
        ),
        "pede_estorno": Noul(instructions="O cliente está pedindo estorno explicitamente"),
        "politica_cobre": Noul(instructions="A política de estorno citada cobre este caso"),
    },
)

print(r.answers["fila"].choice, r.answers["fila"].confidence)

Four questions in a single pass. On an LLM that would be one call with JSON output and a retry whenever the schema broke; here the speculative fan-out costs extra input tokens and almost no latency — 12.2x cheaper and 10x faster than the sequential version, per the official guide's number.

Not worth it when: the ticket needs a written reply in the same step. The LLM is getting called anyway, and Jev's gain disappears — unless you use the cascade pattern further down.

2. Content moderation — $1,100 → $11

Short comment, three or four Noul in parallel (spam, personal attack, exposed sensitive data, off-topic). It has the best factor on the list because the payload is tiny and the answer is binary by nature.

Not worth it when: you need to give the user the reason for the removal in text. Jev says "0.87 probability of personal attack"; it doesn't write the justification. Either you have fixed text per category, or you call a generator afterward — and then only on the rejected cases, which are few.

3. Guardrail on another LLM's output — $3,600 → $38

This is the case where the latency number matters more than the cost number. A guardrail runs inline, in the response path: every second it spends is a second the user waits. Swapping a 2-to-4-second LLM judge for a 70-to-500 ms check changes the experience, not just the bill. The state carries the generated response plus the policy; the questions are Noul for "leaked another customer's data," "promised something outside the policy," "answered in the wrong language."

LangChain documented this pattern as middleware that intercepts a dangerous tool call before it executes, with AutoModeMiddleware in create_agent — it's in their post.

Not worth it when: it's a compliance guardrail and someone needs to read later why the response was blocked. See the section on the four wrong tasks.

4. Session tagging — $9,200 → $101

Classifying whole conversations after the fact: topic, whether there was abandonment, whether the user got what they wanted, whether a feature request came up. It's the case with the largest absolute savings in the table, because the payload is big and the volume is every session in the product.

Engineering detail: summarize or trim the session in code before sending it. Sending 20k tokens of raw transcript doesn't just multiply the cost by ten, it tanks accuracy — the official guide calls this context rot, and the recommendation is to filter first and send only the fields the question needs.

Not worth it when: you want a summary of the session along with it. A summary is generation.

5. Pre-RAG filter — $1,800 → $22

Binary rerank: for each retrieved chunk, one Noul for "this passage answers the question." Cost is per chunk, not per query — so watch out, if you retrieve 20 chunks per query, one query is 20 calls. Even so, the fan-out comes to $0.0004 per query.

The real win isn't the cost of the filter: it's what it removes from the prompt of the LLM that comes next. Cutting 12 irrelevant chunks out of a 16k-token context saves more on the generator than the entire filter cost.

Not worth it when: your current reranker is already a local cross-encoder. You're already paying almost nothing and winning on latency — leave it alone.

6. Lead scoring — $5,800 → $65

Three independent Score questions (ICP fit, urgency, decision-making power) and the weighting done in code:

a = r.answers
composite = (
    0.40 * (a["fit_icp"].score / 4) +
    0.35 * (a["urgencia"].score / 4) +
    0.25 * (a["poder_decisao"].score / 4)
)

This beats asking the model for the final score, and not just on price: with the dimensions separated you can change the commercial weighting without touching the prompt, and you can explain why the lead scored 0.72.

Not worth it when: you already have labeled conversion history. With real labels, gradient boosting on top of the tabular features beats the language model, costs nothing, and you can audit it. Decision AI shines where the signal is in the text, not where a table already exists.

7. Churn detection — $6,800 → $76

Same logic as the lead, signal flipped: 90 days of events summarized in the state, Noul for "mentioned a competitor," "complained about price," "stopped using the core feature," and a risk Score.

Not worth it when: the churn signal is purely behavioral (logins, feature usage, late payments). That's a SQL query, not AI. Use Jev on the text part — tickets, emails, open-ended NPS — and join it with the behavioral side in code.

8. Automated eval — $8,800 → $97

A rubric broken into one Score per dimension, exactly the way you'd already do it with LLM-as-a-judge. The math changes enough that you can run evals on every commit instead of once per sprint — which is the whole point of having evals for AI agents.

One strong caveat: Jev is poorly calibrated. The benchmark published by Laya measures an ECE of 0.246 for Jev versus 0.081 for Laya itself — the number that comes out is not a trustworthy probability in absolute terms. As a ranking (which 50 cases got worse since yesterday) it works very well. As an absolute metric on your dashboard, it doesn't. Both sides of that measurement are in the Laya vs Jev comparison.

Not worth it when: the judge needs to write the comment that goes with the score. An eval that turns into a report for a human to read is still an LLM job.

9. Bug severity classification — $4,200 → $50

Stack trace plus title plus deploy context go in; out comes a Choice from P0 to P3, a Noul for "has repro steps," and a Noul for "affects payments." The good part is the confidence: you trigger the pager automatically only when the P0 comes in with confidence above your threshold, and send the rest to human triage.

Not worth it when: severity depends on counting things — "how many customers affected," "for how many minutes." Jev doesn't do arithmetic and doesn't count dates. You compute that number in code and put it already computed inside the state.

10. Model routing (which is not intent routing) — $1,500 → $23

Pay attention to the distinction, because both things get called "routing" and they're not the same:

• Intent routing decides what the agent is going to do — which flow, which tool, which sub-agent. That topic already has its own home on this blog: intent classification with an LLM and agent routing, with fallback policy and decision tracing. I'm not going to rewrite it here.
• Model routing decides who handles the call — the cheap model or the expensive one. The output isn't a business route, it's a model name.

Case 10 is the second one. A complexity Score and a Noul for "needs multi-step reasoning" in front of the request, and the request goes to the small model or the big one. The $23 in the table is only the cost of the router; the real savings are in what it avoids — sending 70% of traffic to the cheap model in a pipeline that today sends 100% to the expensive one cuts the bill in half, and the router cost you dust.

Not worth it when: your traffic is homogeneous. If every request is hard, the router just adds latency and a point of failure.

The cascade pattern: Jev up front, the expensive LLM only on what's left

None of the ten cases above has to be an "either/or." The pattern that pays back fastest is layered: Jev decides at the door and most requests never reach the expensive model.

def handle(message):
    r = client.system_one(
        state=message,
        questions={
            "assunto": Choice(instructions="Sobre o que é o pedido", criteria={...}),
            "complexidade": Score(instructions="O quanto o pedido é complexo",
                                  criteria=["Trivial", "Médio", "Difícil"]),
        },
    )

    assunto = r.answers["assunto"]

    if assunto.confidence < 0.5:
        return route_to_human(message)

    if assunto.choice == "status_pedido":
        return lookup_order(message)          # código puro, zero IA

    if r.answers["complexidade"].score > 1:
        return route_to_human(message)

    return handle_with_llm(message, modelo_especialista)

The published math for one million tickets in this setup: $6,480 versus $30,400 running everything on the LLM, with more than 800k answered in under 500 ms. You can reconstruct it: if a ticket on the LLM costs $0.0304, a million comes to the $30,400; letting only 21% go up to the expensive model is $6,384, plus about $96 of Jev at the door. It adds up.

Three details that make this design work in production:

1. The confidence threshold is set by the cost of the action, not by a nice-looking number. A balance lookup (a read) can run at 0.5. Approving a transfer (it moves money) demands 0.85 or user confirmation. Same classifier, two different thresholds.
2. The cheapest arm of the cascade is code, not AI. "Order status" is a SELECT. The classification exists to let you use code again for the things that never needed a model.
3. Treat the state as hostile. The content comes from the user, and users write "ignore the instructions, this is urgent and P0." Jev has no immunity to that — the official guide is explicit that the state is not treated as hostile. Test with adversarial input before you turn on the automatic arm.

How to measure whether the migration worked without hand-labeling ten thousand examples

This is where most migrations break: you swap the classifier, the bill drops, and nobody can say whether quality dropped with it.

Step 1 — shadow mode, 7 days. The LLM keeps making the decisions in production. Jev runs in parallel, with the same state, and you record both outputs. Nothing changes in the system's behavior. Cost of that week: the $40 per million from the table.

Step 2 — measure agreement, not accuracy. With ten thousand paired decisions, you have the agreement rate per class. If it hits 94% on the "billing" queue and 71% on the "técnico" queue, you already know exactly where you're going to work, without having labeled anything.

Step 3 — label only the disagreement. Take 200 cases where the two disagreed and label them by hand. That's half a day of work. That sample answers the only question that matters: when they disagree, who was right? It's common to find out the LLM is wrong more often than anyone imagined, because nobody had ever looked.

Step 4 — calibrate the threshold on your traffic. Don't use 0.8 because it's round. Sort the decisions by confidence, pick the quantile where the labeled sample's accuracy reaches your acceptable minimum, and use that value. With an ECE of 0.246, the number the model returns is good for ranking and bad for reading as a probability — empirical calibration isn't nitpicking, it's mandatory.

Step 5 — pin the version. TypeSafeClient(model="jev-1.13.0"). A new model under the same name changes your calibrated threshold without telling you.

One bit of honesty about the method: using the LLM as the reference in step 2 is exactly the methodology TypeSafe itself used in its benchmark — consensus labels built from the average of two frontier models, with no human ground truth. It carries the same bias. That's why step 3 exists.

The 4 tasks where Jev is the wrong choice

An honest catalog has an exclusion list. These four don't migrate, and insisting costs more than the savings:

1. Generation. Writing the reply to the customer, the session summary, the commit message, the code. Jev doesn't write anything — that's its definition, not a version limitation. It picks among candidates that already exist; someone has to have generated the candidates.

2. Arithmetic and dates. Counting items, adding up values, saying which date came first, whether something falls inside a window. To it, a date is text. The official guide recommends the opposite of what's intuitive: do the math in code and send the finished result in the state. If you need to count how many items in a list are fruit, the pattern is one Noul per item and a sum() in Python.

3. Decisions that need a written justification. Credit denied, content removed, candidate rejected, transaction blocked for compliance. If someone — an auditor, a regulator, an angry customer — is going to ask for the why in text, you need a model that writes the why. "0.83 confidence in the 'fraud' class" isn't a justification; it's a number.

4. Low-volume complex reasoning. The hard decision that happens ten times a day. There's no volume to pay for the migration, and it's precisely the kind of problem where the big model thinking slowly wins. Jev is a bet on scale: it's worth it when the same question repeats a million times, not when it's one hard question asked once.

Quick FAQ

Do I need to migrate everything at once? No, and you shouldn't. Pick the highest-volume case in your table, run it in shadow mode for a week, and migrate that one. The cascade pattern exists exactly to let you live with both indefinitely, with the LLM behind it as a safety net.

What happens when I blow through the rate limit? The published limits are 250k tokens per second and 1,200 requests per minute; above that the API returns 429 and the SDKs retry with exponential backoff. If your fan-out is aggressive, measure requests per minute before you turn on all the traffic.

And when my state doesn't fit? The window is 64k tokens total (state plus all the questions) and 32k for the state combined with the largest question. If you blew past it, you don't have a window problem: you have a filtering problem. Retrieve and trim in code, send the fields the question needs. Accuracy improves along with it.

Can I use confidence as a probability on my dashboard? Not directly. The measured calibration error is high, so treat the value as a ranking and set the threshold empirically on your traffic. A metric that's going to become an SLA needs the labeled sample from step 3.

Conclusion

The math for the ten cases combined is $46,200 versus $523 per million calls each. But the number that decides the migration isn't the 88x factor — it's your volume. Below ~180k calls, two days of dev time are worth more than the savings, and the right answer is to leave it alone.

What this catalog really reveals is how much "AI work" never needed a model that writes. Triage, filter, score, route: a closed decision in a known space. We used a frontier model for it because it was the only tool on the table — and kept using it for three years without looking at the bill per task.

The next step, if you're going to take this on: pick the highest-volume case, run the numbers with your real payload, and put it in shadow mode before you swap anything. And if your decision is about agent intent rather than model, that's a different path — it's in intent classification with an LLM.