ScaleDown: Extract

ScaleDown: Extract is a text model from ScaleDown, built specifically for description-driven entity extraction. Rather than forcing you to pick from a fixed set of entity types, it lets you describe the fields you want in plain English. That makes it a different kind of tool from a general chat model: its job is to pull structured information out of whatever you give it, guided by your own description of the target fields.

The model accepts text, images, and files as input, and returns text. Its context window is 1,000,000 tokens, and the maximum output is 900,000 tokens. That combination of a very large input window and a large output ceiling means you can hand it long documents or mixed media and still get a substantial extracted result back in a single call. The supported parameter list is deliberately short: only max_tokens is exposed, which fits a model whose behaviour is steered mainly by the entity description you supply rather than by a wide set of sampling knobs.

Practical use cases follow directly from those capabilities. If you have contracts, invoices, reports, or scanned paperwork and you need specific fields pulled out, you describe those fields and let the model find them. Because images and files are accepted alongside text, the same call can cover a PDF, a screenshot, or a plain text dump without a separate pipeline for each format. The million-token context is useful when the relevant details are scattered across a long document and you would rather not chunk it yourself. The large output ceiling helps when the extraction result is itself long, such as a list of many entities or a table-like structure.

You call it through api14's OpenAI-compatible API using the model id "scaledown/extract". The only supported request parameter is max_tokens, so keep your request shape simple and put the field descriptions where the provider expects them, under provider.options.scaledown.entities. Because the interface is OpenAI-compatible, existing clients and SDKs generally work with a change of model id and endpoint, and you can set max_tokens to bound the response length for your workload.

The narrow parameter surface is worth noting when you are choosing a model. If your task needs creative generation, multi-turn conversation, or fine control over sampling behaviour, a general purpose text model will fit better. Extract is aimed at one job, and it does that job by reading your description of the fields rather than by exposing many tuning options. For extraction tasks where the fields are easier to describe in words than to express as a schema, it is a reasonable default to try first.