FAQ
How Many Tokens Is 1% of Your Claude Code Limit? (FAQ)
Claude Code shows you a percentage of your 5-hour and weekly limits used. It doesn't tell you how many tokens that percentage represents, and it doesn't say how different kinds of tokens are weighted. A developer measured it on their own account and published the results. Here are the answers — with the caveats that actually matter.
Figure: Editorial context image from the source page (preview only; rights remain with the publisher) · Credit / further reading: dev.to
Quick answer: in a measured Claude Code account, 1% of the 5-hour limit was about 166,000 new (uncached) tokens, or about 11 million cached tokens. A cached token counted roughly 1/67 as much as a new one.
1. How many tokens is 1% of your Claude Code 5-hour limit?
About 166,000 new tokens — or about 11 million cached tokens — on the account where this was measured.
Those are two ends of the same percentage point, not two different measurements. A single "1%" tick of the usage meter corresponds to a certain amount of weighted budget, and how many raw tokens that is depends entirely on what kind of tokens you're sending. If everything were fresh input, 1% would be roughly 166k tokens. If everything were cache reads, 1% would be roughly 11M tokens.
2. Why does one percentage point have two completely different token values?
Because cache reads are weighted at roughly 1/67 of a new token.
The limit meter isn't counting raw tokens — it's counting cost-weighted tokens. Every token passes through a weighting, and cache hits are weighted far below fresh input. That's why the same slice of budget can absorb 166k new tokens or 11M cached ones: the cached ones cost almost nothing each.
Figure: HEXOPS original illustration inspired by the topic (not a copy of the source article imagery) · Credit / further reading: dev.to
3. What exactly is the cached-to-new ratio?
Roughly 1:67 — about 100 cached tokens equals 1.5 new tokens.
You can verify it straight from the headline numbers: 11,000,000 ÷ 166,000 ≈ 66.3. Treat 67 as a working approximation, not a documented constant. It came from one account over a two-day window, and Anthropic doesn't publish the weighting.
4. So what does 100% of the 5-hour limit equal?
Roughly 16.6 million new tokens, or roughly 1.1 billion cached tokens — as theoretical extremes.
Multiply the 1% figure by 100. In practice you'll never see either extreme, because real sessions mix fresh input, cache reads, cache writes, and output. The 100% figure is useful mainly as a sanity anchor: it tells you the order of magnitude of a full 5-hour window.
5. Why does the ratio matter more than the raw token counts?
Because nearly all your tokens are cached, and nearly all your cost is new tokens.
On the measured account, new tokens were only 2.5% of everything Claude Code sent — but they consumed about 63% of the limit. That inversion is the whole story.
Work the arithmetic yourself. Take 100 tokens of traffic at that mix: 2.5 new, 97.5 cached. Weighted cost = 2.5 × 1 + 97.5 × (1/67) ≈ 2.5 + 1.46 = 3.96 new-token equivalents. New tokens are 2.5 ÷ 3.96 ≈ 63% of the bill. The measurement and the ratio confirm each other.
A useful corollary: at that traffic mix, 1% of the limit is about 4.2 million total tokens sent (166,000 × 25.3), not 166,000. Raw token counters badly mislead you about where your budget goes.
6. Is 166,000 tokens a lot?
It's roughly a medium-sized source tree's worth of text — meaningful, but not enormous for a full 5-hour window.
As a gut check, 166k tokens is on the order of a few hundred source files. That's why people are surprised: a long agentic session that burns 20% of a window has effectively re-read a small repository's worth of fresh content, even if it moved tens of millions of tokens total.
7. What should I actually optimize, given this?
Reduce new tokens. Cache hits are already nearly free.
Practical levers, roughly in order of impact:
- Stop re-sending context. Re-pasting files, logs, or diffs you already shared is pure new-token spend. Reference paths instead.
- Clear between tasks. A stale conversation is re-read and re-processed;
/clearwhen the thread changes. - Read narrowly. Ask for one function or one file rather than "look at the repo." Broad exploration generates large fresh input.
- Keep a stable preamble. Instructions that don't change are the best candidates for cache hits; churning them destroys that.
- Trim tool output. Verbose test logs and full build dumps are fresh tokens on every turn.
- Split long sessions. A single sprawling session accumulates context that gets re-weighted repeatedly.
Note what isn't on this list: worrying about cache reads. At 1/67 weight, 11 million of them cost what 166,000 new ones do.
8. Does 1% mean the same thing on the weekly limit?
No — the weekly limit is a separate budget and wasn't the measured one here.
The 166k / 11M figures come from the 5-hour window. The weekly limit almost certainly resolves to a different tokens-per-percent, and nothing in the source data lets you derive it. If you care about weekly pacing, measure that meter separately using the method in Q10.
9. Why doesn't Anthropic just publish these numbers?
Because they're account-, model-, and policy-dependent, and the percentage is a normalized meter rather than a token count.
Weightings can differ by model and change over time; limits differ by plan tier. A published constant would be wrong for most users within months. The percentage is deliberately an abstraction — accurate as a budget signal, uninformative about composition.
10. How do I measure tokens-per-percent on my own account?
Record the percentage, run a known workload, record it again, and divide by the token counts from your session usage.
A workable procedure:
- Start a session and note the exact percentage shown (it moves in coarse steps, so note fractional detail if visible).
- Run a bounded task — something with a clear start and end.
- Note the new percentage.
- Pull the token breakdown from Claude Code's usage output for that session.
- Divide tokens by the percentage delta. Repeat several times and separate fresh-input runs from cache-heavy runs, because a mixed workload will give you a meaningless average.
Small deltas (1–2%) are noisy. Use runs that move the meter by at least 5 points.
11. How reliable is a single measurement like this?
Directionally reliable, numerically approximate.
Caveats worth carrying: it's one account, two days, one plan tier, and the percentage itself has limited granularity. The 1/67 ratio could shift with model, cache TTL, or a policy change. What's robust is the structural finding — new tokens dominate your limit while being a small share of your traffic — and that finding is durable even if the constants move.
12. What's the one-sentence takeaway?
Your limit is measured in new tokens wearing a percentage costume; cached tokens are almost free, so optimize what you send fresh, not how much you send.
Sources
- Sam Stull, "How Many Tokens Is 1% of Your Claude Code Limit?" — https://dev.to/samstull9007/how-many-tokens-is-1-of-your-claude-code-limit-232n
- Original publication: https://limitcast.dev/blog/tokens-per-percent/
All figures above derive from that source's single-account measurement; the 100%-scaling, the 4.2M total-tokens-per-percent estimate, and the 63% cost-share cross-check are arithmetic performed on those published numbers, not independent measurements.
