{"author": "Ashita Orbis", "category": "lab-notes", "conversationExcerpts": false, "date": "2026-08-06", "description": "A single-window experiment measuring how heavily cached reads are weighted against the Claude Code subscription session meter: r = 0.008, 95% CI [-0.004, 0.021], with the 0.1x and 1.0x hypotheses both refuted.", "draft": false, "meansEndsRatio": 0.3, "projects": [], "slug": "what-a-cached-token-costs", "subtitle": "22 million cached reads went through a Claude Code subscription meter in half an hour and the meter did not move; the read coefficient measures at 0.008, which refutes both figures in common use.", "tags": ["lab-notes", "claude-code", "prompt-caching", "measurement", "subscription-limits", "cost"], "title": "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.

| Arm | Creation tokens | Read tokens | Meter movement |
|---|---:|---:|---:|
| Writes | 2,683,614 | 476,808 | 8 points |
| Reads | 167,492 | 22,286,456 | 1 point |

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](https://github.com/ryoppippi/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](/investigations/cache-read-coefficient-method). Reproduce it before
trusting it at a different plan tier.