ScaleDown Classify vs Microsoft-Decision-1: One Publishes Numbers, the Other Publishes Method

ScaleDown Classify and Microsoft-Decision-1 are the two closed, hosted options in this comparison. Neither ships weights, neither is something you download, and both are built on the same premise: that a decision — which category, which option, which of these — should be read out of a model's probabilities rather than written out as text by a generation loop. Microsoft-Decision-1 has been generally available on Microsoft Foundry since 8 October 2026 as a 9-billion-parameter dense decoder post-trained by Microsoft, with 25 supported languages and a 32,768-token context. ScaleDown Classify is a hosted rubric engine at $0.05 per million input tokens and $0 per million output tokens, with a 1M-token input limit and a twenty-label ceiling. The thing that separates them is not capability. It is what each company is willing to publish about its own model, and they have chosen opposite halves.

The disclosure inversion

Microsoft-Decision-1's Foundry documentation describes its evaluation in unusual detail. Public and community decision benchmarks plus held-out internal sets. Metrics including accuracy and calibration error. Option order varied. Paired statistical tests. An identical harness for every model it is compared against. And then it reports that the model "performs on par with leading decision models and ahead of other open decision models evaluated with the same methodology" — and prints no numbers at all. No accuracy figure, no calibration error, no per-benchmark table.

What Microsoft does publish is a limitations list, and it is a good one. Scores shift with phrasing and option ordering. A poorly framed question still returns a score. Calibration is strongest on familiar task types. No explanations are produced. The model's named strengths are reasoning, rule application and robustness to prompt formatting; its named weaknesses are specialized domain knowledge and non-English performance.

ScaleDown Classify runs the mirror image of that policy. Its documentation goes into operational detail about how to write a request — the rubric is described as the most important part of a classify request, phrased as a direct yes/no question, avoiding negations, kept non-overlapping so probability mass is not split unpredictably — and the vendor's marketing carries accuracy and cost claims, including a roughly half-billion-parameter model reaching 91.7% on a simple classification task against 88.6% for a 72-billion-parameter model. None of those are attached to a described methodology, and ScaleDown Classify carries no published expected calibration error on any public harness.

So the choice is between a vendor who tells you how it measured and not what it found, and a vendor who tells you what it found and not how it measured. Neither is a full disclosure, and neither should be treated as one.

Languages: one publishes a count, the other publishes nothing

Microsoft-Decision-1 lists 25 supported languages and states plainly that coverage, quality and calibration "may vary by language," naming non-English and especially lower-resource languages as areas of underperformance. That is a usable disclosure: it tells you the model is multilingual, it tells you roughly how multilingual, and it tells you where not to trust it.

ScaleDown's Classify documentation does not publish a language list. Nothing in the API reference states which languages the rubric scoring handles, or whether rubric phrasing in a non-English language behaves the same way, and the rubric guidance — phrase it as a direct yes/no question, avoid negations — is written in a way that implicitly assumes an English-speaking caller writing English rubrics. For a classifier that in practice will be pointed at international support tickets, that is the gap to close before you commit, and it is a gap that only your own evaluation can close.

If you need a documented language footprint, this comparison ends here and Microsoft wins by default. If you are English-only, the count is not a factor and the rest of the decision is about input length and thresholds.

Context: 32,768 tokens against a million

Microsoft documents a single invocation over up to 32,768 tokens. ScaleDown documents a 1M-token input limit, and states that per-chunk calibration is identical whether a chunk is sent alone or as part of a fifty-chunk batch, with the shared profile billed once per request. On the raw number, that is a thirty-fold difference and it is the largest single gap between the two products.

What it buys is not throughput — it is whether you need a chunking layer. A support thread, a ticket with its history, a short retrieved passage: all of that fits inside 32k with room for a question schema, and the two models are roughly equivalent at that size. A full contract, a multi-page policy document, a long retrieved context or a scanned form: none of that fits in 32k, and Classify's document path — base64 JPEG, PNG, TIFF or PDF, single or multi-page, with the extracted text returned in an ocr_text field — means the document can go in as bytes rather than as preprocessed text.

Both figures are the vendors' own. ScaleDown's million-token claim has not been independently corroborated, and third-party catalogue listings for the model show context length as not applicable rather than echoing the number, which is a catalogue limitation rather than a contradiction.

Explanations: one refuses, one charges double

Microsoft-Decision-1 produces no explanations, and the model page lists that as a limitation rather than as a design choice. ScaleDown Classify will return a one-sentence explanation of its top label, and the documentation is careful about what that sentence is: it is generated after the top label is fixed, so it explains the decision rather than second-guessing it, it is free-form, and it re-sends the labels and rubrics at 2x billed input tokens. It is available only on single-label requests with a single text or document input — multi-label and batch requests never return it.

For a human review queue, that sentence is frequently the difference between a reviewer accepting a classification and a reviewer re-doing it, which makes the 2x surcharge easy to justify on the fraction of traffic that reaches a human. For an automated pipeline, it is dead weight on the bill, and it should be off.

Both are closed, and that changes what you can test

• Weights — neither ships them; ScaleDown offers enterprise self-hosting and licensing on request, Microsoft's page documents no fine-tuning path at all

• Option ceiling — ScaleDown 20 labels per request, 16 in multi-label mode, scored independently; Microsoft-Decision-1's option-set ceiling is not stated on the model page

• Batch inference — ScaleDown documents up to 50 chunks per request against a shared label profile; Microsoft's page lists batch inference as disabled

• Billing disclosure — Classify's rate is printed, at $0.05 per million input tokens and $0 per million output tokens; the Foundry per-token rate is not printed on the model page

• Price shape — Classify multiplies with your label count in multi-label mode and doubles with reasoning enabled; the Foundry rate is per token with no published label multiplier

• Empty answer — Classify returns a winner even when nothing fits, so you write the threshold; Microsoft's stated behaviour is that a poorly framed question still returns a score

The consequence of both being closed is the same in both cases: you cannot inspect the artifact, so your only verification is behavioural. That makes a held-out set of your own labelled data non-optional, and it makes the cost of switching providers a re-run of that evaluation rather than a code change.

Where OrcaRouter sits in a pipeline built on either

Neither of these models is in our catalogue, and nothing here is an availability claim — both are structured scoring endpoints rather than chat-completions targets, and a routing layer is not what either one needs. What we carry is the layer above them: the more than 200 generative models behind one OpenAI-compatible key that produce the draft the classifier is judging, at provider list price passed through with 0% markup, with a routing DSL for composing several models into one call and automatic failover when a serving path degrades. If a decision model gates what your generation layer is allowed to ship, then the generation layer is where your uptime risk lives, and that is the half one key can consolidate.

Which one to pick

Choose Microsoft-Decision-1 if you need a documented language footprint, if you are already inside Azure, or if the compliance posture of a large vendor matters more to your procurement than a published accuracy figure. Accept that you will be evaluating it entirely on your own data, because Microsoft has chosen not to give you anything else.

Choose ScaleDown Classify if your inputs run past 32k tokens, if you want the extraction step folded into the classification call, or if you want a per-label rubric you can rewrite without retraining anything. Accept that the accuracy argument is the vendor's own and unreproduced, that no calibration number is published, and that you will be writing your own confidence threshold and a catch-all label.

The measurement that would decide this — both models on identical inputs, the same option ordering, the same threshold sweep, run by somebody with no stake — has not been published by either vendor. Until one of them runs it, the honest reading is that Microsoft is the safer default and ScaleDown is the more capable instrument.

Comparisons like this one are also where the failure modes show up: the documented AI incidents and agent failures behind models in this class are collected in the OrcaRouter AI Incident Archive , where each entry carries its own sources, severity, confidence grade and disputed flag.