Stop running everything on the biggest model

The most common mistake we see teams make with AI coding tools has nothing to do with prompts. It is running everything on the biggest model available, all day, for every task. The work gets expensive, the queue gets slow, and the results barely improve, because most of a working day's tasks were never hard enough to need the flagship in the first place.

Claude comes in tiers. As of this writing, the top of the line does the deepest reasoning and costs the most, a middle tier does the great bulk of real coding work remarkably well, and a fast tier handles quick mechanical jobs. The craft is matching the tier to the task, and it is worth learning because the difference in cost between doing this well and doing it badly is roughly a factor of five, on identical output quality.

Think seniority, not intelligence

The useful mental model is a studio's org chart. You have a principal whose judgment is expensive and scarce, a manager who keeps work moving, and staff who produce most of the actual output. Nobody staffs a project with five principals, and nobody asks the principal to rename variables. Our own harness writes the same idea down for the agents themselves:

- **Planning tier** — deep thought and planning only. New apps,
  cross-cutting refactors, data models, design direction.
  Produces plans and specs, not bulk code.
- **Managing tier** — owns the task list, spawns and sequences
  subagents, reviews output, runs the PR lifecycle.
- **Building tier** — actually builds stuff. Page builds,
  component work, migrations, tests, fix iterations.

The counterintuitive part is that the middle tier is not a compromise. On scoped, well-briefed implementation work, current mid-tier models are excellent, and the quality gap against the flagship shows up mainly on open-ended judgment calls: architecture, tricky debugging, design taste, anything where the hard part is deciding rather than doing. So the economics reward a split: expensive judgment at the top of the task, affordable execution through the middle of it.

The plan-then-build pattern

The simplest version of this needs no infrastructure at all. Claude Code ships a mode called opusplan: the big model runs while you are planning the task, then execution drops down to the mid tier once the plan is approved. You get flagship thinking about what to build and economical hands actually building it, inside one session, automatically.

Even without that mode, you can run the pattern by hand, and it is worth doing on anything bigger than a bug fix:

• 01Ask the strongest model to produce a written plan: files to touch, approach, risks, what done looks like.
• 02Review the plan yourself. This is where your judgment is worth the most minutes.
• 03Hand the approved plan to a cheaper model to execute. A good plan makes execution mechanical, which is exactly what mid tiers are best at.
• 04Bring the strong model back only if execution hits something the plan did not anticipate.

The written plan is doing quiet double duty here. It is the quality control on the expensive model's thinking, and it is the brief that makes the cheap model reliable. Skipping the written step and letting one model improvise from a vague request is where both the cost and the quality problems come from.

Where each tier earns its keep

After a year of running agent fleets daily, here is roughly where our work lands. Top tier: system design, choosing between architectures, design direction, the hardest debugging, and reviewing other agents' output before it ships. Mid tier: building pages and components, writing tests, migrations, refactors with a clear spec, content edits, and fix iterations against a review. Fast tier: renames, formatting sweeps, log digging, one-file chores, and anything you would describe as “just go do this.”

Two habits keep the split honest. First, downgrade by default: try the cheaper tier, and promote the task only when the output tells you it needs more horsepower. You will be surprised how rarely it does. Second, watch for the opposite failure, where a cheap model burns an afternoon flailing at a problem the big model would have dispatched in one pass. Flailing is a cost too. The tell is repeated failed attempts at the same step; that is the moment to promote.

One warning about the top tier

When teams do splurge on the flagship, they tend to use it as a very fancy typist, asking it to write ordinary code faster. That is the one job where it is genuinely wasted. Its edge is judgment. Point it at decisions, reviews, plans, and the gnarliest problems, and let it delegate everything else. Our harness goes as far as calling flagship-written feature code a role violation, which sounds strict until you have watched the economics for a few months. The expensive mind is for deciding. The affordable hands are for typing.

The membership playbook version of this includes our actual delegation briefs and the checklists we hand each tier. And if you want this set up inside your own team, tooling, harness, and all, that is exactly the kind of engagement our consulting side takes on.