Why Claude Code Pays Twice for the Same Tokens

On Opus 5.5 a cache write costs 25 times a read, and the cache expires after five minutes. Here is what that does to the bill, and what fixed it.

On Opus 5.5, writing a token to the prompt cache costs 25 times as much as reading it back.

When much of our engineering work moved to Claude Code, we did what we always do with a new cost line: we measured it. We ran Claude Code on Opus 5.5 through Terminal-Bench 2.1, 89 command-line tasks, and priced every request at Anthropic’s real rates. The largest line on the bill wasn't the model’s output, and it wasn't the agent reading its logs. It was writing the prompt cache.

That is a strange place for money to go, because the cache exists to save money. This piece explains why it happens and what we changed in OptScale Kompressor, an open-source proxy that runs locally between Claude Code and Anthropic, to stop it.

How Claude Code uses the cache

Claude Code re-sends the whole conversation on every request and marks it with explicit cache breakpoints. So almost every request is a long prefix the provider has already seen, plus a short new tail. In our runs, 92–95% of billed prompt tokens were cache reads.

Reads are cheap: on Opus 5.5, a cached token costs $0.20 per million, a twentieth of the normal input price. Writes are not. Putting a token into the default five-minute cache costs $5 per million, 25 times a read, and a one-hour entry costs $8.

Where the money leaks

A cache entry lives five minutes. That is plenty while the agent thinks and edits, but not while it waits on a tool. A full build, a training run or a long simulation often runs past that, and by the time the agent returns, the cached prefix is gone, and the next request writes the whole conversation to the cache again at the write price.

Without compression, this happened 33 times in an 89-task run and re-wrote 927K tokens, a third of everything billed at full price.

The cache expires five minutes after its last use. A ping at 4.5 minutes reads it and restarts the clock.

Why more compression doesn’t fix it

The obvious move for a compressor is to remove more text. On Claude Code that backfires: rewriting even one byte inside the cached prefix invalidates it, and the next request pays the write price for everything after the change. Until this release, Kompressor left Claude Code uncompressed for exactly that reason.

Get Nick Hystax’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The safe place to compress is the tail the provider hasn’t cached yet. Kompressor now touches only that part, the first time it is sent, and skips any cut under 4,000 characters. If the model asks for a removed piece back, that retrieval round re-sends the large prefix, so a small cut would cost more than it saved. Function bodies are left alone on this provider too. On Claude Code, compression removes only 5–8% of the tail, and that is by design.

The cached prefix stays byte-identical. Only the new tail is compressed.

Keeping the cache warm

The bigger lever is not letting the cache expire. While the agent runs a tool, Kompressor re-sends the last request every 4.5 minutes with max_tokens: 1. The provider reads the cached prefix at the read price, and that read restarts the five-minute clock. Pinging stops when the agent sends its next request, after 11 pings (about 50 minutes), when a ping fails, or as soon as a ping finds nothing cached.

After a conversation’s first idle gap longer than five minutes, Kompressor also switches it to one-hour cache entries. Using them all the time cost more in our replay of earlier runs, so the switch happens only when the pauses show up. Every one of these decisions is priced on Anthropic’s per-model rates.

What it did to the bill

On the same 89 tasks, the Anthropic API bill dropped from $35.35 to $28.30 per run (20%), and tasks solved rose from 89.9% to 90.6%. Prompt tokens lost to cache expiry fell from 927K to 13K per run. The pings added about 2% to the bill and avoided rewrites worth about 13%. On the 14 tasks that wait on long-running tools, cost fell 34%.

Where the 20% came from. Cache writes account for about 15 of the 20 points.

Reading the numbers honestly

No agent solves a task the same way twice, and in this run four tasks produced the whole net difference. On three of them, the uncompressed agent simply took a much longer route. So the 20% is what we measured, and we expect to repeat about 11% from keeping the cache warm, plus a few percent from compressing the tail.

Try it

Kompressor is one Rust binary under the MIT license. It runs on your own machine as a local proxy, and requests go from there to Anthropic with your own API key or Claude login. The packaged config already turns on tail-only compression and the adaptive one-hour cache for Claude Code. Keep-warm is off until you turn it on, because it is the only request the proxy sends that no client asked for:

[proxy.providers.anthropic]
 cache_keep_warm = true

Then start Claude Code through it:

kompressor wrap claude

Code and README: https://github.com/hystax/optscale-kompressor

The full write-up, with the cost breakdown: https://optscale.ai/blog/claude-code-prompt-caching

Disclosure: I work at Hystax, which builds OptScale AI and the open-source Kompressor discussed here, so I think about this professionally — and, yes, with some bias. I’ve tried to keep this piece focused on the problem: what the prompt cache really costs on Claude Code. The tool is the worked example, and I also show which part of the saving we expect to repeat and which part came from agents taking shorter paths.