Model Tiering: How a Solo Operator Runs Agent Fleets Without the Frontier-Model Bill Eating the Margin

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. It is the core discipline of AI agent cost control, and it's cheaper to learn from someone else's bills than from your own.

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 doctrine: orchestrate high, execute cheap#

I didn't arrive at this from a whitepaper. I arrived at it from a property film that went wrong. The build had the right ingredients — good footage, working pipeline — and the wrong storytelling, because I let the execution layer make orchestration decisions. Shots got picked by mechanical criteria (jitter, exposure) instead of by a narrative plan. The fix became a standing rule in my system: orchestration and execution are separate jobs. The most capable model maps the whole story first — every step verified against intent — and only then does a fleet of execution agents do the mechanical assembly.

That rule generalizes to every workflow I run. The failure mode of skipping it is always the same shape: individually competent steps, incoherent whole. A cheap model can execute a plan beautifully. It cannot be trusted to notice the plan is wrong, because noticing requires holding the whole picture, and holding the whole picture is exactly the expensive skill you tiered away. So the frontier model's job is not "do the work." Its job is to make the work unambiguous enough that cheap models can't get it meaningfully wrong.

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 at the top tier, executors below it" 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.

The counterintuitive row is verification. 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.

The same logic applies to the standing instructions your agents inherit. A well-maintained CLAUDE.md and a tight skill library are what let a cheap executor behave like it has judgment it doesn't actually have — the judgment was front-loaded into the instructions. That's the subject of how CLAUDE.md and skills stop agent drift, and it's the other half of making low tiers safe.

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.

What's the cheapest way to start tiering an existing agent workflow?#

Don't refactor. Pick the one highest-frequency step in your busiest pipeline — usually a formatting, extraction, or classification step — write it a self-contained brief, and move only that step to a cheap model. Watch a week of output. If it holds, demote the next step. Tiering is a sequence of small, reversible demotions, not a migration.

— Italo Campilii. If you're building something that needs this kind of operator, get in touch.