On most Claude models, only uncached input tokens and cache write tokens count toward your input tokens per minute limit. Cache reads do not. A high hit rate therefore raises your effective throughput without a limit increase, and a cold cache can hit the limit even with modest traffic.
What counts
The rate limits documentation lists how the three input fields are treated:
input_tokens, the tokens after the last cache breakpoint: counts.cache_creation_input_tokens, tokens written to the cache: counts.cache_read_input_tokens, tokens read from the cache: does not count for most models.
One older model in the docs does count cache reads toward the limit. The docs mark it with a footnote, so check the footnote for your model.
The arithmetic
The docs give an example: with a 2,000,000 input tokens per minute limit and an 80 percent cache hit rate, you could process about 10,000,000 total input tokens per minute, 2 million uncached plus 8 million read from cache. The docs say limits are estimated at the start of each request and adjusted during it to the actual count.
That is an illustration of the principle. Your own figure depends on your tier and model, which the docs list in tables that change.
Output tokens are separate
Output tokens per minute are evaluated as tokens are generated, counting only the actual tokens produced. Setting a large max_tokens does not hurt your output limit, the docs say. Reasoning tokens are part of output, so a reasoning heavy workload can hit the output limit first.
Practical consequences
- Cold starts hurt twice. After a deploy that changes the prefix, every request writes the cache, and writes count toward the limit. Stagger rollouts of prompt changes.
- Large shared prefixes help most. A long system prompt reused across thousands of requests is cheap in limit terms once cached.
- Shorter cache lifetimes lose throughput. If entries expire between requests, you pay write tokens against the limit again.
- Batch limits are separate. The batch API has its own requests per minute and queue limits.
Monitor it
The docs say the Usage page in the console has an input token rate limit chart that shows hourly maximum uncached input per minute, your limit, and the cache rate. Review it before asking for a higher tier. Raising your hit rate may be cheaper and faster than waiting for a limit increase.
When you do need more
The docs describe a request tier increase flow and suggest including peak input and output tokens per minute and the share of input that is cached when asking on some platforms. Come with numbers.
Quick check
Do cached reads cost anything?
Yes, in dollars at the cache read rate, which is a fraction of the base input price. They simply do not count toward the input token rate limit on most models.
Is the hit rate the only thing that matters for limits?
No. Output and reasoning tokens have their own limit, and request count has another.
Sources
Last reviewed: 19 October 2026.
