Opus 5.5 is 35% cheaper for agents, not 20% — and two thirds of the bill is cache writes

The 30-second version

Anthropic shipped Claude Opus 5.5 on 22 September. The price sheet changed in two directions at once:

Anthropic’s own headline is that Opus 5.5 costs 40% less on typical workloads at default settings — a figure that combines the lower prices with using fewer tokens per task. We wanted to isolate just the price sheet, so we measured the token mix of six long-running agent sessions — 7,850 assistant turns, 2.9 billion input-side tokens — and repriced that fixed traffic against both sheets. Holding tokens constant answers a narrower question than Anthropic’s 40%, and does not test it.

Three things came out of it:

1. Uncached input is 0.015% of the traffic. The headline input price is quoted against a rounding error. Cache reads are 93.4%, cache writes 6.6%.
2. The real cut is 35.3%, not 20% — $3,534 down to $2,286 on the same traffic — because the 60% cache-read cut lands on the category that actually has volume.
3. The biggest line is cache writes, at 54.3% of the modeled Opus 5 cost and 67.1% on Opus 5.5. Not reads. Write prices fell 20% too — writes simply became a larger share of a smaller total.

The third one is the useful one, and it is the opposite of how most people think about caching.

What we measured

Six agent sessions running against real work — code, research, operations — each running continuously for days to weeks. Every assistant turn in a Claude Code transcript records a usage object with four counts: input_tokens (uncached), cache_creation_input_tokens (written), cache_read_input_tokens (read back), and output_tokens. We summed all of them.

Output was 10,467,579 tokens across all six — about a third of a percent of input-side volume.

The spread is worth noting: 88.2% to 96.8%. Even the least cache-heavy session was seven-eighths cache reads. Uncached input reached at most 0.051% of any session’s input-side traffic.

One trap if you replicate this. A Claude Code transcript writes the same assistant message more than once — our largest session held 3,291 usage records for 1,570 distinct message IDs. Summing every record double-counted 51% of its tokens. Deduplicate by message.id before you add anything up; the figures above do.

That shape is not an accident, though six sessions cannot establish how common it is. A long agent loop has a large stable prefix — system prompt, tool definitions, skills, accumulated conversation — that gets written to cache once and then read back on every single turn. Turn count multiplies reads. Nothing multiplies uncached input.

What that does to the price cut

Repricing the same 2.9 billion tokens against each sheet. These are modeled token charges at standard API list prices, not a reconciled invoice: they cover the four token categories only, and exclude server-side tool fees and any negotiated rates. We price every write at the one-hour rate, since 99.5% of write tokens used it — pricing the 0.5% exactly changes the totals by about 0.1%.

35.3% cheaper. If you had assumed the 20% headline applied across the board you would have budgeted $2,827 and come in $541 under — and $541 is exactly the extra saving on the cache-read line, because that is the whole difference.

So the headline understates the cut for this workload. That is the pleasant version of the finding. Here is the other one.

The bill is mostly cache writes

Look again at the Opus 5.5 column. Cache reads are 93.4% of the tokens and 23.7% of the cost. Cache writes are 6.6% of the tokens and 67.1% of the cost.

The arithmetic is simple once you see it. In our data, read tokens outnumbered write tokens by 14.1 to 1. But on Opus 5 a one-hour cache write cost $10 per million against $0.50 for a read — 20x. Twenty beats 14.1, so writes cost about 1.4x what reads cost.

Opus 5.5 widens the gap rather than closing it, because the two prices moved by different amounts:

This is the part that inverts the usual advice. The common instinct is to minimise context so you read fewer tokens back. On this price sheet, reading tokens back is the cheap part. What costs money is invalidating the cache, because every invalidation rewrites the prefix at 2x the base input price. A change that shrinks your prompt by 10% but causes an extra rewrite each turn makes the bill worse.

Anthropic says reads dominate. In these six sessions, writes cost more.

The Opus 5.5 announcement states it directly, in a parenthesis:

Cache reads (which make up the majority of agentic and coding work costs) are $0.20 per million tokens, 60% less than Opus 5.

On our traffic that is not true — reads are 23.7% of the Opus 5.5 bill and writes are 67.1%. Rather than assume one of us is simply wrong, the useful move is to find the line that separates the two cases, because it is a single number.

Read spending overtakes write spending when there are enough reads to overcome the price gap. Writes cost write_price and reads cost read_price, so read cost exceeds write cost exactly when:

read tokens ÷ write tokens > write_price ÷ read_price

That is a comparison between two line items, not a claim about a majority of the whole bill — output and uncached input sit outside it. It is still the line that decides which of the two cache categories you should be managing.

That right-hand side is a property of the price sheet alone:

And the left-hand side is a property of your workload. Ours, per session:

Every one of the six sits below 40:1, which is why writes dominate all of them on the Opus 5.5 sheet. On the old Opus 5 sheet, where the bar was 20:1, three of them — A, B and E — were genuinely read-dominated. So both statements can be true of different workloads, and the disagreement is not really a disagreement: it is a question about where your ratio falls.

Two things follow that are worth more than the argument.

Anthropic can see far more traffic than we can. We measured six sessions; they have the aggregate across their customers, and we do not know what their parenthesis is based on. What our numbers add is an existence proof — long-running autonomous sessions that sit well below the line — plus the test for working out which side any given workload is on.

Opus 5.5 moved the line in the direction that makes the claim harder to satisfy. Cutting reads 60% and writes only 20% raised the break-even from 20:1 to 40:1 on one-hour caching. A workload that was read-dominated on Opus 5 becomes write-dominated on Opus 5.5 without changing at all — three of our six sessions did exactly that, going from read-led to write-led purely because the price sheet moved. The cheaper reads get, the more the bill is about writes.

The one-hour TTL, and the bar it has to clear

Anthropic sells two cache lifetimes: five minutes at 1.25x base input, one hour at 2x. Our sessions wrote to the one-hour cache essentially exclusively — 99.5% of all cache-write tokens.

At the observed write volume, pricing every write at the one-hour rate makes the total modeled cost 33.6% higher than pricing them all at five minutes — $2,286 against $1,711. The write line alone is 60% higher; the total moves less because reads and output do not change.

That is not a saving available by switching, and it would be wrong to read it as one. A shorter TTL expires more often, and every expiry forces a rewrite, so changing the TTL changes the write volume too. Our data cannot measure that counterfactual — we only observe what was actually written.

What the two prices do give you is a threshold, though not the naive one. Shortening the TTL does not simply add writes — the extra writes replace reads, because a rewritten prefix is a prefix you no longer read back. Netting that out, one hour is cheaper when:

W₅ₘ ÷ W₁ₕ > (price₁ₕ − price_read) ÷ (price₅ₘ − price_read)

On Opus 5.5 that is (8 − 0.20) ÷ (5 − 0.20) = 1.625. So:

The one-hour TTL pays for itself only if dropping to five minutes would increase your cache-write volume by more than 62.5% (65.2% on the Opus 5 sheet).

Comparing the write prices alone would have given 60%, which understates the bar — it forgets that the extra writes buy back read tokens.

For a session with a turn every minute or two, that bar is unlikely to be cleared — the five-minute cache rarely expires between turns, so you are paying the longer-lifetime premium on every write for a lifetime you seldom use. A session that goes quiet for twenty minutes at a stretch may clear it, but not automatically: what matters is how many write tokens those gaps would actually force, weighted by size, not how often the gaps happen. The TTL clock also starts at the request, so generation time counts against it. The point is that this is a measurable question about your own reuse intervals, not a default to accept.

What you actually pay per token

Blended across all input-side tokens in our measured mix:

Every headline rate overstates the agent-workload cost by four to six times, and not by the same factor for each model. The ordering happens to survive here — Sonnet 5, then Opus 5.5, then Opus 5, then Fable 5.1, on both columns — but the size of the gaps does not. Opus 5.5 looks twice Sonnet’s price on the headline and is 1.6x on ours. If you are sizing a budget or a switch, the headline spread is the wrong one to use.

Anthropic is clearly aware of this. The standard cache-read multiplier is 0.1x base input. Opus 5.5 is an explicit exception at 0.05x, and Fable 5.1 is a more aggressive one at 0.025x — which is why Fable’s cache reads are only 13.4% of its bill on our mix despite a $10 headline. These carve-outs exist because the vendor knows which number the agent workload actually pays.

Caveats worth stating

These are long-running sessions. Days to weeks, continuous — the shape the cache carve-outs appear aimed at. Six sessions from one machine are not a sample of anything wider, and a short chat session with a small prefix will sit much closer to the headline rate.

Subscriptions work differently. Pro, Max and Team charge a fixed monthly fee that a price-sheet change does not reduce. Usage beyond the included allowance is a separate matter — usage credits are billed at standard API prices, so the cut does reach that portion. The mix still matters either way, because the same traffic shape drives how fast a session burns its window.

We priced traffic, not behaviour. Repricing identical token counts against two sheets is a fair way to isolate a price change. It is not a prediction that your bill drops 31%, because Opus 5.5 is also reported to run faster and may not produce the identical token counts on the same work.

One-hour write prices throughout. Because 98-100% of observed writes used them. A workload on five-minute caching gets different totals, as the TTL section shows.

What to do with this

1. Stop reading headline input prices as agent prices. Compute your own blended input-side rate: pull usage from your transcripts, deduplicate by message ID, then take (uncached_cost + write_cost + read_cost) ÷ (uncached + write + read tokens), in dollars per million. Output is deliberately excluded — fold it in and Opus 5.5 comes to $1.108 rather than $0.717. Ours was under a fifth of the headline input rate.
2. Find out what your writes are before optimising context size. Reads are 93.4% of tokens and 23.7% of the modeled cost, so shrinking what gets read back is not where the money is. But cache writes are not all waste: appending a new message or a tool result writes legitimately, and only the rest is avoidable churn. Separate first-time writes and normal growth from genuine invalidation — a timestamp in a system prompt, a tool list that reorders, a file injected then removed — and only then decide what to fix.
3. Check your TTL against the 60% rule. Look at the actual gaps between turns. If your session is continuously busy, the one-hour cache is a premium for a lifetime you are not using.
4. When comparing models, price all four categories, not the headline. The multipliers differ — 0.1x cache reads is standard, Opus 5.5 is 0.05x, Fable 5.1 is 0.025x — but a low multiplier on a high base is not automatically cheap: Fable’s 0.025x still lands at $0.25 per million, above Opus 5.5’s $0.20, and its writes are the most expensive of the four. Weight each category by your own volumes.

Companion reading

• Claude Code’s 33,000-token startup overhead — what goes into the prefix that gets cached and re-read.
• Claude Code pricing — the subscription side of the same question.
• What enterprises actually spend on AI coding agents — the same bill at organisation scale.
• Spotify’s 90% token cut, reproduced — reducing what enters context, measured.
• Claude model tiers and effort levels — the other dial that moves token volume.

Sources

1. Anthropic — Prompt caching. Authoritative source for the pricing table and the multipliers: 1.25x for five-minute cache writes, 2x for one-hour, 0.1x for cache reads, with documented exceptions of 0.05x for Claude Opus 5.5 and 0.025x for Claude Fable 5.1.
2. Anthropic — Claude Opus 5.5. Release announcement, 22 September 2026.
3. Anthropic — Pricing. Per-model rates quoted above.

Our own measurements: six Claude Code sessions run on macOS against real work, 7,850 distinct assistant turns, token counts taken from the usage object each turn writes to the session transcript (input_tokens, cache_creation_input_tokens, cache_read_input_tokens, output_tokens), summed without sampling and deduplicated by message.id — transcripts re-serialise the same assistant message, and summing raw records inflated our largest session by 51%. No subagent (sidechain) turns appeared in these transcripts. Session names are replaced with letters. Costs are computed by applying the published price sheets to those counts, using one-hour cache-write prices because 98-100% of observed cache writes used the one-hour TTL.

FAQ

How much cheaper is Opus 5.5 for an agent? 35.3% on our measured traffic when only the price sheet changes — $3,534 to $2,286 on identical tokens. Anthropic separately claims 40% on typical workloads at default settings, which also assumes fewer tokens per task; fixed-token repricing neither confirms nor contradicts that. The gap is entirely the 60% cache-read cut landing on a category that has real volume.

What is the token mix? 0.015% uncached input, 6.62% cache writes, 93.37% cache reads, across 7,850 assistant turns. Per-session cache-read share ran 88.2% to 96.8%. Deduplicate by message ID first — raw records inflated our largest session by 51%.

Why do writes cost more than reads? Unit price beats volume. Writes were 14.1x rarer but priced 20x higher on Opus 5, so they cost 1.4x what reads cost. On Opus 5.5 that becomes 2.8x, because reads fell 60% and writes only 20%.

Is the one-hour TTL worth it? Only if it prevents enough rewriting, and the bar is higher than the write prices alone suggest: extra writes replace reads, so the condition nets out the read price and comes to 62.5% more write volume on Opus 5.5 (65.2% on Opus 5), not 60%. Check your actual reuse intervals rather than defaulting.

What do I really pay per token? On our mix, $0.717 per million input-side tokens on Opus 5.5 against a $4 headline. Under a fifth, and the factor differs by model (4.4x to 6.4x), so headline input price mis-ranks models for this workload.

Anthropic says cache reads dominate agentic cost — are they wrong? Not necessarily; it turns on one ratio, and the ratio settles which of the two cache lines is larger rather than what share of the whole bill they take. Read cost exceeds write cost only above write price ÷ read price — 20:1 on Opus 5 with one-hour caching, 40:1 on Opus 5.5. Our sessions ran 7.5:1 to 30.4:1, so writes lead all six on the new sheet, though three led with reads on the old one. They see far more traffic than we do; we contribute the test.

Does this change my Claude Code subscription bill? The fixed monthly fee, no. Usage past the included allowance is billed as usage credits at standard API prices, so the cut reaches that part. The mix matters either way, because it drives how fast a session consumes its window.