Attributed compile + one small offline smoke test

Primary sources (Microsoft, 2026-10-09): Microsoft-Decision-1: Our model for fast decision-making by Achint Srivastava (Command Line / Microsoft), Deploy and use Microsoft-Decision-1 in Microsoft Foundry (Microsoft Learn), and the OpenRouter model page for microsoft/microsoft-decision-1

Secondary: Microsoft launches a decision model built on Alibaba’s Qwen by The Next Web (2026-10-12)

Accuracy, latency multiples, flip rates, and internal Xbox/Copilot anecdotes are Microsoft's. I have no Foundry or OpenRouter key on this box, so I did not call Microsoft-Decision-1. What I ran is an offline request/response linter against hand-built mocks, described below as exactly that.

Microsoft shipped Microsoft-Decision-1 into Foundry and OpenRouter on 2026-10-09, three days after Liquid open-weighted d1. Satya Nadella's launch post on X cleared a million impressions within hours. Same category shift: stop asking a chat model for JSON and ask a decision model for typed probabilities.

The access difference matters. Liquid gave you weights. Microsoft gave you a hosted systemone endpoint, $0.042 per million input tokens with output free, and a Qwen3.5-9B base with an explicit plan to rebase onto MAI and OpenAI later. Same API shape either way. That rebase note is the catch.

What it actually returns

From Microsoft Learn and the OpenRouter page, a request is not a chat completion. You send a state (string or JSON) plus named questions. Each question is one of three types:

type you give you get back
noul a yes/no condition P(yes) in [0, 1]
choice named options with descriptions selected option + per-option probabilities
score an ordered rubric (2+ levels) probability-weighted level index

There is no free-form text and no written rationale. That is the point. Your code thresholds the probability, routes the ticket, or blocks the tool call. Learn's endpoint path on Foundry is:

<your-foundry-resource-endpoint>/providers/microsoft/v1/systemone
Enter fullscreen mode Exit fullscreen mode

The request's model field is your deployment name, not the string Microsoft-Decision-1. On OpenRouter the model id is microsoft/microsoft-decision-1, and OpenRouter documents that chat-completions SDKs will not work — you need the Decisions / System One surface.

What Microsoft is claiming

From Srivastava's post, labeled as vendor numbers:

  • Highest accuracy in Microsoft's 36-benchmark comparison (~150k questions kept blind from training).
  • ~35× faster (P50) than GPT-6 Sol in their latency test; 2.5× faster than H2O-Lightning-4B v1.1.
  • Under eight input perturbations, decisions flipped 1.3% of the time on average; zero flips when option descriptions were paraphrased or options were reversed/shuffled.
  • Xbox Research: competitive with GPT-6 Sol on labeling 10k+ feedback items, >14× faster and ~200× cheaper (Microsoft's framing).
  • Copilot quality scoring: competitive with GPT-5.6 Luna and ~100× faster (Microsoft's framing).

I did not reproduce any of that. Treat it as a launch claim sheet, then measure on your own labeled tickets.

First request shape (Foundry-style)

A single call can ask three questions over the same state. Pattern from Learn + OpenRouter:

import json, os, urllib.request

body = {
    "model": os.environ["DEPLOYMENT_NAME"],  # your Foundry deployment name
    "state": "Help! My payouts have been failing for 3 days.",
    "questions": {
        "is_urgent": {
            "type": "noul",
            "instructions": "Does this message convey urgency?",
            "criteria": {
                "true": "Explicitly time-sensitive",
                "false": "No urgency expressed",
            },
        },
        "team": {
            "type": "choice",
            "instructions": "Which team should handle this?",
            "criteria": {
                "billing": "Payments, invoicing, refunds",
                "technical": "Bugs, outages, integrations",
                "sales": "Pricing, upgrades, new accounts",
                "cannot_tell": "Not enough information, or not a support request",
            },
        },
        "frustration": {
            "type": "score",
            "instructions": "How frustrated is the customer?",
            "criteria": ["Calm", "Frustrated", "Very angry"],
        },
    },
}

req = urllib.request.Request(
    os.environ["AZURE_ENDPOINT"].rstrip("/") + "/providers/microsoft/v1/systemone",
    data=json.dumps(body).encode(),
    headers={
        "Content-Type": "application/json",
        "api-key": os.environ["AZURE_API_KEY"],
    },
    method="POST",
)
# with urllib.request.urlopen(req) as resp: print(resp.read().decode())
Enter fullscreen mode Exit fullscreen mode

Three things before production:

  1. cannot_tell is deliberate. A choice always picks one option. Without an abstention label, gibberish still gets a team. Learn says to include abstention when the model should not be forced.
  2. Option descriptions are the policy. "Payments, invoicing, refunds" does not cover "is this phishing email from you?". Write phishing into the criteria if it belongs in fraud/security.
  3. Auth is Entra ID or api-key. Learn prefers DefaultAzureCredential; the snippet uses an API key because it is shorter to read.

Cost arithmetic (list price, not a bill)

Microsoft and OpenRouter both list $0.042 / 1M input and $0 / 1M output. Output is free because there are no completion tokens in the chat sense — you get structured answers.

Illustrative only: 100,000 requests × 2,000 billable input tokens ≈ $8.40 of model input (ignores retries, retrieval, review, platform fees). That is why decision models look attractive for the boring 80% of routing.

OpenRouter lists a 32,768-token context, text in, structured decision out. No images or audio here (unlike Liquid's multimodal d1-omni).

What I actually ran (offline)

No Azure and no OpenRouter key on the box, so I wrote a small preflight that only checks shapes:

  • A legacy chat request (messages + temperature=0) is flagged as the wrong API.
  • A multi-question Foundry body with noul / choice / score lints clean.
  • A two-option choice without an abstention key gets a warning.
  • A hand-built mock answers object parses; a chat-completions-shaped mock raises ValueError: missing answers object.
  • The $8.40 figure above is the same list-price arithmetic the linter prints.

That is a smoke test of your client, not of Microsoft-Decision-1. Scripts live under runs/16-microsoft-decision-1/ (preflight.py, run_output.txt).

The Qwen-to-MAI rebase catch

Microsoft says Decision-1 was post-trained from Qwen3.5-9B, and that it will soon rebase onto other bases including MAI and OpenAI. The API shape is supposed to stay put while the weights under it change.

Practical consequences:

  • Do not bake "this is a Qwen model" into monitoring, eval harnesses, or compliance docs as a permanent fact. Pin the deployment / model version you evaluated.
  • Re-run your labeled set after any silent base swap. Calibration and flip rate are product claims; they are not a contract that survives a rebase without measurement.
  • If you needed open weights or air-gapped inference, this product is the wrong shelf. Liquid d1 (or another open decision model) is the local path; Decision-1 is the hosted path inside Foundry/OpenRouter.

How I'd wire it for an agent

  1. Gate tool calls with noul. "Does this tool argument touch production data?" — auto-allow only above a high threshold; otherwise ask a human or a stronger model.
  2. Route with choice + abstention. Escalate when cannot_tell wins or when top probability is below your threshold (start around 0.7 and tune).
  3. Grade agent steps with score. Rubric the proposed next action before you execute it. Microsoft's Discovery anecdote is exactly this pattern.
  4. Keep Decision-1 off consequential people decisions. Microsoft's own card and Learn page say not to use it as the sole basis for employment, credit, healthcare, and similar.
  5. Log state, criteria, answers, and the action you took. When something routes wrong, you need to know whether the bug was missing evidence, a bad option description, or your threshold.

Why this matters

Agent stacks are full of "call an LLM, beg for JSON, parse it." A hosted decision endpoint that returns calibrated probabilities, charges nothing for output, and already sits next to Foundry deployments is a concrete alternative for routing, gating, and grading. It does not replace a generative model for writing. It stops you from using one for a multiple-choice question.

Keep Liquid's open d1 for edge and offline. Use Microsoft-Decision-1 when you already live in Azure or OpenRouter. Measure both on the same labeled set before you trust either.

YongBo Yu is an AI engineer in Toronto building LLM workflows and agent systems. More at yongbo-yu.vercel.app and GitHub.