Microsoft Decision-1: What a Decision Model Is and When to Use It

Most calls inside an AI application are not requests for prose. They are decisions: which queue does this ticket go to, is this tool call safe to run, does this generated answer meet the rubric, which of four actions comes next. Teams have been making those decisions with a language model and a regular expression on its output, paying flagship prices for a yes or a no.

Microsoft Decision-1, announced on 9 October 2026, is Microsoft's answer to that waste: a model that scores a fixed set of options and returns a probability for each, without generating any text. This post explains what that means, how it differs from a large language model, what Microsoft claims and what is verified, and the use cases where it belongs. It is the companion to Which LLM should you use?, where Decision-1 appears as one of nine model families, and it reuses the agent and evaluation patterns from my Azure document-intelligence project.

The short answer

Decision-1 is a decision model, not a chatbot. Give it a text (the state) and a set of questions with fixed answers, and it returns a calibrated probability per answer in one pass: yes/no, one of several choices, or a position on an ordered scale. It is post-trained from Qwen3.5-9B, takes up to 32,768 tokens of text, costs $0.042 per million input tokens with free output, and runs in Microsoft Foundry and on OpenRouter. Use it for routing, classification, prioritisation, agent gates and grading. Use a language model when the answer has to be written.

What is the difference between a decision model and an LLM?

A language model generates an answer token by token; a decision model evaluates options you supply and scores them. The difference is the contract, not the intelligence. With an LLM you write "analyse this complaint and say what we should do", receive a paragraph, and parse it, hoping the format holds. With a decision model you send the complaint plus the options "refund, replace the order, escalate, do nothing", and receive a probability for each. Figure 1 shows the two flows on the same input.

How does the Decision-1 API work?

The request has three parts: the text to score, the questions, and the deployment name. Each question has a type, instructions and the allowed answers. Microsoft Learn documents three types in the Foundry Decisions API, and the Decision-1 catalogue entry lists the same shapes under different names: yes/no, multiple-choice and rating.

This is the shape of a choice question and its answer in the Foundry Decisions API, as documented by Microsoft Learn on 21 October 2026. The values are illustrative, like Microsoft's own example.

{
  "model": "YOUR-DEPLOYMENT-NAME",
  "input": "I was charged twice for my order.",
  "questions": [
    {
      "type": "choice",
      "name": "department",
      "instructions": "Which department should handle this complaint?",
      "choices": [
        { "value": "billing", "description": "Payments and refunds." },
        { "value": "technical", "description": "Product problems." },
        { "value": "shipping", "description": "Delivery and tracking." },
        { "value": "other", "description": "All other requests." }
      ]
    }
  ]
}

{
  "type": "choice",
  "name": "department",
  "choice": "billing",
  "probabilities": [
    { "value": "billing", "probability": 0.95 },
    { "value": "technical", "probability": 0.02 },
    { "value": "shipping", "probability": 0.01 },
    { "value": "other", "probability": 0.02 }
  ],
  "confidence": 0.93
}

Four rules from the documentation that save a week of debugging:

1. Give every question a unique name. The answers array comes back in the same order, and the name is how you match them.
2. Put independent questions in one request. Several questions about the same text are one call; a question that depends on an earlier answer is a second call.
3. Include a fallback option such as "other" or "cannot tell" when the categories do not cover every input, and treat a refusal as different from a low probability.
4. Choose each threshold on labelled examples from your own application, based on the cost of a false positive and a false negative in that scenario.

The Microsoft Learn how-to for the Decisions API uses the gpt-6-luna model and the /openai/v1/decisions endpoint; Decision-1 is deployed from the Foundry catalogue as its own model with the same three question types. Check the catalogue entry for the exact endpoint of your deployment.

What does Microsoft claim, and what is independently verified?

Everything below comes from Microsoft's announcement and its Learn pages. None of it had been reproduced by an independent evaluation on 6 November 2026, and third-party write-ups note that the Foundry catalogue describes the benchmark methodology without publishing figures. Read the table as the vendor's claims.

The honest reading: the architecture argument is sound and the price is real, and the quality numbers are what you should measure yourself on a few hundred labelled examples before trusting a threshold.

When should you use Decision-1 instead of an LLM?

Ask one question: can you list every acceptable answer before the call? If yes, and you do not need a written explanation, a decision model fits. If the answer has to be written, summarised or explained, it does not.

The architectural takeaway is the same one that runs through the LLM comparison: an agent might make thirty decisions during one run, and most of them do not need a reasoning model. A lightweight decision model handles the gates and the checks; the powerful model handles the planning and the writing.

Where does a decision model sit in a real system?

Figure 2 shows the three places I put it: support triage, an agent loop, and an evaluation pipeline. Tap a layer to read what happens there.

Support triageAgent loopEvaluation and labelling

Every ticket is scored once: is it urgent, which department, how frustrated is the customer. A language model only writes the reply, and only for the tickets that need one.

1. IncomingEmail, chat, web form
2. Decision modelMicrosoft Decision-1
3. RoutingQueue per departmentSLA timers
4. Reply draftingGPT-6.1 TerraClaude Sonnet 5.5
5. Quality gateMicrosoft Decision-1
6. PeopleAgent review

Typical use: Help desks, shared inboxes, form submissions and any queue where thousands of items a day need the same few labels.

Tap a layer to read what that technology does in this stack.

Support triage. Every ticket is scored once: is it urgent, which department, how frustrated is the customer. A language model only writes the reply, and only for the tickets that need one. Typical use: Help desks, shared inboxes, form submissions and any queue where thousands of items a day need the same few labels.

Layer	Technology	What it does
Incoming	Email, chat, web form	The text of the ticket is the state the model scores; the customer record can be appended as context.
Decision model	Microsoft Decision-1	Three questions in one call: urgent? (yes/no), department (choice), frustration (score). Each answer is a probability per option.
Routing	Queue per department, SLA timers	Thresholds you chose on labelled tickets decide the queue; everything below them goes to a person.
Reply drafting	GPT-6.1 Terra, Claude Sonnet 5.5	A mid-tier language model drafts the answer with the retrieved policy; this is the only step that generates text.
Quality gate	Microsoft Decision-1	A rubric question grades the draft: grounded in the policy? polite? complete? Low scores go back or to a human.
People	Agent review	Humans see the uncertain cases and the samples you audit; their labels feed the next threshold review.

Agent loop. A reasoning model plans and writes; a decision model gates every tool call and checks every result. Thirty decisions per run cost cents instead of dollars. Typical use: Agents that touch real systems: CRM updates, payments, deployments, anything where a wrong tool call has a cost.

Layer	Technology	What it does
Task	User goal	The task in natural language, plus the context the agent is allowed to see.
Planning	Claude Opus 5.5, GPT-6 Sol	The reasoning model decides what to do next and drafts the tool call.
Pre-action gate	Microsoft Decision-1	Is this call within policy? Is it a write? Does it need approval? Three yes/no questions, scored in one pass before anything runs.
Tools	MCP tools, APIs and databases	The same tool registry serves the agent and the MCP clients; permissions are per role.
Post-action check	Microsoft Decision-1	Did the step succeed? Continue, retry or escalate: a choice question over the tool output.
State	PostgreSQL, Redis	Checkpoints of the loop, so a run can pause for a human and resume.
Observability	OpenTelemetry traces, MLflow	Every decision, its probabilities and its cost end up in one trace per run.

Evaluation and labelling. Grading thousands of model outputs or labelling a dataset is a decision per item. A decision model does it consistently and cheaply; a language model judge is sampled for the written rationale. Typical use: LLM evaluation pipelines, data labelling, content moderation queues and regression tests before a model upgrade.

Layer	Technology	What it does
Items to grade	Model outputs or raw records	Answers from the candidate model, or unlabelled records waiting for a category.
Rubric	Ordered levels with criteria	Each level has observable criteria; adjacent levels must differ clearly, or the probabilities blur.
Scoring	Microsoft Decision-1	A score question returns a probability per level and a weighted score; a choice question returns the label.
Sampled rationale	LLM judge, Human audit	A small sample gets a written explanation from a language model and a human check, to catch drift in the rubric itself.
Tracking	MLflow, Dashboards	Scores per model version, per prompt version and per document set, side by side.
Feedback	Prompt and threshold updates	Rubric, thresholds and prompts change on evidence; the same set is rerun before every upgrade.

The agent loop is the one that changes the economics most, so Figure 3 draws it in full.

The pattern in words:

1. Plan. A reasoning model (Claude Opus 5.5, GPT-6 Sol) reads the task and drafts the next tool call.
2. Gate. Decision-1 answers three yes/no questions over the draft: within policy, a write action, needs human approval. Thresholds come from labelled examples; anything uncertain waits for a person.
3. Act. The tool call runs through the same registry that serves MCP clients, with permissions per role.
4. Check. Decision-1 scores the tool output with a choice question: continue, retry or escalate.
5. Record. The state goes to a checkpoint in PostgreSQL or Redis so the run can pause and resume, and every decision with its probabilities and cost lands in the OpenTelemetry trace.

This is the same approval-gated agent I built for the Azure document-intelligence project; the difference is that the gates were language-model calls then, and a decision model makes them cheaper and more consistent.

What does it cost at scale?

Arithmetic at list price, not a quote. Three workloads, each with the assumptions stated, compared with the same tokens on GPT-6.1 Terra at $1 per million input tokens (output not counted, which flatters the LLM).

The ratio is the point: at the same token count the decision model costs about 4 percent of a mid-tier language model's input price, and it produces no output tokens at all. Latency moves the same way, from seconds to milliseconds, which is what makes thirty gates per agent run acceptable.

What are the limits?

• No explanation. The model returns probabilities and nothing else. When a user or an auditor needs a rationale, add a language-model call for the sampled cases.
• Text only, 32K tokens. No images, audio or video; long documents must be chunked or summarised first. For images, the Foundry Decisions API with gpt-6-luna offers the same question types.
• Closed weights. No download, fine-tuning, quantisation or self-hosting. If you need that, the base model Qwen3.5-9B is open, and a classifier trained on your labels remains the classic option.
• Vendor benchmarks only. Speed, accuracy and calibration figures are Microsoft's own as of 6 November 2026.
• A moving base. Microsoft plans to rebase Decision-1 on other models; keep the labelled set and rerun it on every version, as you would for any model retirement.
• Not for consequential decisions about people. The model card rules out sole reliance for credit, employment, housing, insurance, education, healthcare and legal rights.
• Thresholds are yours. A probability is only useful with a threshold you chose on your own data, and a low top probability means a person, not a coin flip.

How do you set the thresholds?

1. Collect 200 to 500 labelled examples per question from real traffic, including the ugly ones.
2. Run them through the question as written, and store the probability per option.
3. Plot precision and recall against the threshold for each option, and pick the point where the cost of a false positive and a false negative balance for that scenario.
4. Define the escalation band: everything between the thresholds, plus refusals, goes to a person.
5. Monitor drift weekly: the share of escalations, the agreement with human labels on a sample, and the distribution of top probabilities. A shift means the inputs changed or the model version did.
6. Rerun the set on every new version of the model before switching the deployment.

Which service should you choose for a decision?

Figure 4 is the three-question guide. It ends in Decision-1 more often than you would expect, and in a language model whenever the answer has to be written.

Sources

• Microsoft, Microsoft-Decision-1: Our model for fast decision-making, Achint Srivastava, 9 October 2026: base model, question types, calibration target, latency and accuracy comparisons, internal use cases, price and availability. Read on 6 November 2026.
• Microsoft Learn, Foundry Models sold by Azure, page dated 21 September 2026 and updated 29 October 2026: the Microsoft-Decision-1 row (decision, text classification, zero-shot classification; calibrated decision scoring; yes/no, multiple-choice, rating, classification and rubric-based questions; single-pass scoring over inputs of up to 32K tokens; text only; no explanations).
• Microsoft Learn, Use the Azure OpenAI Decisions API, page dated 21 October 2026: the predicate, choice and score question types, the request and response shapes, refusals and threshold guidance.
• Microsoft Foundry catalogue, Microsoft-Decision-1: the abstention option and the restriction on consequential decisions about people. The catalogue opens inside the signed-in Foundry portal; those two points are as quoted by the write-ups below, so check them in your own tenant.
• OpenRouter, microsoft/microsoft-decision-1: the listing of 9 October 2026 with the same price.
• Third-party write-ups read on 6 November 2026 for the independent-verification status (no published benchmark figures on the catalogue entry; weights not distributed): eesel.ai and Orca Router. Their numbers are not used here.
• My own study notes of November 2026 on the use-case table, the agent loop, the cost arithmetic and the threshold procedure, written from the projects on this site. The cost figures are list-price arithmetic on stated assumptions, not quotes.