Decision models: the missing layer between LLMs and code

On 15 September 2026, TypeSafe AI released Jev, its first "System One" model, after two years in stealth. Jev takes a deliberately different approach from a conventional language model. It doesn't write anything. It evaluates structured questions against the state you give it, and returns typed decisions with probabilities.

That sounds like a small difference. It changes where the model sits in a software architecture.

A conventional LLM is a generation primitive: context in, text out.
Jev is meant to be a decision primitive: state plus typed questions in, decisions plus probabilities out.

That makes it a candidate for the judgement layer inside agents and applications: routing, policy checks, risk classification, prioritisation, escalation, ranking, and every other place where software needs an answer rather than an explanation.

So the interesting question isn't whether Jev is a better chatbot. It's whether decision models are a useful new building block for AI software. The evidence is early, but it's worth looking at carefully, and a wave of open alternatives appeared within days of the launch.

What Jev actually is

TypeSafe describes Jev as a "frontier-intelligence function call": unstructured state goes in, typed probabilistic decisions come out. The interface has three question types:

Type	Returns	Example
Choice	One option from a list you define, with probabilities	Route this ticket to billing, shipping or technical support?
Score	A value on a numeric scale	How urgent is this request, from 1 to 5?
Noul	Yes or no, with a probability	Does this message contain a refund request?

Several questions can be asked about the same state in one request.

This is not the same as asking an LLM for JSON. With structured output, the model still generates tokens, which are then constrained or parsed into a schema. With Jev, the decision space is part of the interface: there is no free-form answer to parse. If you offer three categories, it cannot invent a fourth, which is why TypeSafe says its output has zero schema errors.

That claim should not be confused with zero semantic errors. If you define ["approve", "reject", "escalate"], Jev can still pick the wrong one. The design removes one class of failure, malformed output. It doesn't remove wrong judgements.

Why the interface matters

A general-purpose LLM is optimised to talk to people. Its output may contain reasoning, explanation, code, JSON or prose. A decision model is optimised to talk to software. Instead of parsing "Based on the information provided, I would probably escalate this case because...", the application receives something much closer to a typed function result:

{ "decision": "escalate", "probability": 0.91 }

That matters because agents make many small judgements. A single workflow may need to ask a dozen questions: Is the request in scope? Is the evidence sufficient? Does this policy apply? Is the action reversible? Does it need human approval? Should we retry?

Sending each of those to a frontier generative model adds latency, token cost and parsing code. A specialised decision model tries to make those judgements cheap and fast enough to become ordinary software operations.

What Jev is not

Jev doesn't generate prose, emails, explanations, code or open-ended answers, and it can't create answer categories you didn't provide. It's a different primitive, not a smaller LLM. It fits between the reasoning model and the code that acts:

+---------------------------+
|      Generative LLM       |
|   reasoning and plans     |
+-------------+-------------+
              |  tool call / workflow step
              v
+---------------------------+
|      Decision model       |
|  Jev or an alternative    |
+-------------+-------------+
              |  typed decision + probability
              v
+---------------------------+
|         Software          |
|  execute, route, escalate |
+---------------------------+

Calibration: why the probabilities matter

TypeSafe trains Jev with a method it calls Reinforcement Learning for Calibrated Decisions (RLCD). Where RLHF optimises for answers people prefer, RLCD optimises for probabilities that match reality: when the model says 70%, it should be right about 70% of the time.

Two things are worth being precise about:

Calibration is a property of many predictions, not one. A probability of 0.90 doesn't guarantee that a particular answer is right. It means that, across a representative set of predictions scored around 0.90, roughly 90% should be correct.
Independent evidence is still thin. One public benchmark of Jev on 60 agent tool-call risk examples reported 91.7% accuracy and an expected calibration error (ECE) of 0.0712, and its author is careful to say that 60 cases are too few to draw strong conclusions either way.

The right reading, then, isn't "Jev's probabilities can be trusted". It's that Jev exposes probabilities you can test and calibrate for your own decision problem, which is a far more useful engineering property.

Where it fails

TypeSafe publishes the known weak spots of the current version: arithmetic and counting, comparing dates, several layers of indirection, irrelevant information in long states, adversarial text and contradictory criteria. TypeSafe's own advice is to keep maths in code.

In practice:

Don't outsource deterministic computation. Checking that an invoice total equals the sum of its lines, or that a date falls inside a window, is code. Whether an invoice looks like it contains a suspicious charge is a judgement.
Don't treat it as a security boundary. The state you pass in can contain hostile, instruction-like text. A typed output removes format risk; it doesn't remove prompt-injection risk. Untrusted input still needs its own isolation and validation, as we describe in How to run coding agents securely.
Don't assume consistency across questions. Separately asked questions are evaluated independently, so their probabilities won't automatically obey logical rules you have in mind.

The economics: one decision versus many

TypeSafe reports that Jev is 40 to 200 times faster and 40 to 400 times cheaper than frontier LLMs, with peaks of 193.6x faster and 444.6x cheaper on its own workflow evaluations. TypeSafe itself notes that its team built those workflows and that the figures are likely to be at the high end of real-world results.

Independent testing tells a more nuanced and more interesting story. TrueStandard measured:

Workload	Jev	Comparison	Speed-up
One yes/no decision	477 ms	790 ms (Gemini 3.1 Flash Lite)	~1.7x
Six judgements	0.739 s, one batched call	74.42 s, six sequential calls to a reasoning model	~100.7x

For a single decision, the gain is useful but modest. The big multiplier appears when many independent judgements are evaluated together against the same state. The advantage isn't that one question is answered 190 times faster; it's that a batch of judgements becomes one structured computation.

Pricing reinforces that pattern. TypeSafe lists Jev at $0.042 per million input tokens, with output free. Workloads that ask many small questions about the same state, the typical shape of an agent's internal checks, are exactly where that price changes the economics.

The open-source response

The most telling development since the launch is how quickly open projects appeared in the same space. They are not copies of Jev: architectures, training data and goals differ. Together they suggest that typed decision models are becoming a category of their own.

Project	What it is	Notes
GLiNER2.5-Decide (Fastino)	340M-parameter open classifier over labels you supply at call time	Aimed at routing, moderation, severity, urgency and human handoff; runs on CPUs; results on a 17-domain held-out suite are vendor-reported
Laya (Convai Innovations)	Non-generative decision model on a ModernBERT-large backbone (about 421M parameters), with English and multilingual checkpoints	Apache 2.0; the authors report faster, better-calibrated results than Jev on their own benchmark, a comparison that is indicative rather than controlled
Kev	Open family of Jev-like decision models on Qwen3.5 (0.8B, 4B, 9B) with training code	Supports noul, choice and score; API compatible with TypeSafe's SDK; the authors report Kev-9B trailing Jev by about 4.5 points on new-source data, noting the comparison isn't controlled
simple-jev (Featherless AI) and OpenJev	Tools that expose open models through a Jev-style decision interface	Show that the interface can be reproduced without the proprietary model

These numbers come from different datasets, prompts and objectives. They shouldn't be merged into one leaderboard. What they do show is that open, self-hostable decision models can be competitive on specific workloads, which matters for anyone who needs data to stay in their own cloud or region.

It's also no coincidence that Laya is built on ModernBERT. Encoder models are fast, cheap and good at exactly this kind of judgement, which is the same principle behind our own hybrid ModernBERT pipeline that reaches 97% of frontier-model quality at a fraction of the cost.

Turning a probability into a production decision

The useful question isn't "is 0.82 a good confidence?" It's "which threshold gives my application the error rate I can accept?" A simple process:

Build a labelled dataset that looks like real production traffic.
Run the decision model and store the input, decision, probability and correct answer.
Sweep the threshold (0.60, 0.65, ... 0.95) and measure precision and coverage at each point.
Pick the operating point that matches your trade-off: above it, act automatically; below it, escalate to a stronger model or a person.
Validate on data the threshold never saw.
Monitor drift. A threshold that was well calibrated in September may not be in December if the incoming work changes.

The shape to aim for is model probability → your data → threshold analysis → production gate. Never model probability → a threshold copied from someone else's blog. A 0.8 from one model on one task means something different from a 0.8 from another model on another task.

The emerging architecture

The most important consequence of Jev may be architectural rather than about any one model. A mature agent system can have two kinds of intelligence, plus code:

                 +---------------------+
                 |    Frontier LLM     |
                 | planning, reasoning |
                 +----------+----------+
                            |
             +--------------+--------------+
             |                             |
+------------v-----------+    +------------v-----------+
|     Decision model     |    |  Deterministic code    |
| Jev, Laya, Kev, a      |    |  rules, calculations,  |
| fine-tuned encoder...  |    |  validation            |
+------------+-----------+    +------------+-----------+
             |                             |
             +--------------+--------------+
                            |
                     typed actions
                            v
                 +---------------------+
                 |     Application     |
                 +---------------------+

The LLM handles work that genuinely needs generation or extended reasoning.
The decision model handles repeated semantic judgements.
Code handles everything deterministic.

This is a more useful framing than asking whether Jev can replace an LLM. It also maps neatly onto the question of how much execution authority each step should have, which we cover in Horizontal vs vertical AI agents is the wrong question.

What the first evidence shows

The interface is genuinely new. Decisions with probabilities, not generated text.
Single decisions are faster, but modestly. Independent tests show gains well below the headline multipliers.
Batching is where it shines. Many judgements against one state become one fast, cheap computation.
The pricing favours many small judgements, especially when they share the same state.
Schema safety is not semantic safety. A perfectly valid answer can still be wrong.
Probabilities are only useful once calibrated against your own data.
The idea is bigger than one model. Several independent teams shipped open decision models within days of Jev's launch.

The bigger idea: AI needs a decision layer

For years the dominant pattern has been: give the model context and ask it to generate something. But many software decisions aren't generation problems. They are classification, routing, authorisation, prioritisation, risk and escalation problems. For those, asking a generative model to write an answer and then parsing it is expensive and fragile.

A decision model changes the primitive to state → typed, probabilistic judgement. That is valuable even if Jev itself doesn't become the dominant model; the open alternatives already make that clear.

The practical lessons will outlast any benchmark:

enumerate the decision space up front;
keep deterministic computation in code;
return probabilities, not prose;
calibrate thresholds on representative data;
escalate uncertain or high-cost cases to a stronger model or a person.

Frequently asked questions

What is a decision model in AI?

A model that returns a typed answer from a space you define (a choice, a score or yes/no) together with a probability, instead of generating free text. It is designed to be called by software as part of a workflow, not to chat with people.

Is Jev a replacement for LLMs like GPT or Claude?

No. Jev doesn't generate text, code or explanations. It complements a generative model by handling the many small, structured judgements inside a workflow faster and more cheaply, while the LLM handles reasoning and generation.

How is a decision model different from JSON or structured output from an LLM?

Structured output still generates tokens that are then constrained or parsed into a schema. A decision model makes the answer space part of the interface, so it can't return malformed or out-of-range answers, and it returns a probability for each decision. It can still choose the wrong option.

Are there open-source alternatives to Jev?

Yes. GLiNER2.5-Decide, Laya and Kev are open decision models, and tools such as simple-jev expose open models through a Jev-style interface. Their published benchmarks use different datasets and aren't directly comparable, so test them on your own data.

How we can help

We design and build decision layers for agents and high-volume workflows: identifying which judgements belong in a decision model, an LLM or code; evaluating Jev and open alternatives on your data; fine-tuning encoder models such as ModernBERT when data must stay in your cloud or region; and calibrating thresholds with monitoring for drift. A typical starting point is a short Architecture Sprint or a proof of concept on one workflow.

Want to know where a decision layer would pay off in your stack? Book a consultation.

Sources

TypeSafe AI: Introducing System One Models & Jev, Jev 1.13 known weak spots
Tom's Hardware: Jev claims 193x faster and 445x cheaper
TechCrunch: A new kind of AI model from a ChatGPT inventor
TrueStandard: Jev accuracy tested
Web of Mike: I benchmarked Jev on agent tool-call risk
Fastino: GLiNER2.5-Decide on Hugging Face
Convai Innovations: Laya on Hugging Face
Kev on GitHub, simple-jev by Featherless AI