Decision models: a probability instead of a paragraph
Jev started a new category in September. What it does, where it beats an LLM, where it doesn't, and how to run one on European data.

Decision models answer closed questions with a probability instead of writing text. What Jev and its successors do, where an LLM still wins, and what runs in the EU.
Most LLM calls inside an agent aren't asking for writing. Which tool next? Is this relevant? How urgent is this ticket? Closed questions dressed up as text generation.
Jev, released by TypeSafe on 15 September 2026, answers only those. Microsoft, OpenAI, Perplexity and dozens of open models have followed. It's a category now.
TypeSafe calls them System One models, after Kahneman: System 1 is the fast gut call, System 2 the slow, deliberate work. LLMs are System 2. Decision models are System 1.
A smart if statement
An LLM writes text for a person to read. A decision model doesn't write. You give it an input, a few questions, and the answers each question is allowed to have. It picks from your answers and says how sure it is. A smart if statement.
Three kinds of question, plus an experimental fourth for images:
Yes/no
“Does the customer need a reply today?”
- yes0.93
- no0.07
Pick one
“Which team should handle this?”
- billing0.86
- technical0.11
- account0.03
Scale
“How frustrated is the customer?”
Locate
“Where is the total on this receipt?”
x0.06 to 0.94
y0.80 to 0.93
The model answers. Your code decides what to do with each answer:
“Help! My payouts have been failing for 3 days and rent is due on Friday.”
Which team should handle it?
Billing
86% sure
Send it to the billing queue
Does it need a reply today?
Yes
96% sure
Move it to the top
How upset is the customer?
Frustrated
62% sure
Offer a callback
How that differs from asking an LLM for JSON:
- Many questions, one call. They run in parallel against the same input. One more question barely adds latency, and no question can contaminate another.
- It only knows what you send. If a question leans on your rules, the rules go into the question, and they have to fit: up to 32k per question.
- You pay for input only. There is no output to speak of.
- The probabilities are the API. You threshold, rank, route and escalate on them.
- Two kinds of sure. Every answer has a probability. Pick-one and scale answers also carry a confidence: how far ahead the winner is. "Scam" at 54% with "careless seller" right behind it is the cue to ask before acting.
What it is not:
- Not a writer. You can't drop Jev into Claude Code as "the model".
- Not a calculator. Counting, arithmetic and dates are documented failure modes. Do the maths in code, ask the model only the semantic part.
- Not a deep reasoner. Indirection and double negatives degrade it. It answers what you wrote, not what you meant.
- Not immune to its input. Adversarial text inside the input can steer it, much like .
An LLM writes, a decision model decides, code acts.
Framing is the product
Decision models reward question design far more than LLMs do. In one public phishing benchmark of 2,000 emails, a single question, "is this phishing?", got Jev to 63% and Haiku 4.5 to 81%. With the question split into five atomic parts and combined in code, Jev reached 95% and Haiku 93%, a gap too small to call. The decomposition closed the gap, and Jev did it at a twelfth to a twenty-seventh of the cost. A two-line regex reached 92%, which tells you how much of the work was in choosing the questions.
A vague question packs several judgments into one word, and the model has to guess how you weigh them. Switch between one question and five:
From IT Service Desk <support@acme-helpdesk.co>
Action needed: mailbox quota exceeded
Your mailbox will be suspended in 24 hours. Sign in at acme-mail.verify-portal.co to keep your messages.
Is this email phishing?
yes 58%Both emails land near the middle. “Phishing” packs five judgments into one word, and the model has to guess how you weigh them. No threshold separates these two safely.
The playbook:
- One judgment per question. If you catch yourself explaining what you meant after a wrong answer, that explanation was the missing half of the question.
- Combine in code. Ask about market size, feasibility and differentiation separately and weight them in code. When priorities change, you change a number, not a prompt.
- Give it a way out. Add "none of these" or "can't tell" to a pick-one. A yes/no has no "doesn't apply", so define what counts as no.
- Several can apply? One yes/no per label. There is no multi-select.
- Ask in English. The content can be in any language. The questions should stay in English: translated questions cost Jev up to 13 points on one Spanish benchmark, English questions over Spanish text cost nothing measurable.
Three more rulesfor whoever writes the questions
- Fan out speculatively. Extra questions in the same call cost almost nothing. Your code reads only the ones that apply.
- Trim the input. Irrelevant context lowers accuracy. Filter in code first, or run a cheap relevance question before the real ones.
- Shuffle options when you evaluate. Some models lean towards the first option. Measure how often the answer flips when you reorder.
Confidence is a design material
When every judgment comes with a probability, "how sure is the system?" stops being a vibe and becomes a value you design with.
The usual shape has three bands: above a high line, act. In the middle, suggest and let the user confirm. Below a floor, hand it to a person or a larger model. Where the lines go is a product decision: the cost of a wrong action against the cost of interrupting someone.
- Finnair 312.40Travel97%
- Notion 12.00Software96%
- VR 38.90Travel95%
- Scandic Hotels 189.00Travel93%
- Figma 15.00Software92%
- Uber 23.10Travel90%
- Apple 1,299.00Softwareshould be Equipment85%
- Wolt 42.30Meals82%
- IKEA 540.00Office suppliesshould be Equipment74%
- K-Market 18.40Meals66%
- PayPal 86.00Softwareshould be Travel57%
- Zettle 15.00Meals49%
Drag the top line down and more receipts file themselves, but the wrongly filed ones land there too, where nobody checks. Drag it up and you're safe, but tapping to confirm more often.
The same shape at scale: a decision model first, the uncertain tail to an LLM or a person. One build on Made with Jev classified 100 fraud emails with Jev in 1.42 seconds, sent the 31 below 95% confidence to a larger model, and got 96 right for about seven cents. The author's own figures, with no published code.
What cheap, calibrated judgments make practical:
- Generative UI that can't invent controls. The model picks from the components the interface already has.
- Flows that branch on meaning. The next question is a pick-one, not a hand-written if/else tree. Low confidence triggers a clarifying question.
- Agent steps you can show and audit. Every step is a typed decision with a probability you can display, log and explain.
- A judgment per keystroke. At around $0.00004 per decision, you can afford one per row, per frame or per keypress.
One firm line: for consequential decisions about people (credit, employment, housing, health, legal), a decision model is decision support with meaningful human review, never the sole decider. Microsoft says so in its own docs, and in the EU these are the uses the AI Act's high-risk obligations cover, from 2 December 2027 after the Digital Omnibus deferral.
Against Haiku 5.5 and GPT-6 Luna
Small, fast LLMs classify too. Artificial Analysis ran both kinds on the same tasks in its Decision Index, published 13 October 2026.
WildGuardTest: is this prompt or response harmful? Accuracy.
Source: Artificial Analysis Decision Index v1.0, 13 October 2026. LLMs run through structured output.
On safety and tool choice, decision models match or beat the LLMs at a tenth of the latency. On knowledge the LLMs win by a wide margin, and decision models are there. Trust the probabilities on classification and routing, not on trivia.
| If the job is… | Use |
|---|---|
| Classify, route, triage, gate, grade against a rubric, pick the next tool or UI element, prune context | A decision model |
| World knowledge, multi-hop reasoning, arithmetic, dates | An LLM, or a decision model with the hard part done in code |
| Any written output: a reply, a summary, an explanation | An LLM |
| Low volume, latency doesn't matter, no need for probabilities | Either. One Haiku call is fine and saves you a vendor |
| A confidence number that decides automate vs review | A decision model |
The numbershaiku-decides, 500 items per dataset
The independent haiku-decides benchmark put Haiku 5.5, thinking off and , against Jev and OpenAI Decisions.
| Dataset | Jev | OpenAI Decisions | Haiku 5.5, one call |
|---|---|---|---|
| Banking77 (77 options) | 79.9% | 79.3% | 79.1% |
| AG News (4 options) | 89.2% | 88.2% | 88.2% |
| BoolQ (yes/no) | 91.0% | 83.8% | 87.2% |
| SMS Spam (yes/no) | 96.6% | 97.2% | 96.2% |
| SST-5 (5 levels) | 55.8% | 50.2% | 52.6% |
- Accuracy: a wash. Indistinguishable on four of five datasets.
- Speed: not close. 140 to 280 ms against 0.8 to 1.2 seconds.
- Probabilities: the gap. Sampling Haiku ten times to estimate them cost 8 to 10 times more and was still worse calibrated.
- Cost: close. Haiku can even win when the hits.
- Option order: varies. With 77 shuffled options, Jev changed its answer on 4% of items, OpenAI Decisions on 30%, a single Haiku call on 22%.
What people build with them
The community catalogue Made with Jev lists 855 builds. The authors' own figures, grouped by the job the model does:
| Job | Example |
|---|---|
| Sort a pile too big to read | 100,000 posts, 14 yes/no questions each, in 20 seconds for $0.67 |
| Triage a queue | 500 emails sorted for 3.5 cents |
| Pick an agent's next action | Browser agents choosing the element to click, about 90 ms per decision |
| Decide inside a frame | Tetris at 0.3 s a move, Doom at about 10 decisions a second |
| Score before it ships | 61 rubric questions per draft in about a second, for $0.0004 |
| Block the risky step | Gates before a tool call, merge, install or post |
| Shrink what the LLM reads | Score each context chunk and drop the irrelevant ones instead of summarising |
| Judge every row where the data lives | A Postgres jev() function: 129 rows in about a second for $0.0009 |
The EU question
This is where the options narrow. Jev itself has no documented EU endpoint. For EU processing today, the practical choice is Microsoft-Decision-1 on Foundry, or open weights you host yourself.
| Option | EU processing | Notes |
|---|---|---|
| Microsoft-Decision-1 on Foundry, | Yes, within the EU data zone | Seven EU regions. Processing stays in the EU, not necessarily in the region you picked. Text only |
OpenAI Decisions on eu.api.openai.com | Yes | Needs approval, 10% price uplift, beta. Account and usage metadata can still leave the region |
| Open weights, self-hosted on an EU GPU cloud | Yes, wherever you put them | Verda runs data centres in Finland and Iceland. Iceland is , not EU |
| Jev, direct from TypeSafe | No documented EU endpoint | DPA, no training on customer data, for enterprise |
| OpenRouter, EU in-region routing | Not for decisions | The EU model list has zero decision models today |
| Vercel AI Gateway, EU inference region | Unconfirmed for these models | The feature exists and fails closed. Test each model |
For comparison, Claude Haiku 5.5 in the EU means Bedrock EU regions or Google Cloud's EU multi-region endpoint.
Language matters less than you'd expect. On a reading benchmark covering 122 languages, Jev scored 97% in English and a median of 91% across the rest. On a French suite, no model lost more than about a point against English. The rule that does matter: keep the questions in English even when the content isn't. Translating them into Spanish cost Jev 13 points on toxicity detection. Finnish is unmeasured, so test it.
For the engineers
Three things whoever runs the model will want to know. Everyone else can skip ahead.
One wire format, mostlyrequest and response shapes
There's no formal standard, but there is a de facto one: TypeSafe's POST /v1/systemone. Microsoft Foundry, OpenRouter, Opper and most open-weight servers speak it, so switching between them is a base-URL change.
{
"model": "jev-1.13",
"state": "Help! My payouts have been failing for 3 days.",
"questions": {
"team": {
"type": "choice",
"instructions": "Which team should handle this ticket?",
"criteria": { "billing": "Payments, refunds", "technical": "Bugs, outages" }
},
"urgent": { "type": "noul", "instructions": "Does the customer need a reply today?" }
}
}
noul is TypeSafe's name for yes/no. The response carries the versioned model ID and one typed answer per question:
{
"model": "jev-1.13.0",
"answers": {
"team": {
"type": "choice",
"choice": "billing",
"probabilities": { "billing": 0.91, "technical": 0.09 },
"confidence": 0.82
},
"urgent": { "type": "noul", "noul": 0.95 }
}
}
OpenAI is the outlier. Its /v1/decisions endpoint takes an input instead of a state, questions as an array, yes/no as predicate, options as a choices array, and returns a typed refusal per question. One thin adapter covers the differences.
For TypeScript teams, the Vercel AI SDK's experimental_decide normalises both shapes and lets you swap models per environment. Two caveats. It can run the same code on Anthropic and Google models through structured output, but then you lose the distributions that make decision models worth having. And it launched in September as experimental_evaluate and has already been renamed once.
Whatever you call it through, pin the model version. Aliases like jev-latest move, and your tuned thresholds move with them. Log the versioned ID from every response.
Text is ready, vision mostly means open weightswhat's production-grade
Text decisions are production-ready from several vendors: Jev 1.13, Microsoft-Decision-1, OpenAI Decisions on GPT-6 Luna (in beta), and Perplexity Decider, whose weights are also open.
Vision is less settled. OpenAI Decisions takes images, still in beta. Jev takes images and returns Box coordinates behind a header literally named TypeSafe-Danger-Zone-Images, and TypeSafe itself says it isn't production-ready. Microsoft-Decision-1 is text only. The strongest vision decision models on the open Jev Decision Index are 27B you host yourself.
The quotable result from that board: Perplexity's 4B Decider Flash scores 66.0 on vision decisions, ahead of a stock 397B vision-language model at 63.4, with a tenth of the of a stock 8B model.
Running your ownweights, serving, what it costs
Several open fine-tunes of a 27B base now score above hosted Jev on the open Jev Decision Index (16 October 2026). The index weights private test sets at 80%, so training on the public benchmarks doesn't help. Self-hosting is a serious option.
Check the licence. The top model on the board, StartLux-Decision v1.1, is CC-BY-NC, so no commercial use. Check the base model's licence too.
Pick weights
Apache-2.0 for products. A 27B model such as vLLM-SR d3 or Decider v1.2 for best quality, text and vision, about 56 GB in BF16. A 4B model such as Decider Flash for speed and small GPUs. Below 4B the index scores drop fast: the 4B models score 53 to 55 on text, the 2B model 39.
Serve with vLLM or SGLang
The server reads the decision from the option in one . A generic chat-completion call won't reproduce it.
Put a /v1/systemone shim in front
Most model repos ship one. Any TypeSafe client or your own code then calls it by base URL.
Calibrate on your own data
Labelled examples from your workflow, thresholds per question and per model version. The deployment is the easy part.
Latency is a wash. On the index's RTX PRO 6000 the leading 27B models answer in 70 to 150 ms, and hosted Jev measured around 130 ms per task at Artificial Analysis. Price rarely favours self-hosting either:
$0.01 / M input
$0.042 / M input
$0.10 / M input
$0.10 in, $0.50 out, 30 output tokens, no cache
1 × card, RTX PRO 6000 on Verda, on demand
At 1,000 tokens a decision, one dedicated GPU costs the same as Jev at about 1.1M decisions a day. Below that, hosted is cheaper and simpler.
Highlighted: cheapest at this volume. List prices, 19 October 2026, 30-day month. Self-hosting assumes one card sustains about 12,500 input tokens a second, plausible for a 4B to 9B model. Measure your own.
One card running around the clock on a GPU provider like Verda costs about $1,380 a month. The same money buys roughly 33 billion input tokens on Jev, about a million 1,000-token decisions a day. Below that volume the hosted APIs are cheaper and simpler.
You self-host for other reasons: the data stays where you put it, you can fine-tune on your own taxonomy or language (Jev isn't fine-tuned per customer), and the bill is flat at high volume. In return you pick models from a leaderboard that turns over weekly, recalibrate whenever you change weights or , and keep an inference port secure.
The short version
Decision models don't replace LLMs. They replace the part of your LLM usage that was never really generation: the closed questions that decide what happens next. That part gets faster, cheaper and, most usefully, honest about its own uncertainty.
An LLM writes, a decision model decides, code acts.
Intentface is an agentic experience company. If you want to find the closed decisions hiding in your product and design what happens at each confidence level, get in touch.
Sources
- TypeSafe docs: primitives, confidence, System One API, known limitations
- Introducing Microsoft-Decision-1 and Foundry deployment docs
- OpenAI Decisions guide and data residency
- Vercel AI SDK: Decisions
- Artificial Analysis Decision Index v1.0
- Jev Decision Index: scores quoted from v0.3.2, the index is at 0.4.1 at the time of writing
- Evaluating and Benchmarking the System One Model Jev: Belebele, 122 language varieties
- DecisionBench: the same questions in French and English, five models
- Galtea: Does an AI judge need to speak your customer's language?: Spanish and Catalan, and the effect of translating the questions
- haiku-decides: Haiku 5.5 vs Jev vs OpenAI Decisions
- Phishing shadow eval and its repo: one question against five, Jev and Haiku 4.5
- Fraud email triage build by Hassan (@nutlope), archived copy
- OpenRouter in-region routing
- Made with Jev: community builds and their published figures
- Verda: GPU pricing
Last updated .