ScaleDown's Small Models for Routine In-App Jobs: Classify, Extract, Summarize

On 13 October 2026, ScaleDown took the covers off three small task-specific models it is selling as a single idea: Classify, Extract and Summarize, each built for the repetitive work that surrounds a production LLM call rather than for conversation. All three take a 1M-token input, all three accept text or images, and all three are reachable through ScaleDown's own API — which is where the pricing question gets interesting, because the three of them have completely different cost shapes. The fourth model in the family, ScaleDown Compress, is listed in the vendor's documentation as a context-trimming tool rather than one of the new three. What follows is what the vendor documents, kept separate from what nobody has yet reproduced.

What actually shipped on 13 October

ScaleDown has been operating a Decisions endpoint for some time — a structured-scoring interface that takes a state object plus a map of typed questions and returns calibrated probabilities. The 13 October announcement is the point at which the company started selling the underlying models as products in their own right rather than as one endpoint, and at which it began describing them as general-purpose components for in-app work.

The three models and their contracts, as the vendor documents them:

• ScaleDown Classify — assigns text to a label set the caller supplies. Each label carries a name and a rubric, which the documentation calls "a yes/no question the model uses to score the label," and which the docs describe as the most important part of the request. Single-label mode returns a softmax distribution summing to 1.0 plus a top label; multi-label mode scores each label independently against a caller-set threshold.

• ScaleDown Extract — pulls structured fields out of unstructured text. In the family's documentation this is the model that turns a document into a record your code can index.

• ScaleDown Summarize — short abstractive summaries of long input, which is the job the 1M-token window is most obviously aimed at.

The shared contract across all three is the part worth writing down. One million tokens of input per request is roughly an order of magnitude beyond what mainstream mid-size APIs take, and it is the number that makes Summarize and Extract plausible for whole-document work without a chunking layer. The text-or-image input matters for Extract specifically: a scanned invoice or a screenshot of a form goes in, fields come out, and no OCR step sits between them. All three are served from ScaleDown's own API, whose docs give the base URL as span>api.scaledown.xyz/span> and are explicit that span>api.scaledown.ai/span> is not an API host.

The one number that is not like the others

Pricing is where these three stop being interchangeable. Classify is listed at $0.05 per million input tokens and $0 per million output tokens, and the model's listing on third-party catalogues shows that same rate with a promotional discount applied at times; the discount is not a ScaleDown commitment and should not be planned around. The zero output price is not a marketing trick — a rubric-scored classifier emits labels and probabilities, not generated text, so there is nothing to bill for. Extract and Summarize do generate output, so their cost shapes are not comparable to Classify's and should be priced from the vendor directly rather than inferred from the classifier's rate.

Classify's billing detail is harder to reason about than the headline rate. In single-label mode every label and its rubric goes into one model call, so each label you add increases billed input tokens; asking for a one-sentence explanation of the choice re-sends them at 2x, and the documentation says plainly that the explanation is generated after the top label is fixed, so it justifies the answer rather than second-guessing it. In multi-label mode each label is a separate model call, and each chunk is scored separately. A sixty-label taxonomy with reasoning on is therefore not a $0.05-per-million-token operation in the sense a reader assumes; it is that rate multiplied by the label set, and then doubled if reasoning is on. The documented ceilings — 20 labels per request, 16 in multi-label mode, 50 chunks per batch — are the practical constraints to design against.

There is one more documented behaviour that matters more than any of these caps. The classifier "always returns a winner," even when no label fits. Confidence filtering is left entirely to the caller. On a 10-label request a top score of 0.4 can still be the correct answer, because the scores are relative within the label set rather than absolute. Every production use of this model needs a threshold policy of its own, and a catch-all label — the documentation suggests naming one span>other/span> — is not optional in practice.

Why a 1M-token window on a classifier is the interesting part

Classifier models conventionally take short inputs. The reason is mechanical: a rubric-scored classifier has to weigh the whole input against each label's yes/no question, and the cost of scoring a hundred-thousand-token document against twenty rubrics is twenty full passes over that document. ScaleDown's answer is the 1M window plus the batching layer — up to 50 chunks scored against one shared profile in a single request — and the vendor's claim is that per-chunk calibration is the same whether you send one chunk or fifty, with the only difference being that the shared profile is billed once per request.

That claim is the one to test before you build on it. It is also the claim that makes the model interesting: the whole reason to classify inside the application rather than at the edge is that the decision can see the full context — the entire support thread, the whole contract, the full retrieved document — rather than a truncated window. If the 1M window holds up at your input sizes, the architecture question ("do I need a chunking and voting scheme?") largely disappears. If it does not, you have a very cheap short-input classifier and a second problem to solve.

The claims that need a second opinion

ScaleDown's marketing argues that task-specific small language models beat frontier models on cost, speed and accuracy for high-volume repetitive work, and cites figures including a roughly half-billion-parameter model reaching 91.7% on a simple classification task against 88.6% for a 72-billion-parameter model. Those are the vendor's own numbers and they have not been independently reproduced: ScaleDown Classify currently sits unscored on the public leaderboards, with no third-party benchmark rows published. Treat the accuracy argument as a hypothesis with a plausible mechanism — the sample-efficiency gap between a purpose-trained small model and a general-purpose large one on a narrow taxonomy is real and well documented — not as an established result.

The 1M-token input figure is likewise vendor-stated. Third-party catalogue listings for the model show the context length as not applicable rather than echoing the million-token number, which is a catalogue limitation rather than a contradiction, but it does mean the window has not been corroborated outside ScaleDown's documentation.

Where this fits if you are already running a pipeline

The pattern these three models are aimed at is a loop, not a single call: retrieve a document, classify it, extract fields, summarize it, and then hand the summary to a generative model that writes the reply. Step four is the expensive one on a per-token basis, and it is the step OrcaRouter covers — more than 200 models behind one OpenAI-compatible key at provider list price passed through with 0% markup, with automatic failover when a serving path degrades. We do not host ScaleDown Classify, Extract or Summarize; they are not in our catalogue and are not a chat-completions target, and the routing layer here is the generation half of the pattern rather than the scoring half.

That division is worth stating plainly because the cost comparison people will reach for is misleading. A rubric-scored classifier at a few cents per million input tokens and a generative model at a few dollars per million are not competitors; they are different line items, and the reason to put a small model on the classification step is that it lets you afford a better model on the step that actually writes something.

What would change this assessment

Three things, in order of how much they would move the picture. An independent evaluation of the rubric-scored classification task on a public benchmark would turn the accuracy argument from a vendor claim into a datum. A published latency figure — the vendor documents cost drivers but no serving latency — would settle whether the 1M window is usable at throughput or only at batch. And a third-party reproduction of the per-chunk calibration claim would decide whether a fifty-chunk batch is a cost optimisation or a different model. Until at least one of those lands, the honest summary is that ScaleDown has shipped three models with unusually clear contracts and unusually large input limits, at prices that make a threshold-based classification stage cheap enough to consider, and that the numbers supporting them are the vendor's own.

The short version

If you have a high-volume classification or extraction stage with a stable taxonomy and text or image input, ScaleDown's three models are worth a benchmark on your own data this week, because the contract is simple and the input limit is generous. Budget for the label-multiplication and the 2x reasoning surcharge before you commit to a taxonomy, and expect to write your own confidence threshold. If your task is open-ended generation, none of this is aimed at you.

Model choices are also a question of what has gone wrong before: 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.