How many tokens is 1% of your Claude Code limit?

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: input, cache writes, outputcached: cache reads
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 millionTokens per 1%
New tokens6.04%≈ 166k
Cached tokens0.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

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.

limitcast also forecasts when each window runs out, and its Pro plan stops new subagents when a window is about to run out. That's the biggest lever in the data above.

Next: do subagents burn your limit faster? · See what limitcast does