Should You Always Reach for the Flagship Model?
"Always use the cheapest model that works" has costs that don't appear in a token bill. The case for flagship-by-default is stronger than usually admitted — and there's a cheaper optimization people skip first.
The reflex is to use the most capable model available and stop thinking about it. That's defensible more often than cost-optimization advocates admit, and wrong in a specific set of situations that are easy to identify.
Worth arguing both sides properly, because the usual advice — always route to the cheapest model that works — has real costs that don't show up in a token bill.
The case for flagship by default
Model choice is a distraction from the actual work. Agent quality is dominated by tool design, context assembly, and verification. A team spending its first month on model routing instead of tool descriptions has optimized the wrong thing. Using the best model and moving on is a reasonable way to remove a variable.
Debugging is easier with one variable removed. When something goes wrong, "is this the model?" is a question you don't want to be asking. A uniform strong model means failures are attributable to your harness.
Volume is often low enough not to matter. ⚠️ This is the honest one. An internal tool running a few hundred times a day has a model bill that rounds to nothing regardless of tier. Routing effort there costs more in engineering time than it saves, permanently.
Capability headroom absorbs prompt weakness. A stronger model is more forgiving of imperfect tool descriptions and messy context. That's not an argument for leaving those imperfect — it's an argument that flagship-by-default is a reasonable starting point while you improve them.
When it's actually wrong
High-frequency steps in a long loop. A classification running once per turn across a forty-turn run, thousands of times a day, is where tier choice becomes a real number. This is where routing pays and where it should start.
Latency-sensitive paths. Larger models are generally slower. If a step sits in an interactive path with a tight budget, the tier choice is a product decision, not a cost one.
Constrained tasks with a mechanical check. Extraction against a schema, classification into a closed set, format transformation. The output is verifiable, so a cheaper model's mistakes are caught rather than propagated — which changes the risk calculus entirely.
When it hides a design problem. ✅ The subtle one: if your agent only works on the flagship model, that's information. It often means the tool descriptions are ambiguous or the context is poorly assembled, and the strong model is compensating. Testing on a weaker model is a genuinely useful diagnostic — not necessarily to deploy it, but to find out where your harness is thin.
The order that avoids wasted effort
- Start on the strongest model. Get it working. Don't optimize what isn't working.
- Instrument cost per completed task and per step. You can't route sensibly without knowing where spend concentrates.
- Look at call frequency, not call cost. The step running once per turn matters more than the expensive one running once per task.
- Move the highest-frequency, most-constrained steps first, one at a time, measuring that step's assertions specifically.
- Leave the judgment steps alone — tool selection in a wide space, planning under ambiguity, final synthesis a person reads.
→ Most systems reach a good place after moving two or three steps. Exhaustive per-step optimization has sharply diminishing returns and adds permanent complexity.
💡 The cheaper optimization people skip
Before changing tiers, check whether the step needs the full context. An extraction step doesn't need the conversation history; a classification doesn't need the accumulated tool results.
Same model, smaller input, most of the saving — and no quality risk at all, because you haven't changed what's doing the work. This is frequently a larger win than routing and it's almost always available.
The takeaway
Flagship-by-default is a reasonable starting position: it removes a variable while you fix the things that actually determine quality. Move off it deliberately, starting with high-frequency constrained steps that have mechanical checks, and leave judgment steps alone. And before you route anything, trim what you're sending — that's the saving with no downside, and it's the one people skip because changing models feels more like optimization.