Microsoft-Decision-1 Just Landed: First systemone Call, Free Output Tokens, and the Qwen-to-MAI Rebase Catch

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.

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:

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

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.

From Srivastava's post, labeled as vendor numbers:

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

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",
)

Three things before production:

cannot_tell is deliberate.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.api-key. DefaultAzureCredential; the snippet uses an API key because it is shorter to read. 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).

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

messages + temperature=0) is flagged as the wrong API. noul / score lints clean.answers object parses; a chat-completions-shaped mock raises ValueError: missing answers object. 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).

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:

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.