Cheap Model or Expensive Model? The Routing Rule That Cuts AI Agent Bills
The rule that cuts an AI agent's bill is to route each task by the judgment it needs, not its size: mechanical work goes to a cheap model, research-with-synthesis to a mid model, and only strategy and design to the expensive one. Run everything on the top model and you overpay; run everything cheap and a hard call gets fumbled.
Most teams pick one model and use it for everything, which is why the bill looks the way it does. The instinct is that the best model gives the best result on every task, but most agent work is not hard - it is legwork. Sweeping text for a phrase, collecting numbers, filling a checklist: these have one right answer, and a cheap model reaches it just as reliably as a costly one. Paying flagship rates for legwork is the single most common way an agent runs up a bill with nothing to show for the premium.
The fix is not a discount or a cheaper vendor. It is a routing rule you decide once and then apply on every task, so the expensive model shows up only where it earns its price. That price gap is real and worth planning around; we break the raw math down in what it costs to run an AI agent.
Which tasks deserve the expensive model?
The expensive model is worth it only where a wrong call is expensive and there is no single right answer. Choosing a niche, designing a product or a system, writing the flagship copy whose quality is the actual product - these are places where a mediocre answer costs you more than the model ever could, and where two capable people could reasonably disagree. That combination, high stakes plus genuine ambiguity, is the whole test. If a task has neither, you are overpaying.
Notice the test is about judgment, not effort or length. A task can be long, tedious, and enormous in volume and still be cheap-tier if every step has one correct outcome - a thousand-line text sweep is still mechanical. A task can be a single sentence and still be top-tier if it is a strategic call that sets the direction of everything downstream. Size is a distraction; the question is only how much judgment a wrong answer would cost you.
Between those poles sits the mid tier, and it is where the routing rule earns most of its savings. Research that requires synthesis, verification of a claim, editorial review of someone else's draft - work that needs real judgment but is not strategy - runs well on a mid model. You are not deciding the direction of the business; you are executing skilled work against a brief. Sending that to the top model is the quiet, everyday overspend that a routing rule removes, because it happens dozens of times a session without anyone noticing.
Example (as of July 2026, check current names and prices before you copy this): a cheap tier looks like Claude Haiku or GPT-4o mini; a mid tier looks like Claude Sonnet; a top tier looks like Claude Opus or a frontier flagship. The tiers are roles, not brands - vendors reshuffle names and prices constantly, so treat this as a snapshot and re-check the current lineup. We track notable model price and tier changes on our radar.
How do you enforce the rule so it survives sessions?
Write the rule into the agent's contract file, set an explicit model on every subagent, and treat a missing model parameter as a bug. A rule you only say in chat lasts one conversation; a rule written into the file the agent reads on startup governs every session after it. The contract is where routing has to live, right next to the agent's other standing instructions, so no session has to rediscover it.
Our own contract does exactly this: the top model is reserved for the main strategic session, and every subagent it spawns gets an explicit model parameter matched to its task tier - cheap for mechanical sweeps, mid for research and verification, top only when the output quality is the product. The word "explicit" is doing the work here. A subagent launched without a stated model does not default to cheap; it inherits the caller's model, which on a strategy session is the most expensive one you have.
We learned that the hard way. Five subagents once fired off to do a mechanical text sweep - pure legwork, one right answer per line - and every one of them ran on the most expensive model, because nobody set a model parameter and they silently inherited the flagship from the main session. It was caught by a human reviewer, not by the system, which is the uncomfortable part. The lesson became a standing rule: a missing model parameter is a bug, not a shortcut. If a subagent's tier is not stated, the launch is wrong and gets fixed before it runs, the same way you would treat any other unset required field.
That is the difference between a routing rule that saves money and one that only sounds good in a meeting. The savings are not in knowing which tier fits a task; most people can eyeball that. The savings are in making the right tier the default that survives across sessions and subagents, so the flagship never quietly picks up work that a cheap model would have finished for a fraction of the cost.
FAQ
Does the cheap model hurt quality?
Not on mechanical work with one right answer. Sweeping text, collecting numbers, and filling checklists have a single correct outcome that a cheap model reaches reliably, and a coordinator spot-check catches the rare miss. You save real money by not running that legwork on the flagship - and you lose nothing, because there was no judgment for the expensive model to add in the first place.
How do I find the boundary between tiers?
Route by judgment required, not by length. Ask whether the task has one right answer or genuine room to disagree, and whether a wrong call would be expensive. A long, boring sweep is cheap-tier no matter how many lines it runs; a one-line strategic call that sets direction is top-tier even though it takes seconds. Effort and volume are distractions - only the judgment at stake decides the tier.
What about consistency across a task?
Keep one tier per task and let a coordinator integrate the pieces. Mixing tiers mid-task is fine as long as the cheap parts are genuinely mechanical and every actual judgment call stays on one model, so the reasoning does not wobble between two brains. The failure mode to avoid is splitting a real decision across tiers; the safe pattern is cheap legwork feeding a single higher-tier model that makes the calls.