Microsoft Just Shipped Jev's API: Microsoft-Decision-1 vs Jev, Tested From C#

I've spent the last few weeks writing about Jev, the model that answers in types, how to call it from C#, what replaces it, where it sits next to System 2 models, and why it's a multiple-choice exam instead of an essay. On 9 October Microsoft shipped Microsoft-Decision-1 in Foundry, and it changes the story in a way I didn't expect.

It's not just another decision model. It serves Jev's API.

Same request, same answer, different URL

Decision-1 was built by Microsoft's Office of the CTO on Qwen3.5-9B (launch coverage). It costs exactly what Jev costs: $0.042 per million input tokens, output free. And you call it with POST .../providers/microsoft/v1/systemone and a body of {model, state, questions}.

That's TypeSafe's System One contract. I checked the answers against Jev's public OpenAPI spec field by field: choice with probabilities and confidence, score with its legend, noul, usage. All identical. Only three things differ:

	Jev (TypeSafe)	Microsoft-Decision-1	open-jev (local)
URL	https://api.typesafe.ai/v1/systemone	<foundry-endpoint>/providers/microsoft/v1/systemone	http://127.0.0.1:8000/v1/systemone
Auth	Authorization: Bearer <key>	api-key: <key> or Entra Bearer	none
model	jev-latest	your deployment name	ignored

Remember when every LLM vendor started accepting the OpenAI chat format, and your client code stopped caring who was on the other end? This is that moment for System One. A request shape invented by a small startup is now served by Microsoft, and by open-jev on your own Mac. The contract is becoming the standard.

One C# client, three servers

So the client collapses to one class with three factories. It's in the companion repo, egarim/decision-1-vs-jev:

var client = SystemOneClient.Foundry(http, endpoint, deployment: "decision-1", apiKey);
// or SystemOneClient.Jev(http, typesafeKey)
// or SystemOneClient.OpenJev(http)

var r = await client.AskAsync(
    new { message = "Checkout is down again. This is my third request.", customer_contact_count = 3 },
    new Dictionary<string, Question>
    {
        ["team"] = Ask.Choice("Which team should handle this request?", new Dictionary<string, string>
        {
            ["billing"] = "Charges, invoices, and refunds",
            ["engineering"] = "Bugs, errors, and outages",
            ["support"] = "How-to and account questions",
        }),
        ["severity"] = Ask.Score("How severe is this issue?", "Cosmetic", "Minor", "Major", "Critical"),
        ["repeat_contact"] = Ask.Noul("Has the customer contacted support before?"),
    });

r.Answers["team"].Choice;            // "engineering"
r.Answers["team"].TopProbability;    // 0.991
r.Answers["severity"].Score;         // 2.18  (probability-weighted level index, 0..3)
r.Answers["repeat_contact"].Noul;    // 0.995

Three typed questions in one call: which one (choice), how much (score), is it true (noul). Swap the factory and nothing else changes.

What Microsoft claims, and what it leaves out

Microsoft says Decision-1 has the "highest accuracy" across 36 benchmarks (about 150,000 questions), which aren't named. Jev isn't in the comparison table, even though an editor's note says the post was updated to add Jev. On robustness, Microsoft reports 1.3% of answers changed under perturbations, and zero flips when the options were paraphrased or shuffled.

I can't check 36 unnamed benchmarks. I can check my own workload.

What I tested

48 support tickets that I labeled myself, in English, Spanish and Russian. Each ticket gets three questions:

• team: a choice of 4,
• severity: a score from 0 to 3,
• churn: a noul, "is the customer threatening to leave?"

Plus two extra runs: a 1-question call, to see what extra questions cost, and the same call with the option list reversed, to see whether the answer flips. Run on 12 October from my Mac Studio (M1 Max) in Arizona, against Foundry in East US, GlobalStandard. The local side is open-jev running Qwen3-4B-Instruct, 4-bit, on MLX.

	Decision-1	open-jev
team accuracy	100%	85.4%
team Brier (lower is better)	0.001	0.227
severity MAE (0..3)	0.15	0.78
churn accuracy	100%	97.9%
flips with options reversed	0 / 48	7 / 48
latency, 1 → 3 questions, p50	217 → 256 ms	238 → 562 ms
network floor	74 ms	0 ms

Every answer behind those numbers is in the repo's results/ folder.

Four things the numbers say

1. The confidence drops where a human would hesitate. The 100% is the least interesting part. Decision-1's two least confident answers (p = 0.87 and 0.88) were exactly the two tickets I wrote to be ambiguous: "switch from monthly to annual billing" (billing or sales?) and "SSO login loop" (account or technical?). That's the property you actually build on. Set an abstain threshold and the uncertain tickets go to a human, exactly the ones a human should see.

2. Extra questions are nearly free on Decision-1. One question took 217 ms; three questions in the same request took 256 ms. Two extra answers for 39 ms. open-jev pays one prefill per question, so it goes from 238 to 562 ms, growing linearly. That matches what I measured earlier when I tried open-jev as the decision brain for my telekinesis agent. The practical rule: batch your questions on Decision-1, minimize them on open-jev.

3. A confident wrong answer beats your threshold. open-jev routes 85% of tickets right, which is usable for free. But it was wrong three times at p = 1.00: an invoice-address ticket sent to account, a data-leak report sent to account, an AI add-on purchase sent to technical. A wrong answer at 1.00 sails through any abstain threshold. Calibration isn't a nice-to-have, it's what makes the threshold work at all.

4. It costs nothing. About 193 input tokens per 3-question call is roughly $0.000008, or about 120,000 decisions per dollar. The whole benchmark cost about a tenth of a cent.

Honest caveats

• Hosted Jev is not in this table. I don't have an early-access key. The code path is the same one; once I have a key, it's one command: TYPESAFE_API_KEY=... dotnet run --project src/Decision1VsJev -- bench jev.
• 48 tickets is too small and too clean to separate two good models. Decision-1's 100% means "handles routine support triage". It does not mean "beats Jev".
• It's not the same weight class. open-jev here runs a 4B model; Decision-1 is 9B. open-jev is in the table to answer "what do I get for free, on my own Mac, with the same API?"
• The hosted latencies include the network. Subtract the 74 ms floor before comparing them with the local engine.

Five Foundry traps (so you don't hit them)

1. "microsoft" is a reserved word in deployment names. microsoft-decision-1 fails with ContainsReservedWord. Name it decision-1.
2. No custom subdomain, no Entra. An account created without a custom subdomain only has the regional endpoint (https://eastus.api.cognitive.microsoft.com), and that takes api-key, not an Entra token. The docs' Entra sample assumes a <name>.services.ai.azure.com endpoint.
3. Content-Length is mandatory. .NET's JsonContent streams the body chunked, and the gateway answers 400 no_content_length_header. Serialize to a StringContent.
4. Capacity changes never reach the gateway. I deployed at capacity 1 and raised it to 60. The control plane said 60; every response kept saying x-ratelimit-limit-requests: 1. Still true ten minutes later, and still true after deleting and recreating the deployment under the same name. A new deployment name got 60 immediately. Deploy at your final capacity.
5. 429s carry retry-after-ms, not the standard Retry-After. A client that only reads Retry-After backs off on its own schedule and can give up before the window resets.

A correction to my earlier Jev client

Reading Jev's OpenAPI spec line by line for this comparison showed me that my earlier article and the JevDecider in egarim/systemone-deciders used the wrong wire shape:

• Request: I sent {type: "choice", question, options}. The real shape is {type: "choice", instructions, criteria: {option: description}}. criteria is required, so real Jev would answer my old request with a 422.
• Response: I parsed answers.decision.options[] as {option, probability}. The real shape is answers.<key>.probabilities as {option: p}.

My hermetic tests passed because they checked my client against canned JSON that I wrote, in my own wrong shape. That's the limit of stub tests: they prove you agree with yourself. The new repo's fixture is a real Decision-1 response, which is the right way round. The idea in the old article still holds; its wire format doesn't. The client in decision-1-vs-jev has the correct shape.

So what changed?

A month ago "System One" meant one startup's early-access API. Now the same request gets an answer from Microsoft, from TypeSafe, and from a free open-source server on my desk, at the same price or for free. That's how a format becomes a standard: not by announcement, but by the second big vendor deciding it's easier to speak it than to invent their own.

For a .NET developer that's the good news. Write against the contract, not the vendor. Keep your questions batched and your abstain threshold honest, and test on your tickets, not 36 benchmarks you can't see.

The repo has the client, the 48 tickets, every answer and the bench command: github.com/egarim/decision-1-vs-jev. Run dotnet test (6 hermetic tests, no key, no network), then point it at whichever of the three servers you have.