Microsoft-Decision-1 Goes Live: First systemone Call and Free Output

Microsoft has pushed Microsoft-Decision-1 onto Foundry and OpenRouter, timed right after Liquid's open-source d1 weights dropped. The track this model targets is clear: stop making chat models spit out JSON, and hand decision-making to a dedicated decision model that returns typed probability values.

The difference in how you access it is worth noting. Liquid gives you weight files; Microsoft gives you a hosted systemone endpoint, priced at $0.042 per million input tokens, free output, built on Qwen3.5-9B, with an explicit statement that it will later be rebased onto MAI and OpenAI models. The API shape is the same on both sides, but that rebase note is the real catch.

What It Actually Returns

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

type	You provide	You get back
noul	A yes/no condition	P(yes) in the range [0, 1]
choice	Named options with descriptions	The selected item + a probability for each option
score	An ordered rating scale (2+ levels)	A probability-weighted rank index

No free text, no written rationale. That's exactly the point. Your code takes the probabilities and applies its own thresholds to route, triage tickets, or block tool calls. The endpoint path on Foundry is:

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

The model field in the request holds your deployment name, not the string Microsoft-Decision-1. The model ID on OpenRouter is microsoft/microsoft-decision-1, and the official docs explicitly state that the chat-completions SDK won't work — you must go through the Decisions / System One interface.

What Is a "Decision Model"

A decision model is a class of model designed specifically for "choosing among a limited set of options," and its fundamental difference from a generative model lies in the output space. A generative model's autoregressive decoding process allows probability to be assigned over any token sequence, so its output is free text; a decision model constrains its output to a predefined structure — a yes/no judgment, a set of named options, or an ordered rating. This constraint brings three engineering benefits: first, no parsing is needed, since the return value is naturally a program-usable type; second, calibration can be optimized directly against the task objective during training, rather than relying on prompt luck; third, inference cost is extremely low, because no full sentence needs to be generated — only a few logits need to be computed in a forward pass. These models are often also called classifiers or discriminative models, but when hosted as an API endpoint that accepts natural-language instructions and criteria, they look more like a "programmable judgment function." Microsoft positions Decision-1 as a complement to generative models rather than a replacement, precisely on the basis of this positioning difference.

The Design Meaning of the noul, choice, and score Types

The three types correspond to three common categories of business judgment. noul returns a scalar P(yes), suited to binary gating, e.g., "does this request touch production data?" — the threshold is set by the caller, and the model doesn't decide for you. choice returns a distribution over named options, suited to multi-way routing; the key design point is that it always selects one, so you must explicitly provide an abstention option, otherwise the model is forced to give an answer even when evidence is insufficient. score returns a probability-weighted rank index, and the output is a continuous weighted average rather than a single integer, which lets "middle-of-the-road" judgments be distinguished by a threshold — suited to severity grading or step-quality scoring. What all three have in common is that none returns free text or a written rationale. This is deliberate: rationale introduces unparseable noise and makes evaluation difficult. The caller takes the probabilities and applies its own thresholds, leaving decision logic in its own code; the model is only responsible for supplying calibrated evidence.

What Data Microsoft Has Officially Provided

According to Achint Srivastava's blog, all of the following are labeled as vendor data:

• Highest accuracy in Microsoft's 36-benchmark comparison, with roughly 150,000 questions kept blind during training.
• In latency testing (P50), about 35x faster than GPT-6 Sol, and 2.5x faster than H2O-Lightning-4B v1.1.
• Under eight input perturbations, the average decision flip rate was only 1.3%; zero flips when option descriptions were rewritten or option order was reversed/shuffled.
• Xbox Research scenario: on 10,000+ pieces of feedback annotation, on par with GPT-6 Sol, more than 14x faster, and about 200x cheaper (Microsoft's wording).
• Copilot quality scoring: on par with GPT-5.6 Luna, about 100x faster (Microsoft's wording).

I haven't reproduced these numbers. Treat them as a launch claim, then measure them yourself on your own labeled ticket set.

The Shape of the First Call

A single call can ask three questions on the same state. The following pattern comes from the Learn and OpenRouter docs:

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"],
        },
    },
}

There are three things to watch before going to production. cannot_tell is deliberate — the choice type always selects an option, so without an abstention label, even gibberish gets assigned to a team. The Learn docs explicitly recommend adding an abstention option when a choice shouldn't be forced. Option descriptions are the policy itself: "Payments, invoicing, refunds" does not cover "Did you send this phishing email?" — if phishing falls under a fraud/security category, that has to be written into the criteria. Authentication supports Entra ID or api-key, and Learn recommends DefaultAzureCredential.

The Cost Math

Both Microsoft and OpenRouter list $0.042 / 1M input and $0 / 1M output. Output is free because this kind of call has no completion tokens in the traditional sense — you get structured answers.

For example: 100,000 requests × 2,000 billed input tokens ≈ $8.40 in model input cost (excluding retries, retrieval, moderation, and platform fees). This is why decision models look cost-effective for boring-but-80%-of-volume scenarios like routing. OpenRouter lists the context window at 32,768 tokens, text input only, structured decision output, no image or audio support.

Why Output Tokens Can Be Free

Traditional pricing bills both input and output tokens, because a generative model decodes autoregressively token by token, and output length is uncertain and directly consumes compute. A decision model's output is fixed-structure: noul needs only a single scalar, choice needs only a single softmax over a finite set of options, and score needs only a weighted index over an ordered rating. These computations are complete after the model's final forward pass, with no natural-language tokens needing to be generated, so there's essentially no marginal inference cost on the output side. Microsoft and OpenRouter pricing output at 0 reflects exactly this structural difference, not a marketing subsidy. Understanding this is practically useful for cost estimation: the cost of a decision call is determined entirely by the input side — that is, the total length of state plus questions plus criteria. Retries and input bloat are the main cost variables; the output is nothing to worry about.

The Qwen-to-MAI Rebase Is the Real Key

Microsoft says Decision-1 was post-trained from Qwen3.5-9B, and will soon be rebased onto other bases including MAI and OpenAI. The API shape is promised to stay the same, but the underlying weights will change.

There are three practical consequences. First, don't hard-code "this is a Qwen model" into monitoring, evaluation frameworks, or compliance documents as a permanent fact — pin the deployment/model version you evaluated. Second, re-run your labeled set after any silent base swap — calibration and flip rates are product claims, not contracts, and they don't hold after a rebase without fresh measurement. Third, if you need open weights or air-gapped inference, this product isn't for you; Liquid d1 is the local path, and Decision-1 is the managed path inside Foundry/OpenRouter.

What "rebase" Is and Why It's Trickier Than a Version Upgrade

In the post-training context, rebase means keeping the original interface, task definition, and output contract, but replacing the underlying base model wholesale, then redoing alignment training on the new base. This differs from an ordinary minor-version iteration — the weights, knowledge distribution, and tokenizer behavior can all change, and even generalization characteristics outside the training data can drift. For users, an unchanged API shape means the code doesn't need to change, but the model's calibration curve, its sensitivity to criteria wording, and its stability under different input perturbations can all be reshuffled. Microsoft swapping Decision-1's base from Qwen3.5-9B to MAI and OpenAI models is exactly the typical rebase scenario: the service name and endpoint stay the same, but after each swap, all the probability thresholds and flip-rate data you previously measured may become invalid. This is also why the article emphasizes pinning the "deployment/model version" rather than the model name, and re-running your labeled set after a swap.

How to Wire It Into an Agent

Guard tool calls with noul. "Does this tool argument touch production data?" — only auto-approve above a high threshold; otherwise hand it off to a human or a stronger model.

Route with choice + abstention. Escalate when cannot_tell wins or the top probability falls below a threshold; start tuning around 0.7.

Score agent steps with score. Rate the proposed next action against a rubric before executing it.

Don't let Decision-1 make high-stakes personnel decisions. Microsoft's own model card and Learn page both state that it must not be used as the sole basis for decisions in employment, credit, healthcare, and the like.

Log the state, criteria, answers, and the action you took. When routing goes wrong, you need to determine whether evidence was missing, the option descriptions were wrong, or the threshold was set incorrectly.

Why This Matters

The agent stack is full of the "call an LLM, beg it to output JSON, parse" routine. A hosted decision endpoint that returns calibrated probabilities, doesn't charge for output, and sits right next to your Foundry deployment is a concrete alternative for routing, gating, and scoring. It doesn't replace generative models for writing, but it lets you stop using a generative model to answer a multiple-choice question.

For edge and offline scenarios, keep using Liquid's open-source d1; if you're already in the Azure or OpenRouter ecosystem, choose Microsoft-Decision-1. Before trusting either one, test both on the same labeled set.

One-line Summary

Microsoft launches the hosted decision model Microsoft-Decision-1, which returns typed probabilities instead of text, targeting routing and gating scenarios.

Paragraph Summary

Microsoft pushes Microsoft-Decision-1 onto Foundry and OpenRouter, right after Liquid's open-source d1 weights. The model doesn't return chat text; instead, via the systemone endpoint, it accepts a state and named questions and returns three types of typed answers — noul (yes/no probability), choice (option distribution), and score (ordered-rating weighted) — leaving threshold judgments to the caller. Pricing is $0.042 per million input tokens with free output, built on Qwen3.5-9B, with official plans to rebase onto MAI and OpenAI in the future. Microsoft claims top accuracy across 36 benchmarks, roughly 35x faster than GPT-6 Sol, and only a 1.3% flip rate under perturbation, but these are all vendor figures. The article recommends it for agent tool-call gating, ticket routing, and step scoring, while cautioning to pin the evaluated version, re-measure calibration after a rebase, and never use it as the sole basis for major decisions in employment, credit, healthcare, and the like.