Sonnet 5.5's cache-read price cut: what it does to coding agent bills

Alongside the launch of Claude Haiku 5.5 on 7 October 2026, Anthropic cut the price of cache reads on Claude Sonnet 5.5 by half. The announcement says cache reads now cost $0.10 per million tokens instead of $0.20, and that because cache reads make up a large share of token use, Sonnet 5.5 now runs "around 20% cheaper on most agentic work." For teams running coding agents on Sonnet 5.5, that is a real saving with no change on their side. It also shifts the economics in a way that makes cache behaviour more important to watch, not less.

The context: how a coding agent is billed

A coding agent sends the model a long, mostly unchanged prompt on every turn: the system prompt, tool definitions, project instructions and the conversation so far. Prompt caching lets the provider store that prefix and charge much less to reuse it. The prompt caching documentation lists Sonnet 5.5 at $2 per million input tokens, $2.50 for a 5-minute cache write, $4 for a 1-hour cache write, $0.10 for a cache hit and $10 for output. Cache hits on Sonnet 5.5 and Opus 5.5 are priced at 0.05 times the base input price, against the standard 0.1 times for other models.

Each response reports three input figures: cache_read_input_tokens, cache_creation_input_tokens and input_tokens, where the last counts only tokens after the final cache breakpoint. Total input is the sum of the three. The default cache lifetime is 5 minutes, and the minimum cacheable prompt for Sonnet 5.5 is 512 tokens.

The Haiku 5.5 announcement also lists Haiku 5.5 cache reads at $0.01 per million tokens for prompts up to 100,000 tokens and $0.05 above that.

Analysis: a worked example

The following is an illustrative example, not a measurement. Take one mid-session agent turn on Sonnet 5.5 with a 5-minute cache: 95,000 tokens read from the cache, 4,000 new tokens written to it (the latest tool output), 500 uncached input tokens and 1,000 output tokens.

Component	Tokens	Before 7 October	After 7 October
Cache reads	95,000	$0.0190	$0.0095
5-minute cache writes	4,000	$0.0100	$0.0100
Uncached input	500	$0.0010	$0.0010
Output	1,000	$0.0100	$0.0100
Turn total		$0.0400	$0.0305

That turn is about 24% cheaper, close to Anthropic's figure. The saving depends on the mix: a turn with more output or more new context saves less, because only the cache-read line changed.

Now take the same turn with the cache expired, for example after a developer stepped away for longer than the cache lifetime. The 99,000-token prefix is written again at $2.50 per million ($0.2475), plus the uncached input and output, for about $0.26. That is roughly 6.5 times the cost of a cache hit at the old price, and about 8.5 times at the new one.

Cheaper hits make misses relatively dearer

That is the main consequence. When reads get cheaper and writes do not, the gap between a good session and a badly cached one widens. Teams that already had high hit rates get the full benefit. Teams whose sessions often miss see a smaller saving than the headline, and the misses become a larger share of their bill.

What causes misses

The caching documentation lists what invalidates a cache. Changing tool definitions invalidates the whole cache. Changing thinking settings or the output_config.effort value invalidates message blocks, with model-specific effects on the rest. The system checks for earlier cache entries within a 20-block lookback window per breakpoint, so long conversations can miss if breakpoints are placed poorly. And entries expire after 5 minutes by default, so idle time between turns matters. In coding tools, the usual culprits are MCP servers or plugins that change the tool list mid-session, switching effort or thinking levels, and long pauses.

The harness decides most of this

Developers rarely place cache breakpoints themselves; the agent harness does. Two harnesses on the same model can produce very different hit rates and bills, which is the point of the harness sets the bill. For measuring hit rates in general, see prompt caching as a cost control; for Sonnet 5.5's wider prices and benchmarks, see Claude Sonnet 5.5: faster mid-tier coding without a list-price rise.

What it means for engineering and security leaders

Expect a lower Sonnet 5.5 bill from 7 October without any change, but do not assume the full 20% applies to every team. Check it against your own data.

Claude Code makes that possible. Its monitoring documentation describes a claude_code.token.usage metric with a type of input, output, cacheRead or cacheCreation, where input excludes cached tokens, and API request events that carry cache_read_tokens and cache_creation_tokens. The same page says its cost metrics are approximations, and points to the provider's console for official billing. So any dashboard built on that telemetry needs current prices to estimate cost correctly, and should be checked against the provider's figures.

The cut also changes the comparison with other models. A routing decision made on September prices, such as sending some work from Sonnet 5.5 to a cheaper model, may now be worth revisiting, particularly for long sessions dominated by cache reads.

Practical takeaways for this week

• Compare Sonnet 5.5 cost per session for the two weeks before and after 7 October, using provider billing as the reference.
• Track the cache-read share of input tokens per session and per tool; a falling share is the early sign of misses.
• Look for sessions with repeated large cache writes, and check whether tool lists, effort or thinking settings changed mid-session.
• Make sure any cost dashboard uses the new $0.10 cache-read price for Sonnet 5.5.
• Revisit routing rules that were set on cost grounds before the change.

Where SpanDock fits

When a tool reports tokens but not cost, SpanDock estimates the cost from a price catalogue and marks it as estimated; a cost the tool reports itself always wins. As the model proxy and budgets page describes, your own overrides under Settings → Model prices take priority over the built-in Claude prices and the public list, so a price change like this one can be reflected straight away in estimated costs; a cost the tool reports itself, as Claude Code does, is used as reported. The Models page, described in getting started, then ranks the models your tools used by spend and value.