Prompt caching lets Claude reuse a stored copy of a repeated prompt prefix — a long system prompt, a tool catalog, a reference document — instead of reprocessing it on every request. Everyone knows the billing benefit: cache reads are priced at roughly a tenth of normal input tokens. Less widely known is the quota benefit. AWS documents that on the bedrock-mantle endpoint (the current "Claude in Amazon Bedrock" surface), cached input tokens read via prompt caching do not count against the mantle input tokens-per-minute quota.
The consequence is that your nominal input-TPM figure understates real throughput for any cache-friendly workload. If most of each prompt is a shared prefix served from cache, only the uncached remainder draws down quota. The same allocation that supports N requests per minute with cold prompts can support a multiple of that once the cache is warm.
What counts, what doesn't
| Token type | Counts against input TPM? |
|---|---|
| Regular (uncached) input tokens | Yes |
| Cache-write tokens (creating a cache entry) | Yes — AWS's CloudWatch documentation states cache-write tokens count toward the TPM quota |
| Cache-read tokens (serving from cache) | No — excluded from the input-TPM counter |
Note the asymmetry: writing to the cache still costs quota (and is billed at a premium — 1.25x input price for the 5-minute duration, 2x for the 1-hour duration). The exemption applies only to reads. So the first request that establishes the cache pays full quota freight; every subsequent hit inside the cache's lifetime rides free on the input meter. Output tokens are unaffected either way — they draw from the mantle endpoint's separate output-TPM quota as usual.
A worked example
Take a support assistant whose every request carries a 40,000-token knowledge-base prefix plus about 1,000 tokens of user-specific content. Cold, each request consumes ~41,000 input-quota tokens. With the prefix cached, each request consumes ~1,000. At a steady cache-hit state, the same input-TPM allocation admits roughly forty times the request rate — no quota increase filed, no architecture change beyond adding cache breakpoints. The total tokens Claude processes per minute can therefore vastly exceed the number printed next to your quota in the console.
This interacts helpfully with the mantle endpoint's reservation-based admission control, which reserves input tokens plus your full max_tokens upfront when a request is admitted. A high cache-hit rate shrinks the input side of every reservation, letting more requests be in flight simultaneously under the same quota.
The same idea exists on the first-party API
This isn't a Bedrock quirk so much as a design Anthropic applies broadly. On the first-party Claude API, rate-limit documentation describes cache-aware ITPM: cache_read_input_tokens don't count toward the input-token limit for most models, and Anthropic gives the example that a 2M ITPM limit with an 80% cache hit rate effectively processes 10M input tokens per minute. Microsoft Foundry's ITPM accounting likewise excludes cache reads. If you're comparing platforms for a cache-heavy workload, compare effective throughput after cache exemptions, not the headline quota numbers — and remember those numbers change frequently; the pages linked below carry the current values.
Verifying it in your metrics
You can watch the split directly. AWS's CloudWatch metrics for Bedrock include CacheReadInputTokens — documented as charged at a reduced rate and not counting toward your TPM quota — alongside CacheWriteInputTokens, which does count. Tracking the ratio between them tells you both your hit rate and how much effective quota headroom caching is buying you. Keep in mind that mantle traffic reports to its own AWS/BedrockMantle CloudWatch namespace, separate from legacy runtime traffic.
Where to go next
For cache mechanics and pricing multipliers, see how prompt caching works and cache reads vs writes. For the broader quota picture on this endpoint, start with Bedrock's two quota pools.