Microsoft Decision-1 Matches Jev on Price and API Shape

Microsoft released Microsoft Decision-1 on October 9, a decision model in Microsoft Foundry that scores a fixed set of options instead of writing text. It costs $0.042 per million input tokens with free output, which is exactly what TypeSafe charges for Jev, and its request format follows Jev's almost field for field.

With the price identical, the case for Decision-1 rests on speed. Microsoft says 85 ms per decision, timed from inside its own Azure region. An independent run on JevBench a day later measured 459 ms.

Microsoft Decision-1 is a Qwen model tuned to score options

Achint Srivastava, VP of software engineering in Microsoft's Office of the CTO, announced it. Decision-1 is built for routing, classification, prioritization, verification and workflow control. You give it a situation and a bounded question, and it returns a calibrated probability for each option. It supports yes or no gates, multiple choice and rating scales, plus rubric grading of AI responses and agent actions.

Under the hood, Microsoft post trained Qwen3.5-9B, Alibaba's open weight model, for fast single pass decision scoring. The post says Microsoft will "soon rebase" it on other models, including Microsoft AI and OpenAI models. The Register noted that Microsoft gave no reason for the rebase.

Microsoft's launch post links both the Foundry catalog entry and an OpenRouter page. When I queried OpenRouter's public model list on October 11, no Microsoft decision model was in it, which matches The Register's wording that OpenRouter access is coming "soon". Today it's a Foundry deployment.

The API is Jev's, with an Azure endpoint

Microsoft's deployment guide says the request pattern "is similar to a system-one API". The endpoint path ends in /v1/systemone. The body has a state (text or JSON) and named questions, each with a type of noul, choice or score, plus instructions and criteria. That's the shape TypeSafe documents for Jev, down to the name Noul for a yes or no probability. I walked through those primitives in my Jev explainer and test.

So a working Jev integration should move to Foundry with a handful of changes rather than a rewrite. Here's what differs, from the two vendors' docs:

The Jev models page publishes its context limit and rate limits (100K tokens per second, 80 requests per second). Microsoft's guide publishes neither: throughput is whatever quota your deployment has, and a 429 means you've exceeded it. JevBench's run of Decision-1 counted 21 failures on context limits, so send your longest real states in the first test, not your shortest.

Microsoft's chart puts Jev a whisker behind

Microsoft updated its post after launch to add Jev to the charts. Here are the main rows from the data behind them (I left out three smaller models; the full set is in Microsoft's post). It doesn't support a clean win on every axis:

Accuracy is 1.2 points apart, which is close enough that your own data will decide it. Calibration goes the other way, and Microsoft's own chart ranks Decision-1 third, 1.5 points behind Jev. The latency column also mixes two methods: the other models use the JevBench adjusted median checked October 7, while Decision-1 was "measured through Foundry in the same region", the most favourable network path a hosted model can get.

JevBench then ran its own test. Its October 10 changelog records a native Foundry run of Decision-1 on 1,500 questions: a Capability score of 70.78, Calibration of 84.40, and a median latency of 459 ms on its 124 request speed subset, with those 21 context limit failures counted against it. That's a different benchmark set and method from Microsoft's, so 84.40 isn't directly comparable with Microsoft's 92.2, and the latency gap mixes different network paths. Still, 459 ms is the number I'd plan around until you've timed your own path.

Microsoft-Decision-1 (What an odd release?!?)

85 ms versus 459 ms on a 20 step agent loop

Microsoft's own example: 100 ms extra on each of 20 sequential decisions adds two seconds. Run that chain through each figure:

• At Microsoft's 85 ms median: 1.7 seconds of decision time.
• At the 240 ms Microsoft charts for Jev: 4.8 seconds.
• At JevBench's 459 ms for Decision-1: about 9.2 seconds.
• At the 3,010 ms Microsoft charts for GPT-6 Sol: about 60 seconds.

Even the slowest decision model figure beats sending those calls to a frontier model by a factor of six, before cost enters. Microsoft's cost chart, built on three game review and livestream datasets, scales to about $11 per million classified texts on Decision-1 against about $2,434 on GPT-6 Sol, because the decision model pays only for input. My arithmetic for a typical 500 token decision lands at $21 per million decisions on either Jev or Decision-1.

That's the pattern I'd use Decision-1 for: a gate on an agentic loop that decides continue, retry or escalate, not a replacement for the model doing the work. It's the same job I described in choosing an LLM router for agents, where every extra hop eats into a latency budget.

Azure shops should test now, Jev users can wait

My read: price is a wash, so the choice comes down to network path, calibration and where your data is allowed to go.

• Already on Azure Foundry: test it this week. Same region deployment is where the 85 ms figure came from, Entra ID replaces another vendor key, and DataZoneStandard keeps inference processing inside one data zone, which some regulated teams need regardless of speed.
• Running Jev in production: no reason to move yet. You'd trade 1.5 points of calibration for speed you may not see from your region, and if your thresholds were tuned on Jev's probabilities, they won't carry over unchanged.
• Classifying with GPT-6 Sol or another LLM today: you have the most to gain. Either decision model brings a classification call down to about two cents per thousand at a 500 token prompt, and the per token math on agent loops already showed how fast those calls add up.
• Uneasy about the Qwen base: Microsoft says a rebase is coming but gives no date. If your procurement rules exclude it, wait for the next version.

Microsoft's guide also lists the caveats I'd treat as rules: scores shift with how you word and order the options, there's no written rationale, and calibration is strongest on familiar task types. It recommends adding an abstention option such as "cannot tell" and randomizing option order. I'd do both from the first deployment. A decision model can still be confidently wrong, which is why the low confidence branch should end at a person, the same human in the loop step you'd put on any agent action that costs money.

A test plan you can finish in an afternoon

1. Pull 200 labeled examples from your own logs, not a public benchmark, and include your longest real states.
2. Deploy Decision-1 in the region closest to your app. Run the support ticket script from Microsoft's guide, which already prints accuracy and median latency.
3. Send the identical requests to Jev. Change only the endpoint, the auth header and the model value.
4. Compare three numbers: accuracy, p50 and p95 latency from your own machine, and how often the top probability falls below your threshold. If you don't have one yet, I'd start at 0.8 for acting without review and move it once you've seen where the wrong answers cluster.
5. Shuffle the option order and run again. Microsoft reports decisions flip on 1.3% of perturbed requests on average, and zero times when options are reversed or shuffled. Check that on your own data.

If you'd rather have the gates, thresholds and escalation paths designed and monitored for you, that's the work I do when I build AI agents for businesses.

Frequently asked questions

What is Microsoft Decision-1?

Microsoft Decision-1 is a decision scoring model released on October 9, 2026 in Microsoft Foundry. Instead of generating text, it returns a calibrated probability for each option in a fixed set, for yes or no gates, multiple choice classification and rating scales. Microsoft built it by post training Qwen3.5-9B and says it will later rebase the model on Microsoft AI and OpenAI models.

How much does Microsoft Decision-1 cost?

Input tokens cost $0.042 per million and output tokens are free, per Microsoft's launch post. That's the same per million rate TypeSafe lists for Jev 1.13. A decision with a 500 token prompt costs about $0.000021, so a million such decisions comes to roughly $21. You pay through your Azure subscription once you deploy the model in a Foundry project.

Is Microsoft Decision-1 faster than Jev?

On Microsoft's own chart, yes: an 85 ms median against 240 ms for Jev. But Microsoft measured Decision-1 through Foundry in the same region, while the other models used JevBench timings. JevBench's own Foundry run on October 10 recorded a 459 ms median for Decision-1. Measure from the region your application runs in before you rely on either figure.

Can I move my Jev code to Microsoft Decision-1?

Mostly, yes. Both use a systemone endpoint with a state and named questions of type noul, choice or score. You change the base URL to your Foundry resource, switch to an Entra ID token or api-key header, and set model to your deployment name. Microsoft's guide states no context limit, so test your longest inputs first, and retest your probability thresholds, because the two models are calibrated differently.