The problem it solves
More capability is not always better, because it is not free. The most powerful model costs more per use and is slower than a smaller one. If you send every task to the biggest model, you overpay and add latency for work a lighter model would have handled perfectly. If you send everything to the smallest, you save money but may get weaker results on the tasks that actually need depth.
Offering a family of models solves this. It lets you match the tool to the job: pay for power where the task demands it, and pay less for speed where it does not. The skill is knowing which is which, and that skill outlasts any particular set of models.
How it works
Model families are usually organized along a single spectrum, from fast-and-affordable to most-capable, and it helps to think in three broad tiers.
A fast, low-cost tier. The smallest, quickest, cheapest models. They are not “weak”, modern small models are highly capable, but they are best pointed at high-volume, well-defined tasks: classification, extraction, simple responses, routing, and any workload where speed and cost matter most and the task is clear.
A balanced tier. The everyday workhorse, offering a strong mix of capability and cost. For most applications, writing, analysis, coding, retrieval-based systems, this is the sensible default and the right place to start.
A most-capable tier. The largest, most powerful models, for the hardest problems: complex reasoning, deep analysis, difficult agentic work. They cost the most and are worth it precisely when a task genuinely needs that extra capability.
The practical method follows from this. Start in the middle, with the balanced default. If the task turns out to be simple and high-volume, step down for speed and savings. If it proves genuinely hard and the quality is not enough, step up. Let the requirement decide, and measure rather than assume. Since cost is driven by tokens, and the largest models cost many times more than the smallest, this matching has a direct effect on what an application costs to run at scale.
A concrete example
Imagine a company with two AI features: sorting incoming support emails by topic, and writing detailed answers to complex technical questions.
Sending both to the most powerful model would work, and would waste a great deal of money on the sorting task, which is simple and high-volume. The better design matches each to its tier: a fast, cheap model classifies the emails at scale, and a more capable model handles the hard technical answers where quality matters. Same product, far better economics, achieved purely by choosing the right model for each job.
How it connects
Choosing a model is really about the properties of an LLM applied to a specific task, and its cost is measured in tokens, which is why model choice and token cost are inseparable. The decision is a direct trade-off between capability and cost and latency.
This is everyday judgment for the building roles. An AI/LLM Developer routes each task to the right tier in code, and an AI Solutions Architect designs systems that use cheaper models where they suffice and reserve the expensive ones for where they are truly needed.