Anthropic publishes exact per-token prices for API usage: base input, 5-minute cache write at 1.25x, 1-hour cache write at 2x, cache read at 0.1x, output at 5x. Those numbers are well documented and easy to reason about. Subscription plans work differently. Usage is metered against a rolling 5-hour window and a weekly window, and the unit of those meters is not documented anywhere. No official page states how a cached token weighs against an uncached one inside plan usage. The prompt caching docs explain the API multipliers; the plan pages say only that limits exist and that there is no fixed message count. That gap matters if you are trying to optimise cache usage on a subscription. Whether to use the 1-hour TTL, whether keeping a session warm is worth it, whether long contexts are expensive, all depend on numbers nobody publishes. So I measured them. Everything below is measured through the normal Claude Code CLI. Results Claude Fable 5.1 (Max 5x) Fable has its own model-scoped weekly window on top of the shared ones. It shows up in the response headers as anthropic-ratelimit-unified-7d_oi-utilization , but only on requests to Fable. Percentages are the share of that window consumed per 1M tokens. The 1-hour cache write is the headline: it costs 1.18x uncached input against the subscription meter, not the 2x the API charges. On Fable both TTLs cost the same. Claude Opus 5 (Max 20x) * The 5-minute write measured as free , identical to uncached input, where the API charges a 25% premium. The measurement excludes 1.25. But the same condition on Fable gives 1.18x, and Opus was measured on a Max 20x account while Fable was measured on a Max 5x one, so model and plan tier vary together. I cannot tell whether “5m writes are free” is a property of Opus or of the 20x tier. Treat that row as provisional. Every other row agrees across both accounts. General caveat: the Opus numbers come from a Max 20x account and the Fable numbers from a Max 5x account. The ratios should be tier-independent, but I have not verified that. What holds across both The 1-hour cache write costs about 1.2x, not 2x. That replicates across two models, two plan tiers and two accounts. Cache reads cost about 0.028x on both models, even though the API charges 0.1x on Opus and 0.025x on Fable. The subscription meter appears to use one read discount regardless of model. Output tracks the API ratio on both (4.49 and 5.27 against a list ratio of 5.0). So the subscription meter is not uniformly cheaper than the API. It discounts caching specifically. Fable looks like it costs roughly 3.5x an Opus token against the shared meters, where its API price is only 2x Opus. I am less confident in that one than in the rows above: the Fable side is a clean measurement but the Opus side on the same account was not a dedicated run, so I would call it approximate until I redo it. Method The real Claude Code CLI runs in a container, pointed at a local proxy that forwards every request to api.anthropic.com byte for byte and logs the response headers. Nothing rewrites the request, which matters because the whole question is how cache_control and the TTL beta header affect metering. Token types are isolated with documented CLI controls rather than hand-built requests: DISABLE_PROMPT_CACHING=1 gives pure uncached input CLAUDE_CODE_PROMPT_CACHE_TTL=5m or =1h selects the write TTL re-sending a corpus that is already warm gives pure cache reads a prompt that generates a long deterministic list gives output Payload size is controlled with –append-system-prompt-file carrying generated filler text, which inflates the cacheable prefix without invoking any tool. Each request’s actual token split is read back from –output-format json to confirm the tokens landed in the bucket they were supposed to. The meters come from the anthropic-ratelimit-unified-* response headers. Three properties shape the whole design: Resolution is 1%. Utilization is reported as a fraction rounded to two decimals, so one quantum is one percent of the window. Quantization is the dominant error term in everything above. The meter lags spend by one to two minutes. Reading immediately after a batch reports the state before it. Every measurement waits about 150 seconds first. My first attempt skipped this and concluded the meters were frozen after $20 of spend, which was wrong. Refused requests bill nothing. Several probes were rejected by safety classifiers and the meters did not move, despite the CLI reporting hundreds of thousands of input tokens. Each measurement spends one token type in bulk, waits for the meter to settle, and takes the delta. Roughly 16.9M tokens of Opus and 5.3M of Fable went into the numbers above. Two traps worth mentioning for anyone repeating this. A request that a safety classifier flags gets silently re-run on the fallback model, so a Fable measurement quietly becomes an Opus one unless you set CLAUDE_CODE_NO_MODEL_FALLBACK=1 and CLAUDE_CODE_DISABLE_REFUSAL_FALLBACK=1 . And a large block of repetitive generated filler reads as an attack payload: six identical 123k corpora were refused while a 114k one passed, which looked like a size limit but was actually repetition. Varying the generated records fixed it. submitted by /u/flobernd
Originally posted by u/flobernd on r/ClaudeCode