Jev: What it is and why this new model matters

Jev is an AI model from TypeSafe AI that makes decisions instead of generating text. It is the first public System One model: you send it a state and a set of typed questions, and it returns choices, scores and probabilities that your code can act on directly. That makes it useful as a fast, inexpensive decision layer inside AI agents and other automated software.

Three things matter most:

• Jev is not a cheaper LLM. It is a different output shape: bounded, typed answers with probabilities TypeSafe calls calibrated, and no ability to write prose at all.
• The confidence number is the point. It lets your code decide when to act alone and when to escalate, which is the decision most agent architectures currently hide in a prompt.
• Zero token decoding. Where LLMs waste compute and latency generating JSON syntax line by line; Jev bypasses autoregressive text generation entirely, emitting structured values in a single pass.

What is Jev?

Jev is TypeSafe AI’s first public System One model, released on 15 September 2026 after two years in stealth. TypeSafe defines the category on its own homepage: System One Models are “a new class of AI model built for decisions inside software”. The name borrows from Daniel Kahneman’s split between fast, intuitive System 1 thinking and slow, deliberate System 2 reasoning. The model is named after William Stanley Jevons, whose paradox describes demand rising as efficiency makes something cheaper.

The practical definition is simpler. Jev returns decisions rather than strings. You hand it a state, which can be a support message, a JSON object or a list of records, and a set of questions you have typed in advance. It answers each question inside the answer space you defined, and attaches a probability distribution and a confidence score to the answer. Founder Diogo Almeida describes the model in the launch post as “a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out”.

TypeSafe had to build a new stack to get that output shape. It says it built a new model architecture, a parallel sampler and a training method it calls Reinforcement Learning for Calibrated Decisions, or RLCD. RLCD replaces the RLHF behind the chat models in everyday use.

Why is Jev different from an LLM?

Jev differs from an LLM in what it is for, not in how big it is. An LLM generates a sequence of tokens and you parse the result; Jev picks from options you supplied and hands you the probabilities behind the pick. TypeSafe puts it the same way when asked whether Jev is just a small language model: “Jev is neither small nor an LLM”.

	Jev	Traditional LLM
Primary job	Decide	Generate
Output	Typed choices, scores and probabilities	Text and tokens
Open-ended writing	No	Yes
Routing and classification	Native use case	Possible, with parsing
Output structure	Bounded before the call	Generated during the call
Best role	Decision layer	Reasoning and generation layer

The table describes Jev alongside an LLM, not Jev against one. TypeSafe does not claim the model can replace a chat model, and the architecture it describes assumes both are present. The interesting question for a team is not which one wins. It is which of your current LLM calls are really decisions dressed up as text.

Jev also differs from JSON mode and structured outputs, the comparison most engineers reach for first. TypeSafe’s answer is that valid JSON only fixes the format: “forcing an LLM into that format can leave some of its intelligence on the table”. TypeSafe trains a System One model for the structured decision from the start, so the model produces the probabilities instead of a prompt requesting them.

How does Jev work?

A Jev call has two parts: a state and a set of questions. The state is what you want evaluated, and it accepts a string, a JSON object or an array of text values. Jev is text only for now, so images, audio and video need preprocessing. You type the questions, and Jev evaluates them in parallel and in isolation against that same state. Asking more of them costs almost no extra time.

There are three question types, and the whole model surface is built out of them:

• Choice answers “which of these options?” and returns the chosen option, the probabilities and a confidence score. Use it for routing a ticket to a department or classifying a document. It supports up to 255 options.
• Score answers “which level?” against an ordered rubric of two to ten levels, and returns the level, the legend, the probabilities and a confidence score. Use it for bug severity or customer frustration.
• Noul answers “is this true?” and returns a single value between 0 and 1. Use it when the probability itself is the signal.

The confidence number comes from the shape of the probability distribution rather than from the model’s opinion of itself. A distribution concentrated on one outcome is a confident answer, a flat one is not. For three options the formula is (3 x largest probability minus 1) divided by 2. TypeSafe’s reasoning for shipping it at all is worth quoting: “If an intelligent system, whether human or machine, cannot express honest uncertainty, the system cannot be trusted.”

Here is what that looks like on a task any support team will recognise. The example below is a composite, built from the kind of triage work we see at several clients rather than from one of them.

A customer message arrives at an agent. In a single call, Jev decides which team should receive it (Choice), scores how urgent it is (Score), and answers whether a human needs to look at it before anything is sent (Noul). Your code reads the three answers and the confidence behind each one, and only then does an LLM write the reply. A model that cannot invent a fourth team takes the decisions, and a model that can write produces the reply.

One design rule runs through the docs and is easy to get wrong. Each question should be “a gut-check determination: the kind of judgment a highly knowledgeable person could make in a few seconds”. If the question needs a chain of reasoning, you break it into several questions and combine the answers in code.

Where does Jev fit inside an AI agent?

Jev fits in the places where an agent currently asks a language model a question it does not need prose to answer. Those places are ordinary, and the agent frameworks have already named them. LangChain’s middleware documentation describes steps that run before and after each turn of the agent loop, with built-ins for tool selection, guardrails, PII detection and human-in-the-loop interrupts. Every one of those is a bounded decision.

Six patterns are worth more than a long list of possibilities:

• Model routing. Classify intent and difficulty in one call, then send the easy traffic to a small model and the hard traffic to a frontier one. TypeSafe’s intent routing pattern makes the point that “the expensive resources only get invoked for the requests that actually need them”, which is the same logic behind an AI gateway.
• Tool selection. Choosing among a fixed set of tools is a Choice question with a confidence score, not a paragraph of reasoning followed by a parse.
• Guardrails. TypeSafe’s guardrails cookbook screens each message with a set of Noul questions and a Score for potential harm, and routes the result to pass, review, block or crisis support. In its worked example a jailbreak disguised as a medical accommodation scored 0.74 on jailbreak detection and was blocked. This is a cheaper shape for the AI guardrails most teams already run.
• RAG evaluation. In TypeSafe’s passage classification cookbook, Jev rated 72 retrieved passages across six queries for relevance, usability, contradiction and injection attempts before anything reached the prompt. A planted attack ranked first on cosine similarity but hit 0.99 on injection detection, so it never reached the context.
• Ticket triage. One request returns category, severity, reproducibility and frustration, and the routing logic stays in your own code instead of in a system prompt.
• Human escalation. The confidence-gated routing pattern sets different thresholds for different risks: act automatically above 0.85, ask the user between 0.6 and 0.85, and hand to a human below 0.6. Anything destructive needs more than 0.9. As the docs put it, “the answer tells you what; confidence tells you whether to act”.

If you have read our guide to harness engineering, this will feel familiar. Reliability comes from the scaffolding around a model, and a decision layer is scaffolding you can test.

What do Jev’s speed, pricing and benchmarks show?

The speed and pricing figures make a strong vendor case, there are no public benchmark scores at all, and no independent evidence backs any of it yet. That is not a criticism. The product is one week old. The vendor case and the evidence still need separating before anyone builds a business case on these numbers.

Item	TypeSafe’s published figure	How solid it is
Input price	$42 per billion tokens, or $0.042 per million	Published list price, easy to verify on your own bill
Output price	Free	Published list price
End-to-end latency	70 ms to 500 ms	Vendor figure from the launch post; TypeSafe notes its evals are generally run from its own laptops on the US West Coast
Speed versus frontier LLMs	40 to 200 times faster on System One shaped queries	Vendor measurement
Headline comparison	193.6x faster, 444.6x cheaper	Vendor workflow evals; TypeSafe says these are “on the higher end of real world gains”
Context window	64k tokens per request, 32k for state plus the longest question	Documented limit
Throughput	250,000 tokens per second, 1,200 requests per minute	Documented limit, adjusted dynamically
Public benchmark scores	None	Deliberate: TypeSafe publishes no public benchmark results

The pricing is the easiest part to check. At $0.042 per million input tokens with free output, a routing call costs almost nothing here, while the same call on a frontier model costs real money. Our article on tokens and cost explains why that ratio matters more than the headline rate. TypeSafe’s homepage claims its price is 238 times lower than one named frontier model’s input price, which implies a comparator of roughly $10 per million. Its own launch post puts current LLM input pricing at $0.20 to $10 per million, so the implied comparator sits at the top of TypeSafe’s own range. We have not independently verified the comparator itself.

The speed claims need more care. The side-by-side demo on TypeSafe’s homepage shows a Jev call completing in 0.114 seconds at a cost of $0.000081, against 8.566 seconds and $0.013880 for an LLM doing the same job. That is 75 times faster and 171 times cheaper, which is impressive and is not where the headline multiples come from. Those come from a separate set of workflow evals, and TypeSafe discloses the caveats itself. Its own model capabilities team built the workflows. The reference answers are the average of GPT-6 Astra and Fable 5.1, and the competing LLMs run through TypeSafe’s own wrapper.

Then there is the benchmark question, and the answer is unusual. TypeSafe publishes nothing: “We deliberately chose not to publish performance against public benchmarks.” Its stated position is that teams should put no weight on public benchmarks and build their own evaluations instead, because System One tasks are easier to evaluate than open-ended generation. We think that is right, and we would say the same thing in a piece about evaluating LLMs beyond the benchmarks. It also means nobody outside TypeSafe can currently tell you how accurate Jev is on your work.

There is one thing we have not done: we have not yet run Jev against a client workload. We would start with a routing task that has a known answer set, put a thousand real messages through it, and measure four things. The first is latency at the 95th percentile rather than the average. The second is cost per thousand decisions against the current model. The third is agreement with the incumbent model, plus a human read of every disagreement. The fourth matters most, and it is calibration. When Jev reports 0.9 confidence, is it right nine times out of ten? A model whose confidence is honest is worth more than a model that is slightly more accurate and does not know when it is guessing.

Where does Jev not replace an LLM?

Jev cannot write, and TypeSafe does not pretend otherwise. The jaggedness page for version 1.13 says the model “is not trained to generate text”. It will not draft a reply, explain its reasoning in prose, produce code, or handle anything open-ended. Those remain the language model’s job.

The documented weak spots are worth reading before you design around it. Jev “is not a calculator” and should not be asked to count or do arithmetic. It “reads dates as text, not as ordered quantities”, so comparing two dates belongs in code. Accuracy falls as the state grows with content unrelated to the decision, so filtering before the call matters. Multi-hop reasoning and double negatives reduce accuracy. And the model does not treat data as hostile by default, which means adversarial content needs explicit criteria and testing.

The most important caveat is the one the marketing does not lead with. TypeSafe’s homepage says “Zero Hallucinations”, and its own FAQ explains exactly what that means: “Jev guarantees the shape of its answers, not that every decision is correct. If you provide a list of categories, it can’t invent a category outside that list, but it can choose the wrong one.” Bounded output removes a class of parsing failures. It does not remove the need to check whether the decision was right. TypeSafe is candid about its own chart too: the 0 percent it plots for hallucination “is not empirical”, because schema matching is guaranteed rather than measured.

One more thing to know before you write tests: Jev is not deterministic. TypeSafe argues that consistency matters more than determinism. It defines consistency as making similar decisions when the meaning stays similar, even if the wording changes, and says Jev is designed for that.

Should AI teams pay attention to Jev?

Yes, AI teams should follow Jev, but for the idea more than for the product. Jev is one week old, its evidence is all vendor-supplied, and a sensible team runs a small evaluation before committing anything to it. None of that is a reason to ignore what it is arguing.

The argument is that generation and decision-making are different jobs, and that asking one general-purpose model to do both has been a convenience rather than a design. For three years the default answer to “how should my software decide this?” has been to write a prompt and parse the result. A model class now exists that takes the decision, states its own uncertainty and costs almost nothing. That changes the shape of a sensible AI architecture: an LLM to reason and write, a decision layer to branch, and ordinary code holding the two together.

Whether TypeSafe is the company that wins that category is a separate question, and an open one. The idea is bigger than the model. Teams that start separating the two kinds of calls now will be in a better position whichever vendor ends up serving the decision layer.

Our AI consultancy service can map which decisions in your stack do not need generated text. In the same session they set out what an honest evaluation of a decision model would have to measure.

Frequently asked questions (FAQ) about Jev

Jev launched on 15 September 2026 and is at version 1.13, so the figures in this article are early and worth re-checking before you quote them.