Putting every worker on the frontier model burns a week’s budget for zero gain on CRUD. A tiering playbook from running mixed-model agent waves daily.
The easiest mistake to make when you can fan work out to several agents at once is to put every single one of them on the best model you have access to. It feels like the safe choice, more capability can only help, surely, and it is also the fastest way to burn a week of usage on tasks that never needed it. Most of what a coding agent does day to day is not hard in the sense that matters for model selection. It is mechanical: renaming a variable across a codebase, writing a test that follows an existing pattern, updating a config file, fixing a lint sweep. None of that benefits from the top-tier model’s extra reasoning, because there is no reasoning gap to close.
What I run instead is a tiering playbook, applied per worker rather than per session. At the top sits the frontier model, reserved for work where being wrong is expensive or the problem is genuinely novel: a security-sensitive change, a bug that has already survived two or three attempts at a fix, a piece of architecture nobody has built in this codebase before. That tier is small by task count and large by importance, and it is the one place I do not economise.
Below that sits a mid-tier model for the bulk of real engineering, implementing a feature to an existing spec, debugging something with a clear reproduction, a refactor that touches many files but follows one rule consistently. This is where most of the actual work lives, and a well-specified mid-tier model handles it as reliably as the frontier one, for a fraction of the cost per task. The gap between the two tiers on this kind of work is smaller than the price difference suggests.
At the bottom sits a cheap, fast model for single-file mechanical edits: formatting, renames, one-shot lookups, answering a question whose answer is already present in the file you hand it. The failure mode of the cheap tier is not that it is slow or expensive, it is neither, it is that it will still answer confidently when the task actually requires derivation rather than retrieval, and a fluent wrong answer from a cheap model is more dangerous than a slow correct one, because it does not look uncertain. The discipline is knowing which bucket a task falls into before you assign it, not discovering the mismatch after a confidently wrong diff lands.
Running a wave uniformly on one model is usually a sign that no real choice was made, not that the choice was good. A wave with five workers on five different tiers, matched to five different kinds of task, is not an accident of preference, it is what happens when someone actually looked at each piece of work and asked what it needed rather than defaulting to whatever tier feels safest to reach for.
The economics compound faster than the headline price difference implies, because the frontier model is not just more expensive per token, it is also the scarcest resource in a subscription-based setup where usage windows are finite and shared across every task competing for them that day. Every CRUD task parked on the top tier is not just an overpayment, it is capacity that a genuinely hard task later that day will not have, because the account already spent it on something a cheaper model would have handled identically well.
The habit that fixed this for me was simple to state and easy to skip under time pressure: before launching a worker, say out loud, or in a launch note, which tier it is on and why, in one clause. Forcing that one sentence is enough friction to catch the lazy default, because it is much harder to write ‘frontier model, because it is a config change’ without noticing how thin the justification is.