Key insight

There isn't one model — there's a family, from small, fast, and cheap to large, capable, and expensive, and every choice trades capability against cost and speed. The big mistake is defaulting to the biggest model; the discipline is to match the model to the task and only move up when a smaller one genuinely can't cope — because at scale the cost gap is enormous. You can even mix models within one app, and you should decide with your eval, not the brand name. The rule: right-size the model to the job.

People talk about “the AI model” as if there's one — but every provider offers a whole family, and picking the right member for each job is a real quality-and-cost decision. This guide starts from nothing and builds up how to make that match sensibly, so you pay for exactly the capability a job needs and no more.

At one end sit small models: fast, cheap, and perfectly capable of straightforward tasks. At the other end sit large models: more capable on hard, nuanced problems, but slower and considerably more expensive. And there are mid-range options between. The instinct is to always grab the biggest, smartest one — surely more capable is better? — but that instinct quietly wastes money and speed, and it's the main mistake this article exists to fix. Choosing a model isn't about finding “the best” one in the abstract; it's about matching the model to the specific job.

A family of models Models range from small and cheap to large and capable, with mid-range options between. small & fast mid-range big & powerful from tiny and cheap to huge and capable
Figure 1. Not a single “best” model but a spectrum — and the job decides where on it you should sit.

2 · Three dials: capability, cost, speed

Every model choice balances three things, and they pull against each other. Capability: how well it handles hard, subtle, multi-step problems — bigger models are generally smarter here. Cost: how much each use costs — bigger models cost more, often a lot more, per request. And speed: how fast the answer comes back — bigger models are usually slower. The uncomfortable truth is you can't max out all three; they trade off. Going bigger buys capability but spends cost and speed. Going smaller buys cheapness and speed but spends capability. So “which model?” is really “for this task, how much capability do I truly need, and how much speed and cost will I trade for it?” See it as three dials rather than a single “better/worse” scale, and the decision becomes about fit, not prestige.

3 · Match the model to the task

The core skill is matching model to task, and once stated it's obvious. Many jobs are simple — classifying a message, extracting a field, a quick rephrase, a routine reply. These don't need a giant model's deep reasoning; a small, cheap, fast model does them just as well, and using a big one is like hiring a world-class surgeon to apply a plaster. Other jobs are genuinely hard — intricate reasoning, subtle judgement, complex analysis — and there a bigger model's extra capability earns its cost. So ask honestly of each feature: how hard is this really? Be careful, because we over-estimate — assuming our task is sophisticated and needs the flagship when a smaller model handles it fine. The discipline is to assume a smaller model can do the job and only move up if it actually can't. Match capability to difficulty, and you stop overpaying for power you never use.

4 · The cost gap is enormous

The reason this matters so much is that the cost difference between models isn't small — a large model can cost many times more per use than a small one. On a single request that's invisible; you'd never notice a fraction of a cent. But real applications don't make one request — they make thousands, then millions. At that scale the gap explodes: routing every request to the flagship when most tasks only needed a small model can multiply your bill by ten or more, for quality you couldn't even measure a difference in. This is the hidden tax of the “always use the biggest” instinct, and it compounds with speed — the big model is also slower, so you're paying more and making users wait longer, often for identical results. The lesson isn't “always go cheap”; it's “don't casually default to expensive.” At scale, thoughtful model selection is one of the largest cost levers you have.

A small per-request gap explodes at scale A large model costs many times more per call, multiplied across millions of calls. small: a fraction big: many times more multiplied by millions of calls, it's real money
Figure 2. The economics of the wrong default: a tiny per-call difference becomes a giant bill at production volume.

5 · Mix models within one app

Here's a move that surprises people: you don't have to pick one model for your whole application — you can use different models for different tasks, and the best systems do. Most of what an app does is easy — simple classifications, quick lookups, routine responses — and a small slice is hard. So route the easy majority to a small, cheap, fast model, and send only the genuinely hard cases to the big, expensive one. You get the big model's capability precisely where it's needed and the small model's economy everywhere else. Some systems even do this dynamically: a cheap model handles a request and only escalates to a stronger one when it detects the task is tough or its own answer is shaky. Stop thinking “which single model?” and start thinking “which model for this step?” That shift alone can slash cost while keeping quality high.

6 · Test candidates on your eval

How do you actually decide which model a task needs? The same way you decide everything in this series: your evaluation. Take your test set and run it through the candidate models — a small one, a mid one, maybe the flagship — and compare not just quality scores but cost and speed alongside. Now the choice is evidence, not guesswork. Very often you'll discover the smaller model scores nearly as well as the big one on your specific task, at a fraction of the cost and twice the speed — an easy win you'd never have found by assuming bigger is better. Other times the big model genuinely pulls ahead where it matters, justifying its price. Either way, you chose on data. This also future-proofs you: models change constantly, and when a new one appears you just run it through the same eval to see if it's worth switching. Let the numbers pick the model, never the brand name or the hype.

The one sentence to remember

Don't default to the biggest model — right-size it to the task, mix models where it helps, and let your eval weigh quality against cost and speed.

7 · Capability isn't the only axis

A final caution: capability, cost, and speed are the main dials, but not the only considerations, and sometimes another factor decides for you. Privacy and hosting: some data can't leave your environment, which may push you to a model you can run privately even if a cloud model is a touch smarter. Context size: if you need the model to read very long documents at once, its window size matters as much as raw intelligence. Languages and specialisation: a model strong in the languages or domain you need may beat a “smarter” generalist. And reliability, availability, and terms of use: a slightly less capable model that's dependable, well-supported, and licensed for your use can be the wiser choice. So while “match capability to task difficulty” is the core rule, sanity-check these practical constraints — because occasionally the right model isn't the smartest or the cheapest, but the one that fits how and where you need to run it.

8 · A simple test you can run this week

Downshift one task

1. Pick a task you currently send to a big model.
2. Honestly rate its difficulty — is it really hard, or routine?
3. Run the same inputs through a smaller model and compare quality, cost, and speed.
4. If quality holds, you just found free savings — and confirmed it on data.

The lesson: right-size the model to the job, and prove it with your eval.

9 · Glossary — every term, spelled out

Model family
The range of models a provider offers, from small and cheap to large and capable.
Capability
How well a model handles hard, subtle, multi-step problems.
Cost and latency
How much each use costs and how long the answer takes — both rise with model size.
Right-sizing
Matching a model's capability to a task's real difficulty, moving up only when needed.
Model mixing / routing
Using a small model for easy tasks and a big one only for hard cases within one app.
Eval-driven selection
Choosing a model by measuring candidates on a test set, comparing quality, cost, and speed.
Key takeaways

There's a family of models, trading capability against cost and speed — not one “best.”
Match the model to the task; don't default to the biggest, because the cost gap is enormous at scale.
Mix models — small for the easy majority, big for the hard slice.
Decide on your eval — quality, cost, and speed together — and check privacy, context, and reliability.

References

  1. Anthropic, Choosing the right model — trading capability, cost, and speed. docs.anthropic.com
  2. OpenAI, Models overview — comparing model sizes and their trade-offs. platform.openai.com
  3. This guide’s Evaluations, Explained From Zero — how to pick a model on the numbers.
  4. This guide’s Tokens, Cost & Latency, Explained From Zero — the units the trade-offs are measured in.