Jev: the model that decides instead of writing. An in-depth analysis and ten use cases

On 15 September, TypeSafe AI released Jev. Within three days, demand had briefly knocked its API over, LangChain had shipped an integration and TechCrunch was reporting that a new kind of model was thrilling developers. Behind it is Diogo Almeida, who comes from OpenAI and is listed — by TypeSafe itself — among the co-inventors of RLHF, the technique that turned language models into ChatGPT.

Jev is not a language model in the usual sense: it doesn't write a single word. It receives a state — a ticket, a claim file, an agent's trace — and a set of closed questions, and returns typed decisions with a probability for each option. According to TypeSafe, in 70–500 milliseconds, and charging for input only.

Before going any further, the question any CTO would ask: Jev came out four days ago and we don't have it in production yet. This piece comes from reading its technical documentation end to end, its cookbooks, what its first testers have reported and, above all, the page where TypeSafe lists the known failure modes of its 1.13 release. It is the most useful page of the whole launch, and the least quoted.

Our reading fits in one sentence: most of what companies ask an LLM to do inside an automation today isn't writing, it's deciding, and for that part Jev changes the maths. But what really changes is not what the headlines say — speed and price — but the fact that every answer arrives with a calibrated probability you can build a threshold on. That is what turns a classification into a decision you can automate.

What exactly Jev is, and what it isn't

The interface is the whole idea. Instead of a prompt and some text back, you send a state — text, a JSON object or a list — and questions of three kinds, which TypeSafe calls primitives:

Every question in a call sees the same state and is evaluated in parallel and in isolation: one answer doesn't leak into another. Adding questions barely changes response time, and batching them is much cheaper than asking them one at a time. In one of their cookbooks, thirteen questions in a single call were around ten times faster and more than eleven times cheaper than thirteen separate calls, with the same answers. Hence the pattern their documentation repeats most: ask everything your code might need, even if it only matters for some cases, and let the code decide which answers to use.

Training is the other half. Chat LLMs are tuned to produce the text a human rater prefers (RLHF) or to get automatically verifiable problems right (RLVR). TypeSafe trains Jev with what it calls Reinforcement Learning for Calibrated Decisions (RLCD), whose goal is honest probabilities: if the model says 0.8 across a set of cases, around 80% of them should be right. The documentation itself adds the important caveat: calibration is measured over groups of predictions and does not guarantee that any single answer is correct.

And what it isn't. It doesn't write replies, doesn't generate code, doesn't explain its reasoning and isn't an agent: it doesn't decide the next step of anything, it answers closed questions put to it by code. The category name, System One, comes from Kahneman's System 1: fast, intuitive judgements of the kind an expert makes in a second when the right context is in front of them. Anything that requires multi-step reasoning is still LLM territory.

What really changes is the probability, not the speed

The headlines went with the figures: 40 to 200 times faster and hundreds of times cheaper. They matter, but they are not the main point.

In the piece on the exception path we explained why the confidence an LLM declares is a poor trigger for deciding which cases go to a person: the GPT-4 technical report showed that post-training made the model's calibration worse. RLCD targets exactly that problem. The comparison table in TypeSafe's announcement puts it better than we could: "If a model can do a task 95% of the time but doesn't say when it's in the 5%, it can't automate that task."

The first testimonials point the same way. Nikhil Mudholkar, CTO of Bryo AI, compared Jev with Gemini on classifying business emails: Gemini was slightly more accurate, but ten to twenty times more expensive. What interested him, he told TechCrunch, was the confidence scores: "it is the only one that hands back a real probability". Armin Ronacher, CTO of Earendil, put it the other way round: "At the end of the day, it delegates the hallucination problem a little bit to the user." If the answer comes back at 50%, it's a coin toss and you disregard it; if it comes back at 95%, you can act on it.

That line is the practical key: the threshold becomes your decision, explicit, measurable and adjustable. And the other half of the exception-path argument still stands, because no model solves it: the probability measures the model's doubt, not what you stand to lose on the case. TypeSafe's documentation applies this in its own examples, with different thresholds for checking a balance and for approving a transfer. How much certainty each action requires is decided by the code.

This is what triage with confidence-gated routing looks like in the Python SDK. Jev's primary language is English, so the example is written in English; a Spanish or Catalan team should run this same example with the instructions in its own language, because that is the first thing to measure:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient(model="jev-1.13.0")  # pinned version: thresholds are calibrated against it

r = client.system_one(
    state={"ticket": ticket, "customer": {"plan": plan, "tenure": tenure}},
    questions={
        "area": Choice(
            instructions="Which team should resolve `ticket`?",
            criteria={
                "billing": "Charges, invoices and refunds",
                "technical": "Errors, integrations and outages",
                "account": "Access, users and permissions",
                "other": "None of the above",
            },
        ),
        "asks_refund": Noul(
            instructions="Is the customer asking for money back?",
        ),
        "churn_risk": Score(
            instructions="What churn risk does `ticket` express?",
            criteria=[
                "None",
                "One-off complaint",
                "Mentions leaving or compares with another provider",
            ],
        ),
    },
)

area = r.answers["area"]
if area.confidence < 0.6:
    send_to_human_queue(ticket)        # the exception path, not an error
elif r.answers["asks_refund"].noul > 0.9:
    open_refund_flow(ticket)           # amount and policy are checked in code
else:
    route(area.choice, priority=r.answers["churn_risk"].score)

Three details in the example are design decisions, not style. The other option, so the model doesn't have to force an answer. The pinned version, because the jev-latest alias moves whenever TypeSafe ships a new release, and thresholds are calibrated against a specific model. And the 0.6 threshold, which is a starting point rather than a recommendation: yours comes from measuring.

The small print, read in full

TypeSafe deserves unusual credit here: its announcement adds a section of caveats after every figure, and its documentation includes a page of known failure modes. Read in full, they draw a fairly clear map of where it is best not used, or not without precautions.

Two more things worth knowing, even if they don't change the design. TypeSafe doesn't disclose its architecture, and outside observers quoted by TechCrunch suspect it is built on top of an open-weight LLM. And it says it trains exclusively on synthetic data produced by its own team.

None of this is a criticism. A lab publishing the list of its own failure modes on launch day is more honest than almost anything else on this market. But it needs reading before you design, not after the first incident.

Ten use cases where it adds a great deal of value

We didn't pick these cases for how impressive they look, but on four criteria: the task is deciding, not writing; there is volume or time pressure, which is where an LLM's cost and latency hurt; the probability is useful for something concrete; and there is, or can be designed, a path for the doubtful cases. They run from the most immediate to the most ambitious.

1 · Support and inbox triage

The problem. Every email or ticket today goes through either an LLM that returns JSON with the area, urgency and tone, or a person who reads it and forwards it. The first is expensive and slow at scale; the second, more so.

How it's built. A Choice for the area, with an "other" option; some Nouls for refund, urgency or a request to talk to a person; a Score for frustration or churn risk. All in one call, and the code routes. It's the example above.

Why here. It is the task that most resembles what Jev does best, and volume turns the difference in cost and latency into money. The Bryo AI case is exactly this.

The trap. Literal reading. "Asks for a refund" is not the same as "is unhappy and asks what their options are", and Jev answers what is written. Edge cases go into the criteria, with examples of what falls in and what doesn't.

2 · Exception paths with a threshold: claims, invoices, complaints

The problem. The automated process handles most cases and has to decide which ones go to a person. With an LLM, that decision rests on a confidence that isn't calibrated.

How it's built. Atomic questions about the file — does the cover apply?, is documentation missing?, is there anything that warrants review? — combined in code into three outcomes: pay, deny or person. One of TypeSafe's cookbooks builds precisely a claims triage with those three outcomes.

Why here. This is the case where a calibrated probability is worth more than speed. Another cookbook, on moderation, puts numbers on it: requiring at least 0.6 on the most likely option and sending whatever falls short to human review, agreement across repeated runs rises from 90.8% to 99.2%, with 74.2% of answers automated. It is the exception path's coverage-versus-error curve, with the numbers in plain view. One caveat: the experiment repeats a single borderline message fifteen times, so it shows the mechanism, not the performance you will get.

The trap. Amounts, excesses and deadlines. Jev doesn't compare quantities or dates reliably: Jev judges the cover and the arithmetic happens in code. And the threshold is set by consequence, not convenience.

3 · Guardrails before the agent acts

The problem. An agent with tools can receive bad instructions, by mistake or because someone has slipped them in. Checking every call with another LLM is expensive and slow, and almost nobody does it.

How it's built. Before a tool call runs, a handful of Nouls: is it destructive?, does it do something the user didn't ask for?, does it send data out? LangChain already packages this as experimental middleware that blocks the call before it executes.

r = client.system_one(
    state={"request": user_request, "call": {"tool": "bash", "command": command}},
    questions={
        "destructive": Noul(instructions="Does `call.command` delete or overwrite data irreversibly?"),
        "out_of_scope": Noul(instructions="Does `call.command` do something `request` did not ask for?"),
        "exfiltrates": Noul(instructions="Does `call.command` send data or credentials to an external destination?"),
    },
)

risk = max(r.answers[k].noul for k in ("destructive", "out_of_scope", "exfiltrates"))
if risk > 0.3:
    ask_for_confirmation(command)   # and the permission list still governs what gets executed

Why here. Because cost and latency let you check every call, not a sample. Pranit Sharma, a software engineer at Vercel, told TechCrunch that they replaced the LLM that reviewed commands for safety with Jev and got results five to eighteen times faster, and with greater accuracy.

The trap. The most serious one on this list: Jev's own documentation warns that text written to manipulate it can shift its answer. A probabilistic guardrail raises the cost of an attack, but it authorises nothing. What the agent may execute is still decided by a deterministic permission list, as we argued in the piece on prompt injection. That is why the threshold in the example is low: here, asking for one confirmation too many is cheaper than executing one too few.

4 · Model routing

The problem. Sending every request to the most powerful model is expensive; sending them all to the cheap one makes the hard ones worse. And a router built with an LLM adds back the latency and cost you were trying to save.

How it's built. A Choice on the request — fast or powerful model, with criteria for what goes to each — and a Score for difficulty or risk; the code picks the model. LangChain also offers experimental routing middleware on top of Jev, and Ronacher singled it out as one of the most useful applications.

Why here. It is the most direct cost lever in any system with volume, and it tackles head-on what we wrote about why the bill grows between pilot and scale.

The trap. Router errors are silent: a hard task sent to the cheap model doesn't throw an error, it produces a worse answer. You need to sample what the router sent to the cheap model and review it, like any other automated path.

5 · Which context and which skill the agent loads

The problem. Agents load too much: every skill in the catalogue, every chunk the search returned. More context isn't more intelligence; it's more cost and more distraction.

How it's built. One call that scores each skill or each chunk against the request, plus a Noul asking whether any is needed at all. In one of the cookbooks, with a catalogue of 182 skills and 488 requests to Claude Haiku 4.5, having Jev suggest at most one skill cut wrong loads from 16.8% to 7.3% and unnecessary ones from 9.8% to 4.0%. Another filters retrieved chunks before they reach the answering model, and drops the ones hiding instructions.

Why here. Because it is automated context engineering: deciding what goes into the window is a decision, and now it is a cheap one.

The trap. Dropping the chunk that held the answer raises no alarm. The filter needs its own evaluation set.

6 · Re-ranking RAG results

The problem. Embedding or keyword search finds the right document, but rarely puts it first.

How it's built. One question per query–candidate pair over a shortlist, then re-sort by the score.

Why here. It improves what the answering model sees without touching it. In TypeSafe's cookbook on legal queries, with thirty-passage shortlists that always contained the right one, the correct passage came first in 18% of queries against 5% for search alone, and within the top ten in 62% against 38%.

The trap. That is forty queries: enough to see the order of magnitude, not to promise that result. And cost grows with the shortlist: those forty queries took 1,200 calls.

7 · Verifying what another LLM writes

The problem. LLMs fail in known ways: they misquote, invent references, call a tool with the wrong argument. Checking every output with another LLM doubles the cost; checking it with people doesn't scale.

How it's built. Atomic questions about the output and its source: does the quoted passage support the claim?, does the quote exist in the document?, does the call's argument match what the user asked for? The documentation breaks the verification of a tool-call trace into nine yes-or-no questions, one for each thing that can go wrong.

Why here. Because it turns verification into something you do on one hundred per cent of outputs, and the answers are logged as data: exactly what the silent-error sampling we described in the exception path needs.

The trap. Checking that a quote is in the document is a judgement; checking that a number adds up is arithmetic. The latter, once again, in code.

8 · Extraction: the LLM proposes, Jev chooses, the code calculates

The problem. Extracting fields from invoices, contracts or forms with an LLM works until it invents a value that wasn't in the document.

How it's built. Jev doesn't extract by writing, because it doesn't write: it chooses. A regular expression or an LLM proposes the candidates — amounts, dates, tax IDs, email addresses — and Jev picks which one matches the requested field, with a "not stated" option. Dates are requested in parts, as closed options, and the code assembles them. One of the cookbooks includes a detail that matters for European documents: asking with a Noul whether the document writes "€1.315,50" or "€1,315.50", because the code that normalises the amount needs to know.

Why here. Because the extracted value is literal: it exists in the document. In accounts payable, that is the difference between a wrong entry and a visible exception. TypeSafe also publishes a cascade in which a small model extracts, Jev verifies field by field and you only pay for the large model when the verification is in doubt.

The trap. Believing Jev does the hard part. The design does: which candidates get proposed and what the code does with each answer.

9 · Reconciling entities in the CRM and the ERP

The problem. The same customer appears three times under different names; the same supplier, with two addresses. Any agent reading those systems inherits the mess.

How it's built. For each candidate pair, a Score with three levels that are the three things you can do — merge, keep separate or hand to a person — and some Nouls telling that person which field disagrees. It is the design of TypeSafe's cookbook on product catalogues, with 450 candidate pairs.

Why here. Because it is the fourth question of the ERP boundary — what if the system's data is wrong? — solved before the agent is connected. Cleaning up master data is the most profitable data preparation there is.

The trap. Identifiers — tax IDs, IBANs, internal codes — are compared in code, never by the model. Jev judges whether "Distribuciones Pérez" and "Dist. Pérez e Hijos, SL" are the same company, not whether two numbers match.

10 · Semantic review in CI and pull request triage

The problem. A team's conventions — how things are named, what isn't done in which layer, what a change to a public API requires — don't fit in a classic linter, and checking them by hand is the first thing that gets skipped when the volume of generated code grows.

How it's built. One Noul per rule on each hunk of the diff, inside the CI pipeline; whatever crosses the threshold is flagged for review. TypeSafe lists this among its use cases as semantic linting.

Why here. Because in teams that develop with AI the bottleneck is no longer writing code but reviewing it, as we covered in the piece on reviewing generated code. A cheap filter that directs human attention to what matters is worth more than another assistant that writes.

The trap. Low-level code and numeric representations are among the things Jev handles worst, according to its own documentation. For rules about intent and structure, fine; for finding a logic bug, no.

Three promising uses we left off the list, for now

Real-time decisions inside an interface. It is the flashiest demo of the launch — Jev playing Doom at ten queries a second, for about seven dollars an hour — and the voice banking example in its documentation. Few processes at a mid-sized company need to decide in 100 milliseconds rather than in three seconds; those that do, such as fraud at the moment of payment, deserve their own analysis.

Turning historical records into features for classical models. Running years of tickets, sales notes or reviews through hundreds of questions and using the probabilities as features for a predictive model is one of the uses with the most headroom, and TypeSafe publishes a complete loop for doing it. But it requires ground truth to measure against and a data team to maintain it: it isn't where you start.

Agents that drive the browser or the computer. Some people are already using it to decide every click for fractions of a cent. It is too early to recommend it for a business process.

How to find out whether it works for your case before committing to anything

TypeSafe asks every customer to build their own evaluations, and it is right. This is the test we would run before putting Jev into a process:

1. Pick a decision, not a process. A single LLM call from the second pile: the one that repeats most or costs most.
2. Gather 200 to 300 real cases with the correct answer, in your language and with your mess. It's the usual golden set, and you probably already have half of it in your history.
3. Break the question down into atomic questions, with criteria that say what falls into each option and what doesn't. Try the instructions in your own language and in English.
4. Run Jev and your current LLM on the same set, and measure accuracy, latency and cost per decision.
5. Look at calibration, not just accuracy. Group the answers into confidence bands and check what percentage is right in each band. If nine out of ten are right in the 0.9 band, you can build a threshold on it; if not, confidence won't work as a trigger and Jev loses its main advantage.
6. Test what you know it finds hard: messages written to fool it, cases with amounts and dates, states full of noise.
7. Decide before deploying the pinned version, the threshold per type of action and what the system does when Jev doesn't respond. And pass the data processing agreement to whoever handles data protection.

The decision criterion is simple to state: Jev pays off if, at the threshold your process needs, it resolves more cases than your current system with the same silent error, or the same cases at lower cost and latency. If calibration doesn't hold on your data, speed and price won't make up for it: you will have swapped an expensive classifier for a cheap one that doesn't know when it's in doubt.

The product may change; the pattern is here to stay

A year from now Jev may have competitors — Ronacher took that for granted — or TypeSafe may not deliver on its promises. What won't go away is the pattern it puts on the table, and it's worth adopting regardless of the vendor.

The pattern is this. Code owns the flow. LLMs keep what only they do well: drafting, multi-step reasoning, handling the open-ended. And the hundreds of small decisions in between — who does this go to, is this safe, which of these is the right one, is something missing — become closed questions that return a probability, are combined in code and are routed with thresholds that someone has decided and measured. It is System 1 and System 2 architecture, and it is what separates an agent that is software from an agent that is a demo.

That is why TypeSafe's documentation insists that Jev is for building AI-powered software, not agents: every turn of an agent's loop is one more chance to go off the rails, and every decision taken out of the loop and turned into a typed question is one chance fewer.

So the useful question isn't whether Jev is better than GPT or Claude. It is how many of your LLM calls were, in fact, a decision dressed up as text.

Frequently asked questions

What is TypeSafe's Jev?

It is the first model in what TypeSafe AI calls System One: a model that doesn't generate text but answers closed questions about a state — a ticket, a claim file, an agent's trace — and returns typed decisions with a probability for each option. There are three question types: Choice to pick between options, Score to place something on a scale and Noul for yes-or-no questions. It launched on 15 September 2026 in early access and is designed to be consumed by code, not by a person.

How is it different from asking an LLM for a JSON answer?

In three ways. The output is restricted by construction to the options you define, so there is nothing to validate or parse. All questions are evaluated in parallel in a single call, in around 100 milliseconds, instead of generating text token by token. And every answer comes with a probability trained to be calibrated, which is what makes thresholds possible. An LLM with structured output can return the same format, but its stated confidence is usually not calibrated.

Is it true that Jev doesn't hallucinate?

It is true in a narrow sense: it cannot return a value that isn't among the options you gave it. It isn't true in the sense that matters: it can pick the wrong option, and with a high probability. The documentation itself points out that calibration is measured over groups of predictions and does not guarantee that any single answer is correct. You have to measure accuracy and calibration on real cases, as with any model.

Does it work in Spanish and Catalan?

It accepts any language, but TypeSafe states that English is its primary training language and that other languages work with lower accuracy. For a Spanish company, that means measuring before trusting it: building a set of real cases in Spanish or Catalan, comparing their accuracy and calibration, and testing instructions written in Spanish and in English. And keeping a particularly close eye on confidence when routing.

Can it be used with the personal data of European customers?

It can, with some groundwork. The service currently runs in the United States, and transfers from the EU rely on the standard contractual clauses in its data processing agreement. TypeSafe says it doesn't train on customer data, but zero data retention is only offered on the enterprise plan. Before sending personal data, a data protection impact assessment and a transfer assessment are advisable, as is minimising what goes into the state: many decisions don't need names or identifiers.

Does it replace GPT or Claude in our workflows?

No, it complements them. Jev doesn't draft, doesn't reason in multiple steps and doesn't generate code. What it can replace are the LLM calls that are really decisions: classifying, routing, scoring, verifying or choosing between candidates. The pattern we propose is that code governs the flow, LLMs keep whatever requires writing or reasoning, and the small decisions are made with closed questions and measured thresholds.