Originally published at limitcast.dev.
Anthropic shows how much of your 5-hour and weekly limit you've used, as a percentage. It doesn't say how many tokens that percentage is, and it doesn't say how different kinds of tokens count. So I measured it on my own account.
1% of the 5-hour limit was about 166,000 new tokens, or about 11 million cached tokens. A cached token counted roughly 1/67 as much as a new one.
That ratio changes what's worth optimizing. Over the two days I measured, new tokens were 2.5% of everything Claude Code sent, and they used about 63% of my limit.
| Share of tokens | Share of the limit they used (estimated) | |
|---|---|---|
| New tokens (input, cache writes, output) | 2.5% | ≈ 63% |
| Cached tokens (cache reads) | 97.5% | ≈ 37% |
My Claude Code usage, 23–25 October 2026: 53.7M new tokens and 2,103.5M cached tokens. The limit share applies the fit below to those totals.
How I measured it
Claude Code passes your limit readings to the status line: percent used of each window and when it resets. Its transcripts record every model call's tokens: input, cache writes, cache reads and output. Put the two side by side and you can see how many tokens it took to move the meter.
Each time the 5-hour reading rose between two status-line updates, I took the rise and the tokens my sessions on that account used in between, split into new tokens (input, cache writes and output) and cached tokens (cache reads). Then a least-squares fit with no intercept:
rise in % ≈ a × new tokens + b × cached tokens
With 61 such observations, the fit gave:
| % of the 5-hour limit per million | Tokens per 1% | |
|---|---|---|
| New tokens | 6.04% | ≈ 166k |
| Cached tokens | 0.090% | ≈ 11.2M |
A fit on the previous day's readings gave about 200k and 10.7M, so treat these as a range rather than constants: roughly 165–200k new tokens, or 10.7–11.2M cached tokens, per 1%.
What it means in practice
Subagents are expensive. Each subagent starts its own context and writes it into the cache from scratch. Subagents sent about a third of my tokens (33%), but nearly half of my new tokens (48%), and used an estimated 42% of my limit.
Your starting context is cheap per call, but it adds up. My sessions start at about 100k tokens before I type: system prompt, tools, MCP servers, skills, CLAUDE.md. Written once into the cache, that's about 0.6% of the limit. After that, each model call re-reads it from the cache for about 0.009%. A session with 300 model calls spends about 3% of a window re-reading that starting context. Trimming 4k tokens of unused skills and MCP servers from mine saved about 0.3% of a window over 1,100 calls: real, but small.
Cache misses are where it gets expensive. This one is an inference from the ratio rather than something I measured directly: when the prompt cache expires (after a pause, for example), the next call writes the whole context again as new tokens. In a session that has grown to 200k tokens, that single call is more than 1% of the limit.
So the order of what to watch is: how many subagents you start, how long your sessions run between pauses, and only then how big your CLAUDE.md is.
The caveats
- This is one person's account on one plan, over about two days. Your numbers will differ.
- The fit doesn't separate models. If Anthropic weights Opus and Sonnet differently, my mix of the two is baked into these numbers.
- Cache writes are counted as new tokens. They may be weighted differently from input and output.
- The readings are whole percentages, so each observation is noisy. It takes dozens of them before the fit settles.
- Anthropic can change how limits are counted at any time; a measurement like this is a snapshot.
Measure your own
I built this measurement into limitcast, a free command-line tool for Claude Code and Codex. It reads only the files Claude Code already writes on your machine and sends nothing anywhere.
npm install -g limitcast
limitcast install # records your limit readings from the status line
# use Claude Code as normal for a day or two, then:
limitcast results
Once it has about 30 observations, limitcast results prints your own numbers: how many new and cached tokens move your meter by 1%. The fit is in src/calibrate.mjs if you want to check it.
I'd like to hear whether other people's ratios look similar, especially on different plans.
Top comments (2)
That 2.5% versus 63% split genuinely changed how I'll think about my sessions. I'd always assumed the huge cached pile was the thing eating my limit, but if a cached token counts roughly 1/67 as much as a new one, then it's the small sliver of new tokens doing the damage. The subagent point stings too — each one starting its own context and writing it into cache from scratch explains why a session with a few parallel helpers drains so fast. I'm curious about the starting context though: if a session already begins around 100k tokens before you type, does that first chunk count as new tokens every time you resume, or does a good cache hit soften it? That feels like the difference between a session that's cheap to pick back up and one that isn't.
Thanks Paul, good question. It depends on whether the prompt cache is still warm.
If you come back while it is, that starting context is a cache read: about 0.009% of the 5-hour window per call on my numbers. If it has expired, the next call writes the whole context again as new tokens: about 0.6% for 100k. A brand-new session always pays that write once.
Where it really bites is resuming a long conversation after a break. A session that has grown to 300k tokens costs roughly 1.8% of a window on the first call back once the cache has expired. On recent Claude Code versions the cache lasts about an hour, so picking up within the hour is cheap and picking up the next morning isn't. If a big session has gone cold, starting a fresh one with a short summary is often cheaper than resuming it.
I haven't measured resumes directly, so treat those as estimates from the ratio. If you run
limitcast resultsI'd be curious whether your numbers look similar.