Three dials, and you don't get all three
Every model choice trades capability, latency, and cost. The frontier model wins one.
The gap isn't subtle. Across a typical provider lineup, the frontier model runs on the order of 10-20x the price per token of the small one, and takes several times longer to first token. So if your task is "classify this ticket into one of six routes," you're paying frontier prices for something a small model does correctly ~99% of the time — and making the user wait for it.
Rough structure to reason with
Small models — classification, extraction, routing, short rewrites, anything with a schema and a narrow answer space. This is a much larger share of a real workload than people expect.
Mid models — the default for most user-facing generation. Summaries, drafts, Q&A over retrieved context.
Frontier models — multi-step reasoning, ambiguous judgment, hard code, agents that must plan. Use deliberately, not by habit.
The order of operations matters
Start at the smallest plausible model. Measure on your eval set. Move up only when the numbers say so.
Almost everyone does the reverse: start at frontier because it obviously works, ship, and never revisit. That's how you end up with a bill 15x what the task needs and a p95 latency nobody can explain.
Note the dependency: this decision is empirical, which means it's downstream of having an eval set. Without one, "can we use the cheaper model?" is unanswerable and the safe-looking answer is always no. That's the real cost of skipping evals — not bad quality, but permanent uncertainty.