Jev, and the cost of a decision

TypeSafe AI shipped a model last week that cannot write a sentence. It cannot write code, summarize a document, or explain its own reasoning. You hand it a description of a situation and a set of typed questions, and it hands back answers with probabilities.

I have spent more time thinking about that than about anything else that shipped this month.

Most of the writeups file Jev under “classifier,” which is accurate and also the least interesting thing about it. Classification is the shape of the output. What matters to me is the price of the output, and what that price makes affordable inside an agent loop, where I have been paying frontier rates to ask questions that are not frontier questions.

For anyone new to this: a normal language model writes its answer one word at a time. That is why asking “is this email about billing?” costs about the same as asking for a paragraph of advice. Jev never generates text. It samples every answer in a single pass and returns a value constrained to the options you defined in advance. If you have ever written an if statement that needed to understand meaning, this is a model built for exactly that spot in the code.

Some background. TypeSafe came out of two years in stealth on September 15 with $40M led by DCVC. The founder, Diogo Almeida, was an author on the InstructGPT paper, the research that turned instruction-following language models into products. He has spent the launch explaining that chat is the wrong interface for software, because software does not want a paragraph, it wants a value. Jev is named after William Stanley Jevons, who noticed that making steam engines more efficient increased coal consumption rather than reducing it. The bet is that cheap decisions get made in places nobody would have paid for a model call.

What Jev actually is

You send two things, state and questions.

The state is the situation. It can be a plain string, a JSON object with named fields, or a list of text for a conversation. Text only, no images or audio.

The questions are what you want to know about that state, and each one declares its own shape. There are three types, and the entire API is those three.

Type	The question you write	What comes back
Noul	Is this true?	A single probability from 0 to 1
Choice	Which of these options?	The selected option, the full distribution, a confidence
Score	Where on this scale?	A position that can land between levels, plus distribution and confidence

A Choice takes up to 255 options. A Score takes two to ten ordered levels. Every answer comes back in roughly 70 to 500 milliseconds, with most landing near 100. Input tokens cost $0.042 per million and output tokens are free, which sounds wrong until you remember there is almost no output to meter.

All the questions run in parallel against the same state. Adding a tenth question costs a few tokens and essentially no time, which inverts the usual instinct to ask one cheap question first and follow up only if needed. You ask everything up front and let your code decide which answers were relevant.

TypeSafe trained Jev with a method it calls Reinforcement Learning for Calibrated Decisions. The load-bearing word there is calibrated: across many predictions, the answers it gives 90% confidence to should be right about 90% of the time. Chat models are trained to produce answers humans rate highly, and they are reliably overconfident when you ask them for a probability. If a model is right 95% of the time but cannot tell you which 5% it is unsure about, you cannot safely automate the task. Calibration is the difference between a model you consult and a model you wire into a decision.

What Jev cannot do

It does not generate anything. No prose, no code, no summaries. If you need text, you still need an LLM, and the useful architecture is the two of them together.

It is not a calculator. It does not count reliably, and the error grows with the size of what you are counting. Dates are text to it, not ordered quantities, so “which of these came first” and “is this inside the window” are both unreliable. Extraction is judgment and Jev can do it. Assembly, ordering, and arithmetic are computation, and that stays in your code.

It gives you a number, not a rationale. That is fine for routing a support ticket and a problem for anything an auditor will read.

It reads literally. It answers the question you wrote, not the one you meant. The tell is when you look at a wrong answer and start explaining what you really meant, because that explanation was the missing half of your instruction.

The state is also not treated as hostile. Text engineered to argue for its own classification can move the answer. If user-controlled content goes into the state, that is your threat model to own.

Pros and cons against an LLM

The honest version of the comparison, with the caveat that most of the numbers come from TypeSafe’s own benchmarks.

Where it wins:

Cost: $0.042 per million input tokens against $0.20 to $10 for frontier models, with free output. That is somewhere between 5 and 238 times cheaper on input depending on what you compare to, and the workflow evals they published claim a 444x reduction on their own workloads.
Latency: 70 to 500 milliseconds against 3 to 329 seconds for frontier models on the same class of question. A router that adds a second is a different product from one that adds 100 milliseconds.
No type errors: The output cannot be a value outside the schema you defined. That is structurally impossible rather than statistically unlikely, so your parsing and validation code can go away.
Confidence with every answer: You set a different threshold per action. Approve a transfer above 0.85, show a balance above 0.5, send anything murkier to a human.
Many decisions per round trip: Ten questions in one call beat ten calls.

Where it loses:

It cannot produce text: Anything generative stays with the LLM. This is a complement, not a replacement, and the launch-day projects all treat it that way.
No rationale: A probability is not an explanation.
It cannot compute: Counting and date math have to be rebuilt as deterministic code around it. Dates are the absolute worst.
“Cannot hallucinate” is narrower than it sounds: Jev cannot return an invalid answer. It can return a wrong valid one, with a confident probability attached.
Context rot applies: Accuracy falls as the state fills with material the question does not need. Whatever assembles the state decides what Jev is allowed to know, and padding it costs you accuracy before it costs you money.
The price might be subsidized: TypeSafe says so itself, and says it expects the number to fall rather than rise. YMMV.

What I actually want to do with it

This is where my thinking has gone, and none of it involves classification.

1. Route work to the cheapest model that can do it

I do this by hand right now. Straightforward tasks go to a small model, anything needing real reasoning goes to a bigger one, and the decision is mine. The problem is that I have to make it before I know what the task is, so the safe answer is usually the expensive model.

A Jev call in front of that turns it into a graded decision. Send the request, ask how much reasoning it needs and which profile it matches, and pick the tier from the answer. The pattern is well studied outside of Jev: RouteLLM reported sending only 14% of queries to the strong model while keeping 95% of the quality, and FrugalGPT’s cascade reported large reductions by letting cheap models handle the easy majority. The research version needed training data and a purpose-built router. A model that takes runtime questions and returns calibrated probabilities is a much smaller thing to maintain.

Getting the routing right is easy next to getting the thresholds right, and thresholds are the part I expect to spend real time on.

2. Decide which skills and MCP servers get loaded

This is the one I think about most, because it is the largest number on my own invoice. My chats open around $0.18 before the agent has done anything at all, and most of that is context. Tool definitions are not free. Fifty MCP tools run to roughly 72,000 tokens of schema before any work starts, and a couple of servers attached to an agent can put 30,000 tokens of metadata in the window. Anthropic’s own numbers show a dynamic approach landing around 8.7K tokens where a static one took 77K. This is a documented cost, and the usual fix is a search or ranking layer over the tool catalog.

What Jev adds is the ability to ask the question in your own words. Send it the prompt plus the names and descriptions of your skills and servers, not their contents, and ask which ones this task needs. At $0.042 per million tokens, reading 5,000 tokens of catalog costs about two hundredths of a cent. A hundred of those a day is sixty cents a month. If it reliably keeps two unneeded servers out of the window, it pays for itself on the first turn.

The reason to slow down: this saves money only where the gated context is genuinely optional. If most of that $0.18 is system prompt, conversation history, and tools the task really does need, the gate shrinks the easy slice and adds a network call. Measure which slice you are cutting before you get excited about the percentage.

3. Decide whether a job should run at all

I have cron jobs that check the news, triage mail, and assemble a morning brief. Right now the “should I run today?” logic is Python I wrote by hand, checking for new items and quiet days. It works, and it is brittle in the way hand-written logic always is: I wrote conditions for the cases I thought of, and the interesting days are the ones I did not think of.

A decision model in front of a job is a better fit, and it composes. Should this run at all. Is this item material enough to include. Does this deserve the expensive model or a summary. Those are three questions in one call, and the answers arrive before the job has spent anything.

Other places I think this fits

Beyond those three, the pattern I keep finding is that agents are full of small judgments currently made by an expensive model, by brittle code, or by nobody.

Gating a tool call before it executes: is this command read-only, reversible, or destructive? Coding agents ship some version of this internally, and it has been closed source until now. An open, cheap classifier in that spot changes how much you can let an agent do unattended.
Deciding the loop is finished: most agents stop because the model said so. Asking a separate model whether the task is actually complete, against the original request, is a second opinion you can afford on every turn.
Deciding what deserves to be remembered: every memory write is a judgment about future relevance, usually made by the same model doing the work. Whether a fact is worth persisting, and how durable it is, is a bounded question.
Deciding whether to interrupt a human: is this worth a notification, or does it keep until the digest? That is the difference between an agent people keep and one they mute.

What I would be careful about

Cheap decisions are still decisions, and a cheap wrong one at the front of a pipeline is more expensive than an expensive right one. Two things I would hold onto.

Price the failure before you pick the threshold. Confidence of 0.7 is plenty for tagging a document and nowhere near enough for moving money. TypeSafe’s own framing is that you set the bar per action, and that only works if you have priced the failure.

Log before you act. Run it in shadow mode for a week, record the confidence and what you would have done by hand, and only then let it into the pipeline. The launch-week projects that will still be running in six months are the ones doing this.

One more thing, from the design guidance in the docs that holds up regardless of Jev: avoid asking a model something code can compute exactly, and avoid hiding several judgments inside one question. Most of my bad prompts fail the second one. “How good is this candidate” is four judgments wearing a trenchcoat, and splitting it into four questions with weights I control turns an opinion into something I can tune.

Where this lands

Jev is interesting because it makes a category of decision free enough that you stop rationing it. My agent currently decides what to load, which model to use, and whether to do the work at all, and it makes those calls with the most expensive tool available, or with Python I wrote on a Tuesday.

A decision that costs a fraction of a cent and 100 milliseconds is a decision you can afford to make well. That is the part I have been poring over.

The practical caution is that it is early. Waitlist, one provider, self-reported benchmarks, and a price that might be a subsidy. If you want to try the shape of it today without the waitlist, a small local model behind a strict output schema gets you most of the interface, minus the calibration. If you want the calibration and the latency, the pattern to copy is the boring one: put the smart if statement in front of the expensive call, log everything for a week, and let it earn the right to act.