There is a quiet math problem underneath every "AI agent fleet" story, and it usually gets skipped in the demos. When you run agents at real volume — not a weekend script, but pipelines that fire on a schedule across several brands — the model bill becomes a line item you can actually feel. If you route every step through the most capable model you have, the economics stop working before the systems do.
I run the infrastructure of five brands solo through Claude Code: content engines, e-commerce, ad factories, a book-publishing pipeline, dashboards. That means dozens of agent runs a day, most of them unattended. So the question I care about is not "which model is smartest." It's "which model is smart enough for this step, and what does the whole run cost when I add it up." The industry has a name for the answer now: model tiering, or heterogeneous agent architectures.
What model tiering actually means
The idea is straightforward once you say it out loud. A frontier model is expensive because it is doing hard reasoning. Most steps in an agent workflow are not hard reasoning. They are formatting, extraction, classification, following a plan that was already written. So you split the work by difficulty.
Coverage this year has settled on a common shape. As MachineLearningMastery put it in their 2026 agentic trends piece, the economics "demand heterogeneous architectures: expensive frontier models for complex reasoning and orchestration, mid-tier models for standard tasks, and small language models for high-frequency execution." The specific pattern that keeps coming up is Plan-and-Execute: a capable model writes the strategy, cheaper models carry it out. Their reported figure is that this can cut costs by up to 90% compared to running everything through a frontier model. (MachineLearningMastery, 2026)
I treat that 90% as a ceiling, not a promise — your mileage depends entirely on how much of your workload is genuinely reasoning versus rote execution. But the direction is right, and I feel it in the bills.
The Claude family gives you the tiers for free
You do not need three vendors to do this. The current Claude lineup is already a tier ladder. Opus 4.8 and the new Claude 5 family sit at the top for orchestration and the genuinely hard calls; Haiku 4.5 is the fast, cheap worker for high-frequency steps. Claude Code lets each subagent run with its own model, so tiering is a configuration decision, not an architecture rewrite. (Claude Code — What's new)
That last part matters more than it sounds. A subagent in Claude Code is an isolated instance with its own context window, its own tool permissions, and its own model. So the "planner in Opus, executors in Haiku" pattern is not something you bolt on — it is the native grain of the tool. You write the plan step at a high tier and fan the work out to a fleet of cheap workers underneath it.
How I actually split the work
Here is the rule of thumb I use when I'm deciding what tier a step belongs to. It is not scientific, but it has held up across a lot of runs.
- Does the step decide what happens next? Orchestration, planning, choosing which branch to take — top tier. This is where a wrong call cascades, so I pay for judgment here.
- Does the step need to hold the whole picture in its head? Cross-referencing many sources, catching a contradiction, reconciling conflicting inputs — mid to top tier.
- Is the step mechanical with a clear spec? Reformatting, extracting fields, applying a template, classifying into known buckets — cheap tier. High volume, low stakes.
- Is the step a verification pass on someone else's output? This one is a trap, and I'll come back to it.
- Is the step producing customer-facing prose or a public claim? Bump it up a tier regardless of volume. A cheap model saving a fraction of a cent is not worth a sentence that misrepresents a product.
The counterintuitive one is number four. My instinct was to verify cheaply — it's "just checking." But verification is often harder than generation, because the checker has to model where the generator could have gone wrong. I wrote about why the checking step is the part that quietly breaks in agents in production and the verification gap. Tiering does not exempt you from that. If anything it sharpens it: the cheap executor makes the mistake, and you need something with enough judgment to catch it. So verification usually rides one tier above the work it's checking, not below.
Tiering and context are the same discipline
Model tiering does not live on its own. It sits right next to context engineering, because a cheap model with a bloated context is the worst of both worlds — you pay for tokens and you get a worse answer, since smaller models feel the "lost in the middle" effect harder than big ones.
The move that makes tiering work is the same move that makes context work: give the cheap executor a tight, complete, self-contained brief so it doesn't need frontier-level reasoning to figure out what you meant. When the plan is explicit, the execution is genuinely easy, and a small model handles it cleanly. When the plan is vague, you're paying a big model to reconstruct intent every step. I go deeper on the mechanics of that in context engineering for solo operator agent fleets. Tiering is what you do with a well-engineered context; it's the payoff, not a separate project.
Where the savings actually show up
For me the biggest win is on the scheduled, unattended work — the runs that happen while I sleep. My authority-engine content loop publishes on a schedule with no manual steps. That's exactly the profile where tiering pays: high frequency, mostly mechanical execution wrapped around a small amount of real planning. Put the plan on a capable model once, let a cheap fleet grind through the volume, and the per-run cost drops without the output getting visibly worse. I've written before about the shape of that kind of scheduled agent work that runs overnight — tiering is what keeps it affordable at volume.
The honest caveat: tiering adds a decision to every workflow you build. You now have to think about where each step lands, and you'll get some of those wrong at first. A step you tiered too low will produce quiet garbage that a verification pass has to catch. So I don't tier aggressively on day one. I build the workflow on a capable model, watch which steps are obviously mechanical, and demote those specific steps once I trust them. Cheap-by-default is a good instinct for a bill and a bad instinct for a first draft.
FAQ
Does model tiering hurt output quality?
It can if you tier the wrong steps. The failure mode is putting real reasoning or public-facing claims on a model that's too small. Done right — cheap models only on mechanical, well-specified steps, with a capable model on planning and verification — the visible quality holds while the cost drops. Start capable, demote steps you've watched and trust.
Do I need multiple AI vendors to do this?
No. The current Claude lineup already spans tiers — Opus 4.8 and the Claude 5 family for orchestration, Haiku 4.5 for high-frequency execution — and Claude Code lets each subagent pick its own model. Tiering becomes a config choice inside one tool rather than a multi-vendor integration project.
Is the "90% cheaper" figure real?
Treat it as a ceiling for a favorable workload, not a guarantee. The 90% reduction reported for the Plan-and-Execute pattern (MachineLearningMastery, 2026) assumes most of your steps are execution, not reasoning. The more of your workflow is genuinely hard thinking, the smaller the saving — because that's the part you correctly keep on the expensive model.
— Italo Campilii. If you're building something that needs this kind of operator, get in touch.