Decision APIs, Explained: The Options Now on the Market, What They Are For, and How to Choose One
A decision API is a model endpoint that answers a bounded question, fast: which category does this belong to, which route should this request take, which action should the agent do next, is this allowed. You give it the situation and a short list of acceptable answers, and it returns one of them, usually in a fraction of the time and cost of asking a full language model to think out loud. In three weeks the idea went from one startup to a category. TypeSafe AI opened it with Jev on September 15. OpenAI previewed a Decisions API at DevDay on September 29 and opened it to all developers on October 6. Liquid AI, AWS, Perplexity, and Cloudflare shipped their own between September 29 and October 1, and on October 9 Microsoft released Microsoft-Decision-1, a decision model that returns a calibrated probability for every answer option. This post explains what a decision model is, where it belongs inside an agent, which options exist as of this week, and how to choose one without betting your architecture on a preview.
What is a decision model, and how is it different from a language model?
A language model is built to generate text. A decision model is built to pick. The difference sounds small and changes everything about cost, speed, and reliability.
When you ask a general model "is this email a refund request, a complaint, or spam," it composes a paragraph and you parse the paragraph. When you ask a decision model the same thing, it returns one of the three labels, often with a confidence figure, and nothing else. There is no prose to parse, no formatting to validate, and no temptation for the model to do anything other than choose.
Developers have been building this pattern for two years with prompts, JSON schemas, and post-processing. What changed this autumn is that the pattern became a first-class product with its own models, trained and priced for the job. OpenAI's own one-line description of its Decisions API sums up the category: use it to "check conditions, select from fixed options, and score text and images against a rubric."
Why does this matter for agents specifically?
Because an agent is a loop, and every turn of the loop contains a decision. Which tool next. Is this result good enough. Does this action match the task. Is this input safe to act on. Today most agents make those decisions by calling the same frontier model that does the reasoning, which is slow and expensive, and worse, it means the thing being checked and the thing doing the checking share the same judgment.
A decision model changes that in two ways. It makes the routine decisions cheap, which is the economic argument we made in the harness pattern post. And it makes the safety decisions independent: a fast, separate model can check every action an agent proposes against the task it was given, before the action runs. The vendors pitch exactly this use: TypeSafe lists guardrails and agent monitoring among Jev's jobs, and Vercel runs Jev in a command-safety classifier, according to Dealroom. A decision model is how the "human approval for irreversible actions" gate gets a machine assistant that never gets tired; the policy that decides which actions need that gate is the subject of our AI governance policy guide.
Which decision APIs exist right now?
As of October 10, 2026, from the vendors' own announcements and Dealroom's reporting. Everything in this table is new, and several items are previews; treat the specifics as provisional and check the vendor page before you build.
| Option | Who | What it is, per the vendor | Status | What to verify before depending on it |
|---|---|---|---|---|
| Jev | TypeSafe AI | A "System One" decision model built for software automation that returns typed values with probabilities; the company reports large speed and cost advantages over general LLMs | Announced September 15, 2026, as TypeSafe left stealth with a $40M seed round | Independent benchmarks, pricing at your volume, data handling terms |
| Decisions API | OpenAI | An endpoint on GPT-6 Luna for developer-defined questions over text and images: a probability for yes-or-no predicates, a pick with confidence scores for fixed choices, or a score against a range; pitched for classification, routing, and an agent's next action; OpenAI says up to 10x faster than GPT-6 Luna through the Responses API | Limited preview September 29; public beta for all developers October 6; $0.10 per million input tokens, with no output charges | Accuracy and calibration (OpenAI had published no figures at the time of writing), context limits, how dependent questions are chained, general availability date |
| Microsoft-Decision-1 | Microsoft | A small decision-scoring model post-trained from Qwen3.5-9B; instead of generating text it returns a calibrated probability for each fixed answer option, so the response carries its own confidence and can drive whether an application acts, defers, or asks for review; aimed at routing, classification, prioritization, verification, workflow control, agent guardrails, and AI judging; Microsoft says it was the most accurate model in its own 36-benchmark comparison and about 35x faster than GPT-6 Sol at median latency | Released October 9, 2026, in Microsoft Foundry and through OpenRouter; text-only with a 32,768-token context per the Foundry catalog listing; $0.042 per million input tokens, with output tokens free | Independent benchmarks (Microsoft's comparisons are its own, and the catalog's benchmarks tab gives a method but no figures), hosted-only access (no downloadable weights), data handling terms |
| Decision models and APIs | Liquid AI, AWS, Perplexity, Cloudflare | Liquid AI's d1 (September 29); AWS's open-weight Strands Decider 2B, Perplexity's Decisions API on its open-weight pplx-decider-v1-27b, and Cloudflare's Clef and Clef-flash under Apache 2.0 (all October 1), per Dealroom | Varies; check each vendor's documentation | Model size and where it runs (edge, cloud, your VPC), latency at your location, whether the weights are open, pricing |
| Do it yourself | Any small model | A fine-tuned small model or a constrained prompt with a JSON schema; the pattern developers have run for two years | Available now, with your own evaluation burden | Accuracy on your decisions, maintenance cost, who retrains it |
Three honest observations about the table. First, the only numbers above that are not the vendors' own claims are the dates. Speed, accuracy, and cost figures are what companies report about themselves, and we found no independent benchmark of any of these products at the time of writing. Second, look at what each option returns, not how fast it returns it. Microsoft-Decision-1 and Jev return a probability for every option, and OpenAI's API does for yes-or-no predicates, instead of a bare pick. That probability is exactly the signal you need to decide when an application should act, defer, or send the case to a person, so prefer an option that exposes it. Third, "do it yourself" belongs in the table because it is what most production teams are running today, and the question is whether a vendor's decision model beats what you already have on your own decisions, not on theirs.
Where should a decision model sit in your system?
Four places, in descending order of how often it pays off.
- Classification and triage. Support tickets, documents, images, leads, transactions. Bounded answers, high volume, measurable accuracy. This is the home run and the easiest to evaluate.
- Routing. Which queue, which workflow, which model, which tool. The decision is cheap and the cost of getting it wrong is usually a retry, not a disaster.
- Agent next-step and guardrails. Does this proposed action match the task; is this content safe to act on; should this run or wait for a human. This is the highest-value use and the one with the sharpest requirement: the decision model must be evaluated on your own cases before it gates anything that acts.
- Scoring against a rubric. Quality checks, compliance checks, "does this draft meet the policy." Useful, but rubric scoring drifts, so it needs a sampled human review loop.
Where it does not belong: anything that requires reasoning you cannot enumerate in advance. If the honest answer is "it depends on things I could not list," that is a language-model problem, and forcing it into a bounded decision produces confident wrong picks.
How do you choose one without betting on a preview?
Six questions, in the order we ask them with clients.
- Can you write the decision down? The question, the allowed answers, and fifty real examples with the answer you would want. If you cannot produce the examples, you do not have a decision yet; you have a vague hope.
- What is your accuracy bar, and who pays when it is wrong? A misrouted ticket costs a minute. A misjudged agent action can cost a customer. The bar sets whether a preview is acceptable.
- Build the evaluation before the integration. Run every candidate, including your own constrained prompt, against the same examples. We wrote the general method in how to evaluate LLM outputs; for decisions it is simpler and stricter, because every answer is right or wrong.
- Keep the interface thin. A decision call is a function: inputs in, one of N answers out. Wrap it so the vendor behind it can change without touching the agent. The category is barely a month old; you will switch at least once.
- Check the data terms. Where do the inputs go, are they retained, are they used for training. For a decision model reading customer tickets or loan documents, this is the question, not a footnote.
- Price it at volume, with the chaining cost. Decisions are cheap per call and called constantly, and a decision that depends on another one usually means a second call. Model the monthly bill at your real volume before you commit.
What we would do this quarter
Pick one high-volume classification you already do with a general model or a rule set. Write the examples. Run two vendor options and your own constrained prompt against them. Ship the winner behind a thin interface with a confidence threshold that sends low-confidence cases to a person. Measure for a month. Only then consider putting a decision model in front of an agent's actions, because that is where the category's real value is, and also where its mistakes stop being cheap.
Decision models are the first piece of the agent stack that got cheaper and safer at the same time. That is rare, and worth using carefully.
Sources: OpenAI, Decisions API is now available in public beta (October 6, 2026); TypeSafe AI, Introducing System One models and Jev (September 15, 2026); SiliconANGLE, TypeSafe AI exits stealth with $40M (September 16, 2026); Dealroom, Cloudflare launches Clef as TypeSafe's decision model idea spreads (October 2, 2026); Microsoft, Introducing Microsoft-Decision-1 (October 9, 2026) and its Microsoft Foundry catalog listing, as summarized by OrcaRouter in Microsoft-Decision-1: a model that answers with a number (October 10, 2026). Vendor capability, speed, and accuracy claims are the vendors' own. Status as of October 10, 2026; several products are in preview.
Related reading: Jev and the harness pattern · An AI governance policy for mid-market companies · The shape of AGI arrived before the intelligence did · AI agent development
