Using the best available model for everything is the natural reflex and the worst possible calculation. On a simple task, a state-of-the-art model does no better than a model twenty times smaller: it does the same thing, more slowly and far more expensively. The skill that matters is not choosing the best model, it's choosing the smallest one that suffices.
We reported this morning the release of a range spanning 0.9 to 375 billion parameters. Here's how to make sense of it.
What size actually changes
Let's recall what a parameter is: an internal setting learned during training. The more there are, the more regularities the model can store.
In practice, size mainly affects three things: the breadth of knowledge, the ability to sustain long reasoning without losing the thread, and robustness in the face of unusual situations.
It affects far less than one might think the quality of a well-scoped reformulation, classification or extraction. These are tasks where a small model hits the ceiling very quickly.
The practical guide
Under 3 billion. Classification, intent detection, filtering, simple field extraction. Runs on a phone. Don't ask it to reason, and it won't disappoint you.
From 3 to 15 billion. Reformulation, short-text summarisation, everyday translation, answering from provided documents. Runs on a decent laptop. Covers a considerable share of real business needs.
From 20 to 40 billion. This is the most interesting segment today. Serious document processing, code of moderate complexity, structured analysis. Fits on a single graphics card, which allows in-house hosting and therefore total confidentiality.
Beyond 100 billion. Complex reasoning, non-trivial code, long-running agentic work, novel problems. Requires server infrastructure or an API.
Beware of a common confusion. A mixture-of-experts model advertises two figures: the total and the active parameters. A 320-billion model with 18 billion active costs as much in compute as an 18-billion model, but takes up the memory footprint of 320 billion. If you go through an API, only the first figure matters for the price. If you host it yourself, it's the second that decides whether the model fits on your hardware. We detailed this in our article on the two architectures.
The method that works
It comes down to three steps and takes an hour.
Start with the smallest. Not the best. Take the smallest size that seems plausible for your task.
Build twenty reference cases. Twenty representative examples, with the expected output. This is the only investment that matters, and it then serves all your decisions: model changes, provider changes, version changes.
Move up a notch only if necessary. Measure the success rate on your twenty cases. If the small model passes, stop. If it fails, move up and measure again. You'll often be surprised to stop lower than expected.
Routing, when one size isn't enough
For varied usage, the right answer isn't a size but an architecture: a small model handles everything by default, and escalation to a larger model triggers when a check fails or when the task is identified as difficult.
That's what makes coherent ranges valuable: escalation becomes a parameter change rather than a rewrite.
And don't forget the additional lever we described in our article on effort level. Often, a mid-range model at high effort beats a large model at low effort, for less money.
What to remember
The question is never "what's the best model" but "what's the smallest that passes my twenty cases".
This reframing changes everything, because it turns a matter of opinion into a measurement. And it almost always yields the same finding: most organisations pay for power they only use a fraction of, on tasks a far more modest model would handle just as well.