Stop paying frontier prices for mechanical AI work

Every founder I talk to about their AI tooling bill describes the same shape: fast growing, hard to explain, and dominated by one model. They picked the best model available, wired it into everything, and now every task, from architecture decisions down to renaming a batch of files, gets billed at the same rate. That is the pattern I want to unwind here, because a large share of what lands on that top-tier bill is work a model costing a tenth as much would do identically well.

This is not a call to use cheap models everywhere. It is the opposite mistake, and it is just as common: forcing every agent onto one flat model, in either direction, throws away the thing that actually saves money, which is matching the model to the task.

The price sheet nobody reads

As of July 2026, here is Anthropic's public list pricing per million tokens, input and output:

That is roughly a 10x spread from top to bottom on input pricing, and the sheet actually understates the real gap. Top-tier models tend to reason longer before answering, which means more output tokens per task, and output is priced higher than input across the board. Two models asked to do the same job do not just differ in per-token price; the pricier one often produces more tokens doing it. The real spend gap between routing a task to the top model versus the cheapest capable one is larger than the price sheet alone suggests.

Where the money actually goes

The waste pattern I see most often is simple: a team standardizes on one frontier model and sends everything through it, including work that has nothing to do with hard reasoning. File scans. Format checks. Data extraction. Boilerplate generation. Renaming a batch of variables. Summarizing content that is already known to be good. None of that needs the model that is best at ambiguous, high-stakes judgment calls. It needs a model that can follow a clear instruction and produce a correct, checkable output, and several tiers down the price list already do that.

The fix is not "use the cheap model instead." It is deciding, task by task, which tier a given piece of work actually belongs on.

How I tier the work

In my own setup, the top-tier model runs only the main loop: orchestration, architecture decisions, and the hardest debugging, the parts where a wrong call is expensive and there is no simple way to check the answer. Everything delegated, implementation, tests, refactors, research, runs on the mid tier, which handles the large majority of real coding and writing work at roughly a third of the top model's price. Mechanical work, the scans and format checks and extraction jobs, runs on the smallest tier, at a third of that again.

There is a fourth option below all three: for work that is both batchable and checkable, a free local model running on my own hardware can take it, at zero marginal cost. It is not a fit for everything; it fabricates on unverifiable judgment calls the same way an underpowered cloud model would. But for the checkable slice of work, it is a real option, and I wrote up exactly where it holds up and where it does not in our benchmark of a free local model against the paid ones.

The routing rule of thumb

The rule I actually use when deciding where a task goes is this: if the output is checkable, meaning tests pass, a schema validates, a file exists, or there is one exact correct answer, route it one tier lower than instinct suggests, then verify the output. If the cost of a wrong answer is high and the output is not verifiable, meaning it is strategy, a client-facing judgment call, or anything else without a clear right answer, route it one tier up instead.

Verification is what makes the down-routing safe. A cheap model plus a check beats an expensive model plus blind trust, for anything checkable. You are not gambling on the small model being right; you are confirming it, and confirming is cheap. The mistake is skipping the check, not choosing the cheap model.

The lever nobody dials: reasoning effort

Model tier is not the only knob. Modern models let you set how long they think before answering, often called reasoning effort or a thinking budget, and this is a second, often-overlooked lever on cost. A routine single-file edit does not need maximum reasoning effort. An architecture decision or a hard debugging session does. Dialing effort down on routine work is cheaper than dropping a model tier, and it hits the most expensive line item directly, because thinking tokens are billed as output, at the output rate.

In practice this means the same model can cost noticeably different amounts depending on whether you left it set to think as hard as possible by default, or turned that down for the routine stretches of a session and saved the high-effort setting for the parts that actually need it.

The silent leak: delegation defaults

Here is the leak that shows up on the invoice and nowhere else. When an expensive top-tier session spawns helper agents to do delegated work, those helpers typically inherit the expensive model by default, unless you explicitly set a cheaper one for each delegation. A session that starts on the top tier can quietly fan out into a dozen sub-tasks all billed at the top tier, even though most of those sub-tasks are exactly the checkable, mechanical work that belongs several tiers down.

The mirror-image mistake is just as damaging: setting one flat override that forces every agent, regardless of task, onto a single model. That looks like cost discipline, but it destroys the tiering in the other direction, either overpaying for mechanical work or underpowering the judgment calls that actually need the strong model. Both failure modes come from the same root cause: not setting the model explicitly, per task, and instead letting a default carry it. There is no shortcut around deciding this per task type. If you also run a team of agents rather than a single assistant, the same discipline extends to how you orchestrate that whole team, since the delegation defaults compound across every agent in the chain.

The bottom line

None of this is exotic. It is closer to how any team allocates its most expensive senior person: the senior engineer reviews the architecture and the gnarly bug, not every commit message and file rename. AI tooling bills grow out of control for the same reason understaffed teams burn out their best person, because nobody separated the work that needs judgment from the work that just needs to get done correctly and checked.

If your AI spend keeps climbing and you suspect, correctly, that most of it is going to work that never needed the frontier model in the first place, that is a routing problem, not a model problem, and it is usually fixable in an afternoon once someone actually looks at where the tokens are going. Send a brief and I will help you find the split.