# ITPM counts uncached tokens: cache to raise your ceiling
Rate limits are measured per model in RPM, ITPM, and OTPM. For most models, what counts toward ITPM is input_tokens plus cache_creation_input_tokens. Tokens served from cache (cache_read_input_tokens) do not count. The documented example: with a 2M ITPM limit and an 80 percent cache hit rate, you can effectively process 10M total input tokens per minute.
## What to do
1. Cache repeated content: system instructions, tool definitions, large context documents, conversation history. Put stable content early so cache breakpoints hit.
2. Note the exception: Claude Haiku 3.5 also counts cache reads toward ITPM. Do not assume the cache discount on every model; check the footnotes for yours.
3. Remember max_tokens does not factor into OTPM calculations. There is no rate-limit downside to setting a higher max_tokens.
4. ITPM is estimated at request start and adjusted during the request to reflect actual input tokens used. Short bursts can still trip the limit even under the per-minute average.
5. Monitor your cache hit rate on the Console Usage page and tune breakpoints until the hit rate climbs.
## The trap
Optimizing RPM while ITPM is the binding constraint, or vice versa. Read the 429 message: it names the exceeded limit, so fix that dimension. The other trap: caching nothing and requesting a limit increase, when a cache breakpoint would have multiplied your effective limit for free.
## Checklist
- When you 429 on ITPM, the first fix is caching, the second fix is spreading across models, the third is a limit increase. In that order.
- Verify the cache discount applies to your model before depending on it in capacity planning.