Why cheaper AI models can cost more in Claude Code

I have been building a software platform (opens in a new tab) with Claude Code for some time. It is now over 300,000 lines of code. One of the most expensive lessons I have learnt is that using a cheaper model does not necessarily mean using fewer tokens. Sometimes it means using far more.

The plan that seemed obvious

My set-up uses a lead agent that plans the work and hands tasks to workers. Early on, I had what felt like a sensible idea: send the simpler coding tasks to cheaper, less capable models and save the stronger model for the hard problems. That way my Claude Code Max allowance would go further.

Sometimes it worked brilliantly. A small, well-defined change went to a cheaper model, came back correct and cost very little.

Other times, a worker would get stuck. It would change the code, run the tests and fail. It would try another fix and fail again. Then it would try a third approach, a fourth, a fifth. Each attempt re-read files, re-ran tests and added more to its context. I have had this go on for hours.

Where the cost actually goes

The expensive part was never the first attempt at writing the code. It was everything that followed when the first attempt was wrong:

• Repeated attempts. Every failed fix still uses tokens, and so does the next one.
• Test runs. Running the tests again after each attempt, sometimes the whole suite, adds up quickly.
• Growing context. Each attempt carries the history of the previous ones. Later requests get bigger and more expensive than earlier ones.
• Review. Every rejected attempt also costs the lead agent’s time to review it and explain what is wrong.

Anthropic’s own guidance on optimising for cost and intelligence (opens in a new tab) describes this exactly. It says to compare models on cost per completed task, not per token, “because you pay for completed tasks”. It also warns that the bill is decided by the tasks the cheaper model fails, because a failed task still bills its tokens, then the retry, then whatever the failure costs downstream. And a more capable model can finish a task with less work, which can offset much of its higher price.

That matched my experience precisely.

The numbers behind the temptation

The temptation is understandable, because the price gaps are large. As of October 2026, Anthropic’s published API prices (opens in a new tab) per million tokens are roughly:

Model	Input	Output
Claude Opus 5.5	$4.00	$20.00
Claude Sonnet 5.5	$2.00	$10.00
Claude Haiku 5.5	$0.10	$0.50

Haiku’s price rises to $0.50 input and $2.50 output when a single request is over 100,000 tokens, which long coding sessions can easily reach.

On paper, a task on Haiku costs a small fraction of the same task on Opus. But that comparison assumes both models finish the task in the same number of steps. If the cheaper model needs ten attempts and the stronger model needs one, the arithmetic changes completely. If the cheaper model never finishes, you pay for every attempt and still have to pay the stronger model at the end.

On a subscription such as Claude Code Max, you do not see a per-token bill, but the same logic applies to your usage allowance. Wasted attempts eat into the week just as they would eat into an API budget.

What I changed

I have not abandoned cheaper models. I have changed how I use them.

1. A lead agent coordinates and reviews. One session plans the work, assigns tasks and checks the results. I wrote about the wider set-up in building with multiple AI coding agents.

2. Workers operate on separate branches. Each task happens in its own branch, so a struggling worker cannot damage anyone else’s work, and a failed attempt can simply be thrown away.

3. Tests run in stages. Instead of re-running everything after every small change, workers test the part they changed first, and only run the full suite once that passes.

4. Repeated failure means escalation, not another retry. When a worker keeps failing, the task goes to a stronger model rather than round the same loop again.

5. Lead sessions start fresh. I start a new lead session regularly and use project documentation to restore context, rather than letting one conversation grow forever.

The full workflow, including how I spread usage across the whole week, is in how I make my Claude Code Max limits last all week.

How to decide when to escalate

The hardest question is when a cheap worker has had enough chances. When I shared this experience with other Claude Code users, several practical rules came back:

• Cap the retries. Two failed attempts on the same error, and the task goes to the stronger model.
• Only delegate tasks that come with a test. If the worker cannot check its own work, it should not be working alone. No test, no delegation.
• Set a time limit. If a task is not done within a set time, try it with a stronger model.
• Watch for false success. One person tested a small local model on coding exercises. It reported success far more often than the tests agreed. An escalation rule that waits for a worker to admit it is stuck will miss these.

That last point matters most. The lead should decide whether work is done based on the test results, not on the worker’s own report. I come back to this theme often in where human oversight still matters in AI-assisted development: the check has to be independent of the thing being checked.

Choosing models in Claude Code

Claude Code makes model choice easy to control. The subagents documentation (opens in a new tab) explains that each subagent can be given its own model, such as sonnet, opus or haiku, or set to inherit the main conversation’s model. Each subagent also runs in its own context window, so verbose work stays out of the main conversation.

The Claude Code cost guidance (opens in a new tab) suggests Sonnet for most coding tasks, Opus for complex architectural decisions or multi-step reasoning, and Haiku for simple subagent tasks. That is a sensible starting point. My addition is that “simple” should be judged by the task’s risk of going wrong, not its size. A three-line change in a fragile part of the system is not simple.

Anthropic’s cost guidance also suggests tuning effort on one model before adding a second, and pricing the stronger model on its own at a lower effort level. In other words, the cheapest way to finish a task is not always a cheaper model. Sometimes it is a stronger model told to think a bit less.

The lesson

Optimise for the cost of getting a task completed correctly, not the cost of the model doing the task.

A cheap attempt that fails is not cheap. It is the first instalment on an expensive one. The skill is in matching the model to the risk, setting clear rules for when to stop and escalate, and giving every worker a test it cannot argue with.

I am still refining this, and I would like to know how others handle it. Do you start cheap and escalate, or start with the stronger model from the beginning?