Not Every Decision Needs an LLM: Getting Started with Microsoft-Decision-1

Every AI team today is balancing the same three pressures: cost, accuracy, and performance. Large language models excel at generating text, but the latest generation relies heavily on step-by-step reasoning, and every reasoning step consumes tokens. Many tasks in production workflows, such as routing a request, classifying intent, or choosing the next action, don’t need that depth of reasoning. Decision Models are designed to fill this gap (they are sometimes described as “System One” models). Instead of producing long-form output, they make quick, focused decisions. This gives teams a lightweight decision layer that keeps costs predictable without sacrificing accuracy.

What are Decision Models?

LLMs have shown what AI can do when it comes to generating text and reasoning through complex problems. Many production tasks, though, don’t need an essay or a chain of thought. They need an answer the application can use right away. Decision Models are built for exactly that. They return structured outputs, such as a label, a route, or a choice, that software can act on immediately. When these decisions are fast and inexpensive, teams can build them into every step of a workflow without worrying about latency or token costs.

Microsoft-Decision-1 Model

Microsoft-Decision-1 is Microsoft’s new model for fast decision scoring, available in Microsoft Foundry and through OpenRouter. It is not another LLM in the usual sense. It belongs to the emerging category of decision models. Instead of writing a free-form response, it takes a fixed set of answer options and returns a calibrated probability for each one in a single pass. It supports yes/no questions, multiple choice, ratings, and rubric-based grading of AI responses and agent actions, all through a simple structured API call. Because the probabilities are calibrated, an application can use the confidence score to decide whether to act, defer, or escalate to a human. This makes the model a natural fit for the decision points inside modern AI systems, such as routing requests, classifying inputs, prioritizing work, verifying outputs, and controlling agent workflows.

Microsoft built it by post-training Qwen3.5-9B and plans to rebase it on other models, including Microsoft AI (MAI) and OpenAI models. In Microsoft’s benchmarking, it achieved the highest accuracy in a 36-benchmark comparison covering nearly 150,000 questions kept blind from training. It was also the fastest model measured: about 2.5 times faster than the runner-up and 35 times faster than GPT-6 Sol. The pricing reflects this design. Input tokens cost $0.042 per million, and output tokens are free.

Trying Microsoft-Decision-1 in Microsoft Foundry

The quickest way to see how a decision model behaves is the Microsoft Foundry playground. It requires no code. The developer describes a situation, defines the decisions to be made, and the model scores each one. The walkthrough below uses an incident-prioritization scenario to show the process.

Step 1: Open the Foundry project and deploy the model

Sign in to Microsoft Foundry and open a project. Microsoft-Decision-1 is located in the model catalog, select and deployed it. In this walkthrough, the model runs on a Global Standard deployment.

Microsoft Decision-1 on Foundry

Step 2: Open the playground

The model is accessed from the Build menu by selecting Models in the left navigation and opening Decision-1. The model page has four tabs: Playground, Details, Monitor, and Evaluation. The Playground tab is where the model can be tested interactively.

The playground is split into two panels. The left panel holds the input: a State and a set of Decisions. The right panel, Response, displays the model’s results. Foundry also provides ready-made samples as starting points.This example uses the case of "Prioritize an incident".

Decision-1 : Playground

Step 3: Describe the state

The State is the situation the model evaluates. It contains the facts the decision is based on. In this example, the state reads:

The checkout service has been unavailable for 20 minutes. Customers cannot complete purchases, and there is no workaround.

The state contains no question. It only describes what is happening. The questions are defined separately in the next step.

Step 4: Define the decisions in JSON

Every request to Microsoft-Decision-1 has three parts. The state is the content to evaluate, the model is the decision model that evaluates it, and the questions are the decisions to make about that content. The playground sets the state and the model separately, so the Decisions JSON field holds only the questions. They are written as a named map: each key is a name the developer chooses, such as urgent or priority. The model does not see these names. It returns each answer under the same key, which lets application code read results directly without any parsing.

Each question is defined with three parameters:

• type: the kind of decision. The value is noul, choice, or score.
• instructions: the question the model answers, or a statement it judges as true or false. A plain string is enough for most cases. It can also be an object when the question needs extra data, such as a record to compare against.
• criteria: what the possible answers mean. Its form depends on the type, as described below.

The three question types cover most decisions an application needs to make:

The urgent question is a noul. It returns one number. A value close to 1 means the model is confident the incident needs immediate attention, a value close to 0 means it does not, and a value near 0.5 means the model is uncertain. A noul has no separate confidence field, because a yes/no question has only two outcomes and the probability already shows how certain the model is. Applications typically compare this value against a threshold. They act automatically above it, ignore the incident below it, and send borderline cases to a person.

The priority question is a score. The criteria array defines three levels: position 0 is Routine, position 1 is Important, and position 2 is Urgent. The model returns a score between 0 and 2. Because the score is weighted across all levels, it can fall between them. A result of 1.9, for example, means the incident sits very close to Urgent. The score works best for ranking and setting thresholds, and should not be read as an exact measurement.

The example does not use a choice question, but this type is useful for routing and classification. Each option in criteria has a key and a short description, and the model returns the key of the best match. For instance, it could pick payments_team or infrastructure_team for this incident. Since the key comes back exactly as written, developers can name keys to match the values their code already expects.

Two practices make these questions more reliable. First, each question should ask exactly one thing. A question like “Is this urgent and customer-facing?” is better written as two separate noul questions combined in code. Second, several questions can share a single request, as in this example. Questions are evaluated in parallel, so adding more of them barely changes the response time.

{
  "urgent": {
    "type": "noul",
    "instructions": "Does this incident require immediate attention?"
  },
  "priority": {
    "type": "score",
    "instructions": "How high is the priority of this incident?",
    "criteria": [
      "Routine, no time pressure",
      "Important, some time pressure",
      "Urgent, immediate attention needed"
    ]
  }
}

The question is in the instructions field. This JSON contains two questions:

• urgent: “Does this incident require immediate attention?”
• priority: “How high is the priority of this incident?”

The other parts of each entry play supporting roles:

• The key (urgent, priority) is the name that labels the question and its answer in the response. The model never sees it.
• type tells the model what kind of answer to give: yes/no for noul, or a position on a scale for score.
• criteria (only in priority) lists the possible answer levels the model scores against.

The JSON never contains the incident itself. That goes in the State field, so the model reads the questions here and evaluates them against the state.

Step 5: Run and review the results

Selecting Run sends the state and the decisions to the model. The Response panel shows the result for each named question. A JSON toggle in the top-right corner switches between the visual view and the raw API response.

Decision-1 : Response

Token usage. The request used 86 input tokens and only 2 output tokens. An LLM would typically produce a paragraph of explanation. Microsoft-Decision-1 returns only the answers, and Microsoft prices output tokens at zero. At the announced rate of $0.042 per million input tokens, this request costs roughly $0.0000036. That works out to more than 275,000 similar decisions for one dollar.

The priority score. The model returned a weighted score of 1.9868 with 98.08% confidence. The panel shows the probability assigned to each level in the criteria array:

The weighted score is each level’s index multiplied by its probability, then added together: (0 × 0.0004) + (1 × 0.0124) + (2 × 0.9872) = 1.9868. The result sits almost exactly at level 2, which places the incident firmly in the Urgent tier. The high confidence value shows that the model’s probability is concentrated on a single level rather than spread across several.

The urgent noul. The yes/no question returned 99.75% true. The model is close to certain that a 20-minute checkout outage with no workaround needs immediate attention. As expected for a noul question, the result is a single probability with no separate confidence field.

What the application does with this?

These outputs are ready for code to act on without any parsing or interpretation. An incident-management workflow could apply simple rules:

• If urgent is above 0.9 and priority is above 1.5, page the on-call engineer immediately.
• If either value falls in a middle range, send the incident to a human reviewer.
• Otherwise, file it as a routine ticket.

Here, both answers clearly exceed those thresholds, so the system would escalate the incident at once. Each threshold depends on the cost of being wrong. Paging someone unnecessarily costs less than missing an outage, so the thresholds for alerting can be set lower.

This is the practical difference between a decision model and an LLM. The application receives a calibrated probability for every decision in a single fast call. It can act on that result directly, defer it, or escalate it, based on how confident the model is.

Conclusion: 

Decision models fill a gap that LLMs were never designed to cover. Not every step in an AI application needs generated text or extended reasoning. Many steps only need a fast, reliable answer to a well-defined question: whether a request is urgent, which team should handle it, or how a result ranks against a set of criteria. Microsoft-Decision-1 answers these questions with calibrated probabilities, in a single pass, at a small fraction of the cost and latency of an LLM. The incident example shows the pattern. Two decisions were returned in one call, using 86 input tokens and only 2 output tokens, and both came with clear confidence signals that application code can act on directly.

For teams optimizing AI systems for cost, accuracy, and performance, this gives them a new architectural option. The LLM can be reserved for the tasks that truly need it, while a decision model handles the routing, classification, verification, and control steps around it.

The next post in this series moves from the portal to code, calling Microsoft-Decision-1 as an API inside a RAG system that runs alongside a Foundry Local model. It will measure how a decision layer improves cost, speed, and answer quality in a real pipeline. Stay tuned!