The day's numbers
I run Claude Code and Codex through Headroom, a local proxy that compresses prompts before forwarding them (I'm @garmdotcom). Yesterday was an ordinary working Monday on one machine. I'm on a Claude Max subscription, so none of this is metered billing: the dollar figures are API-equivalent costs, computed from token counts at list prices. On a subscription, the same arithmetic surfaces as rate-limit headroom rather than dollars.
The $592 is dominated by prompt caching. About $427 of it was cache reads, which Anthropic bills at 10% of the base input rate. A compressor has to leave the cached prefix alone: cache hits require an exact prefix match, so rewriting already-cached content invalidates the cache and costs more than it saves. The remaining ~$165 was non-cache-read input (uncached tokens plus cache writes), the only slice a compressor can act on.
Three percentages, one day
| What's measured | The arithmetic | Result |
|---|---|---|
| Savings on total input cost | $101 ÷ $693 | 15% |
| Savings on non-cache-read input | $101 ÷ $266 | 38% |
| Cache discount counted as savings | ($3,843 + $101) ÷ ($3,843 + $693) | 87% |
15% is the whole-bill number: total input cost came out 15% lower than it would have. Accurate, but workload-dependent. Cache reads are most of the denominator, so the figure tracks the day's cache hit rate as much as the compressor: a day with long uninterrupted sessions and a high hit rate pushes it down while the compressor's behavior is unchanged.
Although 15% may look like the most accurate savings rate, it isn't the one Headroom displays, and the reason is the cache again. Headroom sits upstream of it, so what gets cached is the compressed prompt, and the savings keep working inside: content removed at turn 12 is also absent from the cached prefix at every later turn, where it would have been billed at the cache-read rate. A correct whole-bill rate would have to credit those downstream absences on every cache read, which means modeling what each cached request would have contained without compression: estimation stacked on estimation. My request logs show the scale of the problem: summed per request at the base input rate, yesterday's removals total $877, of which the accounting admits $101, because each removal is credited at the rate its tokens would actually have billed, and for a replayed token that's 10%.
So Headroom reports 38% instead: input removed, divided by non-cache-read input, with cache reads excluded from both numerator and denominator. It measures where measurement is clean and isolates the variable the tool controls. The omission is tolerable because savings propagate through the cache mechanically: a prefix that enters 38% smaller is read back 38% smaller on every hit, so the measured rate is close to the whole-bill rate anyway, and it's a floor. That's the Input chip on the home screen; the tooltip states "Excludes cache reads."
The distribution behind that ratio: 3,284 requests were compressed, with a median reduction of 20% per request, concentrated in long-context turns where accumulated tool output, file reads, and search results dominate the prompt. Workloads with short prompts have less removable content and will show a lower rate.
87% is what you get by counting the provider's cache discount as savings and dividing by a hypothetical bill with no caching at all. The discount is real money, but it isn't attributable to anything in the path: coding agents set their own cache_control breakpoints, so an empty passthrough proxy produces the same discount. A savings claim in the 85-90% range that doesn't vary by workload is usually this calculation.
Evaluating a savings claim
Two questions resolve most of them. What's the denominator: total input including cache reads, or only the input the tool can affect? And would the money have been spent with nothing in the path?
To compute the number for your own traffic: your provider's usage breakdown separates cache reads from other input tokens. Take what a tool removes and divide by the removal plus the non-cache-read input that remained. That's the chip's formula, and it doesn't require trusting us. Yesterday it came to 38%; with the cache discount counted it would have been 87%. Only the first tells you how much additional work fits under your rate limits.
Related: why long sessions are cheap until sub-agents break the cache, what's eating the weekly limit, and the cost-cutting toolkit.