What a Cached Token Actually Costs

Prompt caching splits tokens into two classes that bill differently, creation and reads, and the subscription plans Claude Code runs on expose a session meter rather than a dollar figure, so the weight a cached read carries against that meter is documented nowhere and cannot be derived from the API price sheet. Three answers circulate: reads count at full weight, reads count at the API's discounted multiplier, or reads are excluded the way a throughput limiter excludes them. Those predict meter movements two orders of magnitude apart, which makes the question settleable in one evening on one account.

Two arms ran back to back inside a single window, same model and effort, on a fixed payload of 300,000 bytes reused byte for byte across every request. The write arm ran 18 independent sessions, each carrying a random nonce so no cache hit was possible between them, at roughly 164,000 creation tokens per request. The read arm seeded one session and resumed it 120 times with a trivial prompt, at roughly 16 creation tokens and 182,000 read tokens per resume. Every resume was checked against a floor of 100,000 read tokens, so the read arm is genuinely a read arm.

The shape is legible before any arithmetic, in that the meter climbs while creation accumulates and then flatlines while a further 18.6 million read tokens pour through it. Solving the two segments for the weight of a read relative to a write gives r = 0.008, and an independent regression over all 22 meter observations gives 0.003. A bootstrap over the meter's quantisation puts the 95% interval at [-0.004, 0.021], with the probability of r reaching either 0.1 or 1.0 measuring 0.000. Negative values inside that interval are quantisation artefacts rather than a claim that reading earns credit, so the honest reading is that r sits somewhere between zero and about 0.02 and cannot be told apart from zero. A percentage point costs roughly 44 million read tokens at the point estimate and 16 million at the pessimistic bound, against roughly 336,000 creation tokens for that same point.

The single point of movement during the read arm is fully accounted for by that arm's own 167,000 tokens of creation. No residual demands a nonzero r, so the experiment cannot separate a true zero from a true 0.01, and the result is properly an upper bound rather than a value. What it does exclude is both numbers people plan with. The discounted API multiplier is wrong by at least a factor of five and possibly by an unbounded one. Accounting at full weight, the approach the ccusage token limit tracker implements, overcounts reads by something near a factor of 130. The ArkNill proxy study, cited in full in the companion, recorded 1.5 to 2.1 million read tokens per meter point, a drain roughly 9 times faster than even the pessimistic bound here, and its capture window sat inside a period of cache accounting bugs the vendor later acknowledged, which plausibly explains the gap.

By Claude Code's own arithmetic at list rates this run cost $39.91, of which $11.38 was reads. Those reads consumed approximately none of the window, so the dollar figure the tool reports is not a proxy for consumption against the plan limit, and a session that looks expensive by list rate can be nearly free against the limit that actually stops you working.

What drains a window is anything that forces the cache to be rebuilt: model switches and fallbacks, effort changes, a CLI upgrade mid session, subagents fanning out across cold prefixes, worktree isolation, and any gap longer than the cache lifetime. That last one has teeth, because it means an agent architecture is charged for its topology rather than its output, and a fleet of brief subagents on five minute cache lifetimes can cost more window than one long session doing considerably more work.

Every number here comes from one account, one model, one window, one day. The scripts, the ledger of all 140 calls, the meter timeline, and the analysis are in the companion methodology and raw data. Reproduce it before trusting it at a different plan tier.