How savings are measured

The definition

Input Headroom removed, divided by the non-cache-read input there would otherwise have been, in dollars.

Non-cache-read input is everything bought fresh on a request: uncached tokens plus cache writes, which carry the provider's write premium. Cache reads, the replayed prefix Anthropic bills at 10% of the base input rate, are excluded from both the numerator and the denominator. In the app this is the Input chip on the home screen's history chart; its tooltip reads "Excludes cache reads."

The division is done in dollars rather than token counts because the two sides of a token ratio come from different tokenizers: removals are counted by Headroom's tokenizer, cache reads by the provider's, and the two disagree on the same traffic. On cache-heavy days the provider's cache-read count can exceed our count of the entire forwarded prompt, which would pin a token-based rate at a meaningless 100%. Dollars from a single pricing function stay comparable.

How removals are credited

Each removal is credited at the rate its tokens would actually have billed, not at a flat base rate. Content stripped before it was ever cached is credited at the base input rate. Content that stays absent from a cached prefix on later turns would have billed as cache reads, so those absences are credited at 10%. The haircut is large: on a busy day, summing removals request by request at the base rate gives nearly ten times the credited figure, the cache price ratio showing up in the accounting. We take the haircut because crediting the full amount would mean modeling what every cached request would have contained without compression, which is estimation stacked on estimation.

Why cache reads never enter the number

• The cache discount isn't attributable to anything in the path. Coding agents set their own cache_control breakpoints, so an empty passthrough proxy earns the same discount. Counting it is how tools advertise 85-90% savings while changing almost nothing.
• The cached prefix is untouchable. Cache hits require an exact prefix match, so compressing already-cached content would invalidate the cache and cost more than it saves. Headroom compresses upstream of the cache: what gets cached is the compressed prompt.
• Excluding reads doesn't distort the rate. Savings propagate through the cache mechanically: a prefix that enters a third smaller is read back a third smaller on every hit. The rate measured on non-cache-read input is therefore close to the whole-bill rate, and it's a floor, since the downstream effect inside the cache goes uncredited.

Output savings are labeled estimates

Input compression is measured: the tokens existed, then they didn't. Output shaping can't be measured that way, because the verbose response was never generated. The dashboard reports it separately, as an estimate against a sampled baseline, with the method and a confidence band attached. It never enters the input savings number.

Check it against your own traffic

Headroom exposes the same accounting it charts on a local stats endpoint, and your provider's usage console splits input into cache reads and everything else. Whatever tool you're evaluating, two questions carry over: what's the denominator, and would the money have been spent with nothing in the path?

For a worked example on real traffic, one day scored three ways (15%, 38%, and 87% from the same numbers), read how to present token savings percentages honestly on the blog.