Two threads went up here within a day of each other asking versions of the same question. One asked whether cache reads count against your usage limit. The other asked why the API bills per token when the same work on a subscription doesn’t. Both got confident answers. Most of them were guesses. So I read the docs, then went through my own session files. TLDR: the API side is documented down to the multiplier, the subscription side isn’t documented at all, and people keep answering questions about the second using facts from the first. What’s documented Prompt caching has published multipliers against the base input price of whatever model you’re on. 5 minute cache write: 1.25x 1 hour cache write: 2x cache read: 0.1x On the rate limits page, for most models, cache reads don’t count toward your input-tokens-per-minute limit. input_tokens counts toward ITPM cache_creation_input_tokens counts toward ITPM cache_read_input_tokens does NOT count (most models) Haiku 3.5 is the documented exception and does count them, though it’s retired now except on Bedrock and Google Cloud. Same page, easy to miss: input_tokens only counts what comes after your last cache breakpoint. Your actual input is cache_read_input_tokens + cache_creation_input_tokens + input_tokens So if you’ve been reading input_tokens out of your own logs as your context size, you’re off by a lot. Numbers below. Rate limits aren’t usage limits Rate limits are an API thing. Per organization, per minute, assigned by usage tier, there to manage capacity. Your Pro or Max limit is a different mechanism. Per account, rolling five hour window plus weekly caps, governs what you get for the fee. “Cache hits aren’t deducted against your rate limit” is a true sentence about the API not the Pro limit, which is what most of the replies got wrong. What isn’t documented Everything I can find that Anthropic publishes about subscription limits: Usage is shared across surfaces. “your usage of all different Claude product surfaces (claude.ai, Claude Code, Claude Desktop) counts towards the same usage limit”. The Claude Code support page says the same for Claude Code specifically. “Max 5x provides 5 times more usage per session than the Pro plan.” No token counts anywhere. Weekly limits “reset at a fixed time each week that is assigned to your account.” A list of what affects consumption: conversation length, which features you use, which model, effort level. Factors, no formula. No subscription doc says how caching counts against your limit. The one place it comes up at all is a tip about keeping CLAUDE.md lean, and that’s about per-token cost, not about how a Pro window is metered. So when someone tells you 100k cached tokens count as 100k, or 10k, or zero against your five hour window, they’re guessing. There’s no published weighting. I’m not complaining about that, just don’t build a mental model on top of a confident reply. What you can measure yourself Claude Code writes a JSONL per session, and every assistant record keeps the four counters separate. bash jq -s ’ map(select(.message.usage) | .message.usage) | (map(.input_tokens)|add) as $i | (map(.cache_creation_input_tokens)|add) as $w | (map(.cache_read_input_tokens)|add) as $r | (map(.output_tokens)|add) as $o | {input:$i, cache_write:$w, cache_read:$r, output:$o, total_input:($i+$w+$r)} ’ ~/.claude/projects//.jsonl 26,472 assistant records on my machine: input 2,866,436 cache_write 190,880,769 cache_read 6,986,483,192 output 29,299,738 total_input 7,180,230,397 Cache reads are 97.3% of my total input. input_tokens , the field named like it means input, is 0.04% of it. Sum that field to estimate your consumption and you’re off by a factor of 2,500. Nothing in the session files records limit consumption. The local stats cache holds token counts per model, no percentage used, no reset time. /status and /usage tell you where you stand right now, but it’s not stored, so once you get cut off there’s no history to go back to. Codex does persist it. Its rollout files carry this: json “rate_limits”: { “limit_id”: “codex”, “primary”: { “used_percent”: 19.0, “window_minutes”: 43200, “resets_at”: 1784973092 }, “plan_type”: “free”, “rate_limit_reached_type”: null } On Codex you can line up used_percent deltas against the token counts from the same window and work out the weighting empirically. On Claude Code you’d have to snapshot /status on a timer yourself. Before anyone does the arithmetic Any dollar figure you get out of these token counts is an API-equivalent estimate. Subscriptions aren’t billed per token. Worth labelling clearly if you build something on this, because people will read an estimate as their bill. Sources, all first party: Cache multipliers: https://platform.claude.com/docs/en/build-with-claude/prompt-caching Cache-aware ITPM and the breakpoint detail: https://platform.claude.com/docs/en/api/rate-limits Limits shared across Claude and Claude Code: https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan Usage shared across surfaces, and what affects consumption: https://support.claude.com/en/articles/11647753-how-do-usage-and-length-limits-work Five hour session window and the weekly reset: https://support.claude.com/en/articles/8325606-what-is-the-pro-plan Max 5x described only relative to Pro: https://support.claude.com/en/articles/11049741-what-is-the-max-plan The CLAUDE.md caching tip: https://support.claude.com/en/articles/14552983-models-usage-and-limits-in-claude-code Has anyone actually snapshotted /status against their own token counts across a full five hour window? That’s the one measurement that would settle the cache question, and I can’t find anyone who’s posted it. submitted by /u/actvt_io
Originally posted by u/actvt_io on r/ClaudeCode