A million routing decisions, each consuming 1,000 input tokens, would cost $42 in input charges at Microsoft-Decision-1's listed rate. That's a calculation from OpenRouter's $0.042-per-million input price, which also lists free output. For a developer deciding whether every incoming support ticket deserves a model call, the price makes frequent scoring easier to consider. It also changes what needs scrutiny: how the application turns a prediction into an action. The $42 assumes exactly that input volume, before retries or other services.
Microsoft introduced the model on October 9. Microsoft's announcement describes a system built by post-training Qwen3.5-9B to score predefined answers in a single pass. You supply the situation and the choices. It returns a probability for each answer. That makes the design of the question part of what the application does.
The choices are part of your code
In Vercel's decision API documentation, a choice question contains named options with descriptions. Its answer includes the selected option and each option's probability. A Boolean question instead returns a probability between zero and one. A score question uses an ordered scale with at least two labels and returns an interpolated score. These are different contracts: a category selects a destination, while a fractional score needs a rubric before it means anything useful.
That distinction is visible in Vercel's Microsoft-Decision-1 guide. Its documentation-feedback example asks separately which problem a reader reported and whether the problem prevented setup. The definitions make missing evidence of a block count as false. A developer could ask a different question, but would then be measuring something different. A probability about a reported failure cannot establish that the product actually failed. Someone still needs to check the product against the complaint.
The model card sets tight limits around this arrangement. Decision-1 is text-only, doesn't produce rationales, and isn't intended for questions that require knowledge absent from the input. It supports an explicit option such as "cannot tell." If your workflow needs an explanation, this endpoint won't supply one. If the evidence leaves a question unresolved, giving the model an abstention option is a way to represent that uncertainty in the application.
Cheap input still has a size
OpenRouter lists a 32,768-token context window, alongside the input-only pricing. The same arithmetic that produces the $42 example produces $420 for a million calls averaging 10,000 input tokens. Free output doesn't make long inputs free. For planning purposes, count the material actually sent to the model, including instructions and evidence, rather than budgeting against the length of the ticket alone.
Vercel's launch announcement says multiple questions can share the same input in one request. That creates a useful design choice for a ticketing system: ask where a ticket belongs and whether it needs urgent review against the same record. The questions remain separate, so urgency needn't be squeezed into every routing label. Whether combining them improves your application's cost or latency needs measurement on the requests you actually send.
What Microsoft's benchmarks establish
Microsoft says Decision-1 had the highest accuracy in its comparison across 36 benchmarks containing nearly 150,000 questions, with the benchmarks kept blind from training. It reports measured speed 2.5 times faster than H2O-Lightning-4B v1.1 and 35 times faster than GPT-6 Sol. Those are Microsoft's results on structured decision tasks. They provide a reason to test the model on a bounded classification job, without establishing the same speed ratio for your endpoint or the same accuracy on your labels.
The company also tested eight kinds of input changes and reports an average decision-flip rate of 1.3%. It says paraphrasing option descriptions and reversing or shuffling options produced no flips. This is a useful test for developers to repeat: reorder an unchanged set of choices and inspect whether the selected destination changes. Stability under those edits is a different measurement from whether the destination was correct.
For a deployment test, Microsoft's Foundry launch post recommends representative labeled inputs, including ambiguous cases, and checking errors by category. Its small example measures request latency including network time. The post explicitly says sequential requests don't measure behavior under production load. A support team evaluating the model should therefore include tickets that its own staff struggle to route, alongside ordinary requests, and test the traffic pattern the service will face. A clean result on a few obvious examples gives little information about those harder cases.
Access is broader than an Azure deployment
Microsoft's release material has a status mismatch. The Foundry blog calls Decision-1 a public preview, while the catalog labels its lifecycle generally available. Both describe an accessible model, but they don't agree on the release label. Teams planning a production deployment should check the terms attached to their chosen service rather than infer them from the announcement.
Vercel also made Decision-1 available on AI Gateway on October 9. It says Gateway credentials are sufficient, with no separate Azure account or deployment. Its model identifier is microsoft/microsoft-decision-1. For a team already using that gateway, this removes an account-setup step from an experiment. It doesn't answer the quality question, which still depends on the categories and evidence supplied by that team.
The Gateway documentation says the SDK decision interface requires ai version 7.0.128 or later, with an older experimental evaluation interface available on earlier AI SDK 7 releases. These calls use a decision-specific API. The documentation says they aren't supported through its Chat Completions or Responses endpoints. An existing chat integration therefore needs more than a model-name substitution.
A confident answer can still need review
The Foundry model card assigns the integrating application responsibility for confidence thresholds, escalation and downstream safeguards. It also excludes using the model as the sole automated decision-maker for consequential decisions about people. That matters when a classifier sits before a tool call: the score doesn't carry permission to perform the operation. Application code still needs to decide whether that operation is permitted for the current user and record.
Vercel's guide recommends reviewing incorrect predictions with high probabilities, as well as uncertain predictions. A threshold can't catch every error. One sensible first deployment is to display the suggested route beside the original ticket, leaving assignment with a reviewer until the team has measured mistakes. Keep the input with the answer so the reviewer can identify what the model misunderstood. This is especially useful when a complaint spans categories: confident selection of one route may hide the second problem.
Gateway offers optional decision fallbacks. According to its documentation, an uncertain successful response can trigger a rerun with another model. Both stages are billed and run sequentially, adding both calls' latency. That puts a price on the review policy as well as the first prediction. Measure the fraction of requests that need another pass before treating the cheapest initial rate as the cost of a completed decision.
Vercel says decision calls appear in Gateway logs and count toward configured budgets, alongside other model requests. Those controls make the new workload visible to the people operating the application. They track activity and spending. A team still needs expected answers to measure whether its routing policy works, so request logs should support an evaluation process rather than substitute for one.
The next thing to watch is behavior after updates. OpenRouter's description says the weights will change continually while the API stays the same. Keep a fixed set of labeled cases and rerun it when behavior changes. A stable interface won't tell you whether yesterday's review threshold still works.