Software often needs a small decision, not a paragraph. A support ticket must go to a team. An agent must check whether it can run a tool. An invoice must pass a review.
Decision models address these tasks. They return answers within a set of options that the application defines. This conversation explains how they work, where they came from, and what to check before you use them.
The product examples describe the category as of 14 October 2026. APIs, prices and model capabilities can change.
Start with a support ticket
I keep reading that a decision model “does not write text.” Why is that useful?
Imagine that your application receives this ticket:
I paid for my order yesterday, but the payment does not appear in my account.
Your application needs a team name. It does not need an explanation of customer support.
You give the model the ticket and a question: “Which team should handle this?” You also give it the permitted answers: billing, shipping and returns.
A decision model scores these options and returns a typed result. Typed means that the answer follows a defined data type, such as a choice, a number or a probability. Your code does not need to extract a label from generated prose.
Here is an illustrative result. It is not a response from a specific API:
{
"answer": "billing",
"probabilities": {
"billing": 0.85,
"shipping": 0.10,
"returns": 0.05
}
}
Several models compute decision scores in a single forward pass through the model, rather than generating an answer one token at a time. The exact design differs between models.
So it is a classifier?
Yes, but with a more flexible interface than many traditional classifiers.
A traditional classifier usually learns a fixed set of labels during training. A general decision model can accept questions and answer options when you call it. You can use the same model for ticket routing, content checks and other bounded decisions without training a separate classifier for each task.
That does not mean it can answer every question well. You still need examples and tests for your task.
Three ways to ask a question
What kinds of answers can I request?
Many APIs use three basic question types. Names and result formats differ between providers.
| Question type | Example | What the application receives |
|---|---|---|
| Yes/no condition | Does this ticket contain a payment problem? | A probability that the condition is true |
| Choice | Which team should handle this: billing, shipping or returns? | Scores for the options and a selected answer |
| Score | How severe is this incident, using these levels from 1 to 5? | A score or a distribution over the defined levels |
TypeSafe uses the names noul, choice and score. OpenAI uses predicates, choices and scores.
For a score question, define a rubric: a description of what each level means. “Rate severity” is less useful than a scale that distinguishes a minor display error from a service outage.
Does a confidence value of 0.93 mean that the answer is 93% likely to be correct?
Not necessarily. First check what that field means in the API.
TypeSafe describes its confidence field for Choice and Score answers as a measure derived from the probability distribution. A distribution concentrated on one option produces higher confidence than a distribution spread across options. Its Noul answers do not include this confidence field.
Calibration is a separate property. A model is well calibrated when its probabilities match observed outcomes across many examples. For example, predictions assigned a probability near 0.8 should be correct about 80% of the time on a suitable test set.
A model can give a confident answer and still be wrong. A confidence threshold must be tested on your data.
The idea before the product category
Did decision models begin with Jev?
The underlying ideas are older.
Spam filters, sentiment classifiers and intent classifiers have made bounded decisions for years. Zero-shot classifiers can use labels without task-specific training. Rerankers score candidates. Applications also use generative language models to select actions from a list.
The newer category combines these ideas into a general decision interface: provide the state, define the questions, and receive typed answers with scores.
Here, state means the information needed for the decision. It can include a ticket, document, image or the current step of an agent workflow.
TypeSafe's Jev helped bring attention to this interface in September 2026. It did not invent classification or probability estimation.
Jev and the System One framing
Why did TypeSafe call it a System One model?
The name refers to the distinction between fast, intuitive judgment and slower, deliberate reasoning. It is a useful product analogy, not proof that a model works like a human mind.
The proposal is simple: do not send every small decision to a large model that generates text. Use a decision model for a bounded question. Use a generative model when you need an explanation, a summary or an open-ended response.
For example, a decision model can route a ticket to billing. A generative model can then draft a reply for that team.
Jev was offered as a hosted service. Developers could use its interface, but they could not inspect or run its model weights locally. This created interest in open alternatives.
Open alternatives and larger providers
Why did alternatives appear so quickly?
Developers could build on existing open-weight models instead of training a new model from the beginning. Projects such as Laya, Kev and Open-Jev explored different ways to return decision scores.
Some approaches add a decision head to an existing model. A decision head is the component that turns the model's internal representation into scores. Other approaches use the probabilities that a language model already computes.
Matching the request format is easier than matching the model's behavior. Two services can accept the same question and return very different probabilities.
What happened when larger providers joined?
The category expanded beyond text routing. Providers released hosted APIs, open weights and models for image, audio and video inputs.
These examples show the range:
- Cloudflare Clef and Clef-flash brought decision models to Workers AI and released open weights. Their inputs include text and images.
- AWS Strands Decider 2B uses a pointer head in place of a language-modeling head. Its published design scores the supplied options instead of generating text.
- Perplexity's pplx-decider-v1-27b added another open-weight model to the field.
- OpenAI's Decisions API provides predicates, choices and scores. Its public-beta documentation describes text and image inputs through
POST /v1/decisions. - Liquid AI's d1-3B and d1-omni-600M focus on local and edge use. The latter supports audio as well as text and images.
- Nace AI's Drex 1.5 is an open-weight decision model for agents and backend workflows.
- Microsoft-Decision-1 provides decision scoring through Microsoft Foundry.
These are not interchangeable in every respect. Input types, context limits, licenses, deployment requirements and confidence calculations differ.
A short timeline
Can I see the sequence without keeping track of every product?
This table keeps the main stages. It does not claim to list every release.
| Period or date in 2026 | Development |
|---|---|
| September | Jev draws attention to TypeSafe's System One interface. Open alternatives begin to appear. |
| 1 October | AWS publishes Strands Decider 2B. Cloudflare and Perplexity also join the decision-model wave around this period. |
| Early October | OpenAI makes the Decisions API available in public beta. |
| 7 October | Liquid AI releases open d1 models for text, vision and audio. |
| 9 October | Cloudflare announces Clef-omni. Microsoft's announcement describes Microsoft-Decision-1 in Foundry. Drex 1.5 is also reported in public coverage. |
The important change is not a single launch date. In a few weeks, a specialized interface became available through several deployment options.
Similar APIs do not mean identical behavior
Can I switch models by changing the base URL?
Sometimes that is part of the change. Several projects use a System One-style interface. OpenAI uses its own Decisions endpoint.
Even when request formats match, check the supported question types, option limits, input formats and response fields. Then rerun your evaluations.
Do not copy a confidence threshold from one provider to another. A value of 0.9 may have different meanings or different error rates in two systems.
Public benchmarks can help you select models to test. They do not establish which model is best for your workflow. Compare results only when the dataset version, metric and test conditions match.
Six useful workflow patterns
Where should I start using a decision model?
Start with a bounded task where you can identify errors and limit their consequences.
1. Route incoming requests
Classify support tickets, identify user intent or select a processing pipeline. Keep the available destinations explicit. Send uncertain cases to a fallback queue.
2. Check an agent's proposed tool call
Before an agent runs a tool, ask whether the call matches the user's request and whether required information is present.
A model check is an extra safeguard. It does not replace permissions, input validation or explicit approval for sensitive actions.
3. Triage and escalate
Use tested thresholds to separate cases that can proceed, cases that need another check, and cases that need human review.
A routing probability and an escalation probability answer different questions. Neither is an instruction by itself. Your application policy decides what action follows.
4. Evaluate responses against a rubric
Score relevance, grounding or completeness using defined levels. Compare model scores with human judgments. Check whether the model misses important errors.
5. Review documents and content
Check page types, invoice fields, sensitive information or suspicious content. A vision-capable model can use layout and visual marks that a text-only extraction may lose.
For exact arithmetic, use code. For example, calculate an invoice total deterministically, then use a model only for checks that need interpretation.
6. Select the next workflow step
Choose from permitted actions, decide which context to retain, or route an uncertain case to a larger model.
Local models can reduce network dependence and support edge applications. Measure latency on your hardware with realistic inputs. A vendor's fastest benchmark is not a guarantee for your application.
Where decision models can fail
What is the main risk?
A wrong answer can still have the correct type.
Your code may receive REFUND when the correct answer is EXCHANGE. The response parses successfully. The error becomes visible only when you examine the decision or its outcome.
There are several other limits:
- Bounded answers omit possibilities. If the correct action is missing from the options, the model may select an unsuitable one. Include an appropriate fallback and test it.
- Decision scores do not explain the answer. Use a separate process when a reviewer needs supporting evidence or an explanation.
- Complex reasoning remains difficult. A fast scoring model is not automatically a replacement for a reasoning model, a planner or a deterministic calculation.
- Untrusted inputs can influence decisions. Test misleading context and prompt-injection attempts. Keep policy instructions separate from input data where the API supports it.
- Confidence can drift. Changes to users, documents, questions or models can change error rates. Monitor the system after release.
- Sensitive decisions need stronger controls. Do not use a model as the sole basis for decisions about credit, employment, housing or healthcare. Check provider restrictions and applicable rules. Require meaningful human review.
Test the decision, not just the API
How do I know whether a model is ready for my task?
Write down the decision policy first. Then build a labeled test set from realistic cases.
Include clear cases, ambiguous cases, invalid inputs and cases that should go to a person. A small set of 50 examples can help you start. It is not enough to establish safety for a high-impact system.
For each candidate model:
- Define the question, options and rubric.
- Run the same labeled examples.
- Measure errors by class, not only overall accuracy.
- Check how probabilities relate to observed outcomes.
- Test thresholds on held-out examples that were not used to choose them.
- Measure latency, cost and fallback frequency.
- Review the consequences of each kind of error.
Version questions and thresholds like code. Record who owns the policy. Repeat the tests when the model, question or workflow changes.
Which model should I choose?
First ask what inputs you need, where the model must run, and what errors your workflow can tolerate. Then compare models on your own examples.
Check the license or service terms separately. Open weights do not always mean unrestricted use, and a shared interface does not imply a shared license.
The lasting rule is simple: use a decision model when the answer space is bounded and you can measure the cost of errors. Use generative or reasoning models when the task needs an open-ended response. Keep the application responsible for thresholds, permissions and escalation.
Continue learning
- The Evolution of Machine Learning and Artificial Intelligence
- Introduction to Software Development Lifecycle
Sources and further reading
- TypeSafe: Introducing System One Models and Jev
- TypeSafe: Confidence
- Cloudflare: Introducing Clef decision models
- AWS Strands: Introducing Strands Decider 2B
- Perplexity: pplx-decider-v1-27b model repository
- OpenAI: Decisions API documentation
- Liquid AI: Open d1 models
- Cloudflare: Clef-omni announcement
- Microsoft: Microsoft-Decision-1 in Foundry
- MarkTechPost: Nace AI releases Drex 1.5
Test Your Knowledge
No quiz available