Most conversations about Claude Code spend start and finish with the price list. Which model is cheapest per million tokens, and should the team drop a tier to save money? In September 2026 Anthropic published a breakdown of what a Claude Code task on Opus 5.5 actually costs, and it points somewhere else. The bill is set less by the sticker price than by how the task is run.
That matters for any Australian team that has moved developers onto Claude Code, or is weighing a switch from Cursor or another coding agent. The levers that move the monthly invoice are mostly operating habits, and they are cheap to change.
What does a Claude Code task on Opus 5.5 actually cost?
A Claude Code task on Opus 5.5 costs whatever its turns add up to. Each turn resends the whole conversation so far, so a task that grows from 20K to 120K tokens of context costs far more at 40 turns than at 25, even though the context never passes 120K either way. Cache hits, thinking output and model choice then adjust that total up or down.
Anthropic lists Opus 5.5 API pricing at $4 per million input tokens, $20 per million output tokens and $0.20 per million cache reads (US dollars). Thinking tokens are billed as output, which is five times the input rate. Those three numbers are the only prices you need for the arithmetic below.
The four levers Anthropic names
The breakdown, written by Addy Osmani, names four things that set the cost of a task:
Turns.
Cache hit rate.
Thinking share.
Model choice.
The headline message is blunt: a retry costs more than any token-saving trick. If a cheaper model has to attempt the task twice, it has usually cost more than the stronger model getting it right once.
A worked example: 25 turns against 40
Here is our own arithmetic on the scenario Anthropic describes, using the list prices above. Assume context grows steadily from 20K to 120K tokens, so the average turn resends about 70K tokens, and each turn produces about 1,500 output tokens. These are illustrative assumptions, not Anthropic's figures.
| Scenario | Input resent | Uncached input | 90% cached input | Output | Total, cached |
|---|---|---|---|---|---|
| 25 turns | 1.75M tokens | $7.00 | $1.02 | $0.75 | $1.77 |
| 40 turns | 2.8M tokens | $11.20 | $1.62 | $1.20 | $2.82 |
| 25 turns, then a full retry | 3.5M tokens | $14.00 | $2.04 | $1.50 | $3.54 |
Two things stand out. Caching cuts the input bill by roughly 85 per cent, which is why a cold cache is the first thing to look for in a costly session. And the retried task costs double the clean one, more than the chatty 40-turn version. No change of model tier closes a gap that size.
What that looks like for a team
Scale it up. Take a Sydney product team of 20 developers each running ten Claude Code tasks per working day, about 4,200 tasks a month. The gap between the 25-turn and 40-turn versions is about US$1.05 a task, or roughly US$4,400 a month. At an illustrative exchange rate that is close to $6,800 a month in Australian dollars, or over $80,000 a year, from turn discipline alone. Your numbers will differ; our ROI calculator is a quicker way to model your own team.
Where Australian teams usually lose money
In the Claude Code rollouts we support, the expensive sessions tend to share a few habits:
Vague first prompts that make Claude spend turns working out what was wanted.
Long sessions that wander across several unrelated jobs, so every turn carries dead context.
Edits to CLAUDE.md or system files mid-session, which break the cache prefix.
Maximum effort or thinking settings left on for routine edits.
Accepting a half-right result, then re-running the whole task instead of correcting it.
Each one either adds turns, drops the cache or inflates the output share. None is solved by switching models. Our earlier guide to reading Claude Code token usage as a team lead covers how to spot these in the usage data, and how to cut token waste in Claude Code has the day-to-day fixes.
How to keep the bill down without slowing the team
The practical playbook follows the order of the levers. Watch turns and cache hit rate before you touch the model tier.
Write a precise brief up front: the file, the outcome and the test that proves it is done.
Start a fresh session for each distinct task instead of reusing one long thread.
Keep stable instructions at the top of context and avoid editing them mid-session, so the cache holds.
Match effort to the job. Routine refactors rarely need maximum thinking.
When a result is close, correct it in the same session rather than starting over.
Review the most expensive sessions each week and look for the pattern, not the person.
Caching behaviour is worth understanding properly; our piece on prompt caching lessons from Claude Code goes deeper. For a contrast on how pricing changes play out at the task level, see our note on Claude Fable 5.1 cache and per-task pricing.
What not to conclude
This is not an argument that Opus 5.5 is always the right choice, or that cost does not matter. Plenty of tasks are simple enough that a smaller model gets them right first time, and then it is cheaper. The point is narrower: compare models on cost per finished task, including retries, not on the price per million tokens. A model that is 40 per cent cheaper per token but needs a second attempt on one task in three has not saved you anything.
It is also worth remembering that list prices are in US dollars and billed through whatever plan your organisation uses. Seat-based Claude plans, API billing and enterprise agreements each expose these levers differently, so check which one your developers are actually on before setting targets. Australian finance teams will also want the spend mapped to cost centres; that is a reporting job, not a model choice.
The short version
Read Anthropic's full breakdown and interactive cost calculator if you run Claude Code at any scale. Then measure turns per task and cache hit rate for a fortnight before anyone proposes a cheaper model. If you want help setting that up across a team, talk to us or see how our Claude Code services work.
