Microsoft Decision-1 Explained: A Qwen Fine-Tune Priced to the Cent Like Jev ($0.042 per Million Tokens), the systemone API, Foundry Setup, and How It Compares with Jev, Clef, OpenAI's Decisions API and Amazon's Strands Decider

Microsoft Decision-1 is Microsoft's first decision model, released on October 9, 2026 in public preview on Microsoft Foundry. It does not write text. You hand it a situation and a fixed list of answers, and it returns a calibrated probability for each one, in a single pass, for $0.042 per million input tokens with output free. Two facts the launch coverage skipped. First, Microsoft did not build it from scratch: Decision-1 is a post-trained version of Alibaba's open-weight Qwen3.5-9B, and Microsoft plans to rebase it soon on other models, including Microsoft AI (MAI) and OpenAI models. Second, that price is not a coincidence. TypeSafe's Jev, the model that created this category in September, costs exactly $0.042 per million input tokens with output free. Microsoft matched it to the tenth of a cent, and then borrowed the endpoint name too: you call Decision-1 at /providers/microsoft/v1/systemone.

Jake runs a phone repair shop. Messages arrive all day through the shop's website and WhatsApp: "how much for a cracked S24 screen", "my repair from March has stopped working again", "you charged me twice", and a steady trickle of spam. Last month his nephew wired them into a chat model that wrote a polite paragraph back to each one and filed it under the wrong heading about one time in five. Ethan, who looks after AWS and a few APIs for local businesses, told him the job was never writing: it was sorting. "You want a yes or a no, or one label out of four, with a number that says how sure it is. That is a decision model." This page is what Ethan then worked through: what Microsoft Decision-1 is, what Microsoft actually claims and what it leaves out, the price against Jev, Cloudflare's Clef, OpenAI's Decisions API and Amazon's Strands Decider, how to deploy it on Microsoft Foundry and call the systemone API, how to write questions that get reliable answers, what to run if you want the model on your own machine or on AWS, and the errors you will meet first.

If the words tokens, API or model are still fuzzy, start with our guide to what an LLM is; everything below assumes only that.

What Microsoft Decision-1 is, and what a decision model does

In one line: Decision-1 is a decision-scoring model that returns calibrated probability scores for fixed answer options instead of generated text. You give it a state, which is the situation, as text or JSON, and one or more questions, each with a fixed set of allowed answers. It returns, for each question, the probability of each answer. It never produces a sentence, never explains itself, and never invents a fifth option when you offered four.

The industry name for this kind of model is System One, a term TypeSafe borrowed from Daniel Kahneman when it launched Jev in September 2026: System 1 is the fast, intuitive judgment, System 2 the slow, deliberate reasoning. Decision-1 adopts the vocabulary: its request pattern works like a system-one API, and the endpoint is literally named systemone. Decision-1 answers three kinds of question:

Those are Microsoft's names; "noul" is TypeSafe's word for a yes/no question, and OpenAI calls the same thing a "predicate." In the other framings people search for, it handles yes/no, multiple-choice, rating, classification and rubric-based questions, takes inputs of up to 32K tokens, and is text-only. What it does not do is just as important. Generation, open-ended question answering, conversation, translation and summarization are out of scope, and it never writes an explanation or a rationale.

Jake: "So it is a model that cannot talk. Why is that good?"

Ethan: "Because a model that can talk will talk its way into a wrong answer and make it sound right. This one can only point at one of the doors you showed it, and tell you how sure it is. For sorting your inbox, pointing is the whole job."

How Microsoft built it: a Qwen under the hood, and no weights to download

The recipe is simple: Microsoft took Alibaba's open-weight Qwen3.5-9B and post-trained it for fast, single-pass decision scoring, and it plans to rebase the model soon on others, including Microsoft AI (MAI) and OpenAI models. So the first Microsoft decision model is a Microsoft training run on an Alibaba base, which puts it in the same family as most of the open decision models that appeared in September: Cloudflare's Clef-flash is a Qwen3.5-9B too, Amazon's Strands Decider sits on Qwen3.5-2B, and H2O's Lightning on Qwen3.5-4B.

"Single-pass" is the technical heart of every model in this category. A chat model answers a multiple-choice question by generating tokens one at a time, which is slow and lets it wander. A decision model reads the state and the options once and reads the answer straight off the probability distribution, so the cost is one forward pass and the output is a set of numbers. That is where the speed and the price come from, and why output tokens are free: there are none.

Unlike Clef, Strands Decider or H2O-Lightning, Decision-1 is hosted only. Access is through Foundry only: there are no weights on Hugging Face and no download. If you want a decision model on your own hardware, the section on local alternatives below covers what exists today.

Microsoft's numbers: what is claimed, what is measured, and what is missing

Microsoft makes four kinds of claim, and it helps to separate them.

Accuracy. "Microsoft-Decision-1 achieved the highest accuracy in our 36-benchmark comparison, spanning nearly 150,000 questions across benchmarks kept blind from training." Separately: "We also took several of the top public models on the popular open leaderboard JevBench and tested them across 36 additional public and private benchmarks." An editor's note says the post "was updated from the original to add benchmarks for Jev on accuracy and calibration." What the post does not contain is a single per-benchmark score, so there is no number you can compare with the figures other vendors publish, and no independent JevBench result for Decision-1 is public yet.

Speed. "Microsoft-Decision-1 P50 latency is ~35x faster than GPT-6 Sol," and among the decision models it tested it was "2.5 times quicker than H2O-Lightning-4B v1.1, the runner-up." Microsoft measured both on its own deployment. Its argument for why speed matters is sound: "adding just 100 milliseconds to each of 20 sequential decisions adds two seconds to the overall workflow."

Robustness. Across eight kinds of perturbation, "Microsoft-Decision-1 changes its decision on 1.3% of perturbations on average with zero flips when option descriptions are paraphrased or when options are reversed or shuffled." That last clause matters more than it looks; option order steering the answer is the best-known weakness of this whole category, and our Clef guide shows it happening.

Safety. "We tested Microsoft-Decision-1 on 5,250 requests across 11 benchmarks, covering harmful content, jailbreak attempts, and prompt injection, and found that the model successfully refused harmful behavior while retaining a high degree of utility." Again, no figures.

The appendix names the six models Microsoft benchmarked against, and they are a useful map of the field. Here is what each one is, from its own model card or repository:

Two absences stand out. Jev itself was added only in the editor's note, and Cloudflare's Clef, the other hosted model with a global network behind it, is not in the list at all. When you read "highest accuracy," read it as highest among these six plus Jev, on Microsoft's benchmarks, measured by Microsoft.

Jake: "Thirty-six benchmarks and no scores? If I told a customer my repairs passed thirty-six tests and refused to show one, they would walk."

Ethan: "They would. The others publish their numbers on a public board, and Microsoft has not yet. It may be the best of the lot; today you cannot check, so you test it on your own fifty messages before you trust it. That is true of every model on this page."

How Microsoft uses it in-house: the four stories behind the launch

The most convincing part of the launch is not the benchmark paragraph but four internal deployments, each with a number attached:

• Xbox Research sorted "more than 10,000 open-ended feedback items" into fixed themes, with quality competitive with GPT-6 Sol, "over 14 times faster and 200 times less expensive."
• The Copilot team uses it to measure the quality of chat and agentic responses, "competitive with GPT5.6 Luna and 100 times faster."
• Incident response: on-call engineers' AI retrieval over logs, tickets and messages "performed better and faster than an LLM for knowledge retrieval."
• Microsoft Discovery, the scientific agent, grades each experiment against a rubric before replanning; the decision model was "46 times more consistent than the LLM-based score at three times the speed."

Read these as a job description. Sorting feedback into themes, grading responses against a rubric, routing an incident, deciding whether to replan: every one is a choice among options you already know. None is "write me something." If your task fits that description, a decision model is the right tool; if it does not, no decision model will help.

Microsoft Decision-1 pricing against Jev, Clef, OpenAI and Strands

Input tokens cost $0.042 per million. Output tokens are free. Here is how that sits against every hosted decision model you can call today, and the two free routes:

Three things to read off that table. Microsoft priced Decision-1 at exactly Jev's number, so the choice between them is not about money; it is about ecosystem, context length and whose benchmarks you believe. Cloudflare undercut both by four tenths of a cent the same day Microsoft launched, and its free tier on Workers AI covers thousands of short decisions a day at no charge. And OpenAI's hosted option costs 2.4 times Microsoft's, in return for a far larger base model and image input.

A worked bill, with every number an assumption to swap for your own. Jake's shop gets about 300 messages a week. Each one, with its question block, is about 300 tokens, so a month is roughly 390,000 input tokens.

At Jake's scale the price is a rounding error whichever you choose, and the deciding factors are accuracy on his messages and how little code it takes. At ten million decisions a month the gaps are real money, and they are still small next to what a generative model would charge to read the same tokens and write an answer; Microsoft's Xbox team put its own saving at 200 times. On Foundry, the standard deployment type is GlobalStandard; a DataZoneStandard deployment keeps processing inside a data zone and is available "in selected regions." Check the Foundry pricing page for your deployment type before you forecast a bill.

Microsoft Foundry: what it is, and how to deploy Decision-1 in five steps

If you have not touched Azure's AI tools for a year, the names have changed under you. The names went in this order: Azure AI Studio became Azure AI Foundry, which is now Microsoft Foundry, with the old portal living on as "Foundry (classic)." Foundry is the catalog and deployment layer for models on Azure: OpenAI's models, Microsoft's own MAI models and partner models sit in one catalog, you deploy the one you want into your own Azure resource, and you call it with an Azure identity or an API key. Decision-1 is listed there as a "Direct from Azure" model, version 1, in public preview.

Before you deploy, you need: an Azure subscription with a valid payment method, a Foundry project, permission to create deployments (the Cognitive Services Contributor role covers it), and a way to sign in, with Microsoft Entra ID recommended over an API key. Then:

1. Open the Foundry portal at ai.azure.com and go to your project.
2. Select Model catalog, search for Microsoft-Decision-1 and select it.
3. Select Deploy, choose the deployment type (GlobalStandard everywhere, or DataZoneStandard where offered) and a deployment name, then confirm.
4. On the deployment details page, copy the resource endpoint, the deployment name and, if you use one, the API key.
5. Open the Foundry Playground for the model and send one question before you write code; Microsoft's own demo there checks urgency, picks a support team and scores priority from a single customer message.

The same deployment from the command line, with your own names in the placeholders:

az cognitiveservices account deployment create \
  --name <ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --deployment-name <DEPLOYMENT_NAME> \
  --model-name "Microsoft-Decision-1" \
  --model-format Microsoft \
  --model-version "1" \
  --sku-name GlobalStandard \
  --sku-capacity 1

Change --sku-name to DataZoneStandard to keep inference inside the data zone nearest your application, where that type is available. The latency advice is worth repeating because it is the whole point of the model: create the Foundry resource in a region close to your users and benchmark it, since "a deployment type doesn't guarantee lower latency."

The systemone API: the request, the response and your first call

Requests go to your Foundry resource's decision endpoint:

<your-foundry-resource-endpoint>/providers/microsoft/v1/systemone

Two rules trip up first attempts. The model field in the body is your deployment name, not the catalog name, for example a deployment called pi-decision-1. And the response's own model field reports the underlying model, so it can read microsoft-decision-1 while your request said something else. A routing request for Jake's inbox looks like this:

{
  "model": "jake-decision-1",
  "state": "Hi, you fixed my phone screen in March and now the touch has stopped working on the left side. Is this covered?",
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What is this customer asking for? Select exactly one.",
      "criteria": {
        "quote": "Asking the price or time for a new repair",
        "warranty": "A problem with a repair already done by the shop",
        "billing": "Charges, invoices, refunds or payment problems",
        "other": "Anything else, including spam and greetings"
      }
    },
    "needs_human_today": {
      "type": "noul",
      "instructions": "Does this message need a reply from a person today?",
      "criteria": {
        "true": "The customer has a live problem or is upset",
        "false": "Routine, informational or spam"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated is the customer?",
      "criteria": ["Calm", "Mildly annoyed", "Frustrated", "Angry"]
    }
  }
}

Each question has a type, free-text instructions, and criteria: a map of option name to description for choice, an optional true/false pair for noul, and an ordered list from lowest to highest for score. Independent questions about the same state belong in one request: combining them means fewer requests and keeps the decision context consistent. The response carries an answers object keyed by your question names. A choice answer contains the selected option and a probability for every option; a noul answer is a probability from 0 to 1; a score answer is "the probability-weighted average of the level indexes," so a four-level scale runs from 0 to 3 and an answer of 2.4 means the model leans past "Frustrated" toward "Angry." The response also includes the model name and token usage.

Sending it with Microsoft Entra ID, the recommended sign-in:

az login
export AZURE_ENDPOINT="<your-foundry-resource-endpoint>"
export DEPLOYMENT_NAME="jake-decision-1"
export AZURE_ENTRA_TOKEN=$(az account get-access-token \
  --resource https://cognitiveservices.azure.com \
  --query accessToken --output tsv)

curl "$AZURE_ENDPOINT/providers/microsoft/v1/systemone" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AZURE_ENTRA_TOKEN" \
  -d @request.json

With an API key instead, replace the Authorization header with -H "api-key: $AZURE_API_KEY". Microsoft's Python quickstart uses nothing but the standard library plus azure-identity: it builds the same JSON, posts it with urllib, checks that each answer's type is choice and that the returned option is one you offered, and times each call so you get accuracy and median latency on your own labeled examples. That last habit is the one to copy. Microsoft's own instruction is to "replace EXAMPLES with representative, labeled examples from your workload before you use the measurements to make deployment decisions."

Jake: "So I write the four doors, and it tells me which one and how sure?"

Ethan: "And when it is not sure, the number says so. Your warranty message might come back 0.71 warranty, 0.22 quote, 0.07 billing. That 0.71 is the useful part. Below some line you pick, the message goes to you instead of being filed."

Writing questions that work: the rules, in plain words

A decision model is only as good as the options you hand it, and the failure modes are worth knowing up front. The model can reflect biases from its base model and training data; scores can change with how you phrase or order the questions and options, and a poorly framed question still returns a score; calibration is strongest on familiar task types, and the model can rely on outdated knowledge; and as a safety filter it can miss subtle harmful content or flag benign content. The best practices follow from those, and they apply to every model in this category:

• Validate on your own data first. Fifty labeled examples from your real traffic tell you more than any vendor table.
• Describe each option clearly and use "clear, neutral wording." The description is what the model matches against; a vague option attracts vague matches.
• Add an escape hatch. "Include an abstention option, such as cannot tell, when the model shouldn't make a forced choice." Jake's "other" bucket is that hatch.
• Set thresholds by the cost of being wrong. A missed warranty claim costs a customer; a mis-filed spam message costs nothing. Different thresholds.
• Randomize option order in testing and check whether the answers move. Microsoft reports zero flips on reversed or shuffled options; verify it on your questions.
• Use scores for ordering, not as absolute ratings. Microsoft's words: "prefer scores for relative ordering and thresholds rather than as absolute, calibrated ratings."
• Keep people in the loop where it matters. For decisions about credit, employment, housing, healthcare or legal matters, use the model for decision support with meaningful human review, never as the sole decision-maker, and tell affected users when AI contributed.

Turned into a routine you can finish in an afternoon:

1. Pull fifty real items from your own traffic and label them by hand, including the awkward ones you would normally skip.
2. Write your questions with one option description per outcome and an abstention option, then run all fifty and record the top probability for each.
3. Count the mistakes, then look at the probabilities on the wrong answers; most should sit low. Pick a threshold below which items go to a person, and check how many of the fifty that catches.
4. Shuffle the option order, run the fifty again, and compare; any answer that moves points to a weak description.
5. Run the same fifty through a second model, Jev, Clef-flash or a local Strands Decider, before you commit, since the request shape barely changes.

One more from the launch post that is easy to miss: a "90% prediction should be right about nine times out of 10 on representative cases." That is what calibrated means, and it is the property that lets you set a threshold and trust it. It is also the property most worth checking yourself, because no calibration figure has been published.

Decision-1 vs Jev vs Clef vs OpenAI's Decisions API vs Strands Decider

Five decision models now compete for the same jobs, and they differ in ways that matter more than price:

Every speed claim in that table is the vendor's own, measured on the vendor's own setup, and they are not comparable with one another. What the table does settle is fit. If your inputs include photos, Decision-1 is out and Clef or OpenAI is in. If you need more than 32K tokens of state, Jev or Clef. If you are already on Azure with Entra ID and Foundry governance, Decision-1 slots in with no new vendor. If the data cannot leave your building, Strands Decider or the open Clef weights. If you want the largest model behind the decision and will pay 2.4 times for it, OpenAI's beta. And the request shape is now nearly a standard: four of the five accept a state and a list of typed questions, so moving between them is mostly a URL change. Our guides cover each one in depth: Clef, Strands Decider, and the open-source Jev family.

Is Microsoft Decision-1 on Amazon Bedrock? The AWS reader's route

No. Decision-1 is an Azure model: it lives in Microsoft Foundry, and Amazon Bedrock has no decision-model category at all as of October 2026. If your stack is on AWS you have three honest options.

First, call Decision-1 anyway. It is an HTTPS endpoint, so a Lambda function or an agent running on Bedrock AgentCore can post to Foundry like any other API, with the cross-cloud latency and a second cloud bill that implies. Second, use Amazon's own decision model. Strands Decider 2B, released by Amazon's Strands Labs on October 1, 2026 by Marc Brooker, Mike Chambers and Fabio Nonato de Paula, is a 2-billion-parameter Qwen3.5-2B with its language head replaced by a pointer head of about a million parameters, open under Apache 2.0 with its training data and scripts, answering in about 115 ms on an RTX 3090 and 153 ms on an M3 Mac. It is not a Bedrock model either; it runs where you run it, on an EC2 instance, in a container, or on the laptop in front of you, and Microsoft thought enough of it to include it in its benchmark set. Our Strands Decider guide covers the install on Windows, Mac, Linux and Kali and a test on a CPU-only laptop. Third, if you want a hosted model with a free tier and no cloud account at all, Cloudflare's Clef-flash on Workers AI is reachable from any AWS Region.

Jake: "Amazon made one of these and gave it away, and Microsoft made one and charges for it?"

Ethan: "Amazon's is small enough to run on your shop PC; that is the gift. Microsoft's is more than four times bigger and runs on their servers; that is the service. For your three hundred messages a week, either costs less than one screen protector."

Can you run Microsoft Decision-1 locally? No, and here is what you can run

You cannot. Microsoft has published no weights for Decision-1, there is nothing on Hugging Face under Microsoft's name, and every description of the model is of a hosted service. Anything labeled "Decision-1 GGUF" is another model wearing the name. The underlying Qwen3.5-9B is open, but the post-training that turns it into a decision model is Microsoft's and is not released.

The open field is wide, though, and most of it runs on ordinary hardware:

For Jake's kind of workload, the 2B and 4B models are the sensible local choice: they answer in a fraction of a second on a laptop and the data never leaves the shop. The 27B-and-up tier exists for people who want to beat Jev on a leaderboard, and it needs hardware most offices do not own.

What to build with it: six jobs that are choices, not paragraphs

The intended uses are agent controls, model routing, intent analysis, data labeling, AI judging, incident response routing, data validation and content classification. Here is what each looks like as a question, in the shape Decision-1 takes:

• Inbox and ticket routing (choice): "Which team should handle this?" with billing, engineering and support as options, exactly Microsoft's quickstart. Jake's four doors are the small-business version.
• Agent guardrails (noul): "Does this tool call touch production data?" or "Are the arguments of this tool call grounded in what the user asked?" asked before the tool runs, with a threshold that blocks or escalates.
• Grading model output (score): "How well does this answer follow the rubric?" on a four-level scale, which is how Microsoft's Copilot team measures quality and how Microsoft Discovery decides whether to replan.
• Prompt-injection and content gates (noul): "Does this document contain instructions aimed at the AI rather than the reader?" The model can miss subtle cases, so pair it with your other filters.
• Model routing (choice): "Is this request simple, standard or hard?" to send cheap requests to a small model and hard ones to a large one. A few hundred tokens at $0.042 per million to save dollars on the other side.
• Incident triage (choice plus score): classify the incident type, score its severity from cosmetic to critical, and page accordingly, in one request.

The pattern across all six: the application already knows the possible outcomes, and the only question is which one. The moment you need the model to produce something new, a summary, a reply, a fix, you are back to a generative model: anything that creates, summarizes, rewrites or explains content is a job for a generative LLM. The two combine well. Decision-1 decides whether a request is worth answering and who should answer it; the generative model writes the answer.

Microsoft Decision-1 errors, and what each one means

The errors you are most likely to hit, and what causes each:

Three more that are not errors but feel like them. A score that comes back as 2.4 on a four-level scale is correct; it is a weighted average, not an index. A choice whose top probability is 0.4 is the model telling you it does not know; route it to a person rather than lowering your standards. And if every answer looks suspiciously confident, check whether your option descriptions are doing the work the state should: a description that quotes typical customer phrasing can match on wording alone.

The limits to know before you rely on it

Plan around these: text and JSON input only, no images or audio; inputs up to 32K tokens; no explanations or rationales in the response; public preview, with future versions planned on MAI and OpenAI models, which means the model behind the same deployment name may change; not designed or evaluated as the sole automated decision-maker in consequential decisions about people; calibration strongest on familiar task types; and sensitivity to wording and option order, which Microsoft reports as a 1.3% average flip rate under perturbation. None of these is unusual for the category. All of them argue for the same habit: label fifty real examples, run them, and read the numbers before you connect anything to production.

Jake's router has been live for a week. The four options and the two extra questions cost him under a cent a month, the "needs a human today" flag catches the angry ones within a minute, and the paragraph-writing model now only writes when a message has been sorted into a door where a reply is wanted. The one he still reads himself is the pile the model marks under 0.6, which turned out to be about one message in twelve.

A new category of model arriving every two weeks can feel like one more thing to keep up with. It is simpler than it looks. Decision models do one job, choosing, and they now come in five flavors that cost about the same and speak nearly the same language, so the right question is not "which is best" but "which fits where my code already lives." Jake did not need to understand Qwen or Foundry to get his inbox sorted; he needed four good option descriptions and a threshold. Ethan's advice to him is the advice for anyone reading this: label fifty real examples, run them through two of these models, and let your own numbers decide.

Revision note. Written October 10, 2026, the day after Microsoft released Decision-1. "Don't use a sledgehammer to crack a nut," says the English proverb; a yes-or-no question never needed a model that writes essays.