Most rate-limit systems count what you actually used. The bedrock-mantle endpoint — the current "Claude in Amazon Bedrock" surface serving the Anthropic Messages API — does something different at the front door. AWS documents an admission control model: when a request arrives, the endpoint reserves your input tokens plus the full max_tokens value (or the model's maximum, if you didn't set one) against your input tokens-per-minute quota. If the reservation doesn't fit in the remaining quota, the request is rejected with a 429 before any generation happens. During generation, output tokens are counted against the separate output-TPM quota, and after the request completes, the unused portion of the reservation is released back into the pool.
In plain terms: the quota system charges you upfront for the response you might get, then refunds the difference. The refund is real, but for the seconds or minutes a long request is in flight, your quota pool is smaller by the full reserved amount.
Why max_tokens becomes a capacity decision
Suppose a service sets max_tokens to the model maximum "just to be safe," but its responses typically run a few hundred tokens. Every in-flight request is now holding a reservation dozens of times larger than what it will actually consume. Stack up enough concurrent requests and the input-TPM pool is fully reserved — new requests start bouncing with 429s — even though the tokens genuinely being processed are a small fraction of the nominal quota.
This is the opposite of how the first-party Claude API treats the same parameter. Anthropic's rate-limit documentation states that on the Claude API, output-token limits count only actual generated tokens in real time, and max_tokens does not factor into the rate limit at all — so a generous max_tokens is free there. Code migrated from the Claude API to Bedrock's mantle endpoint carries that habit into an environment where it has a real cost.
max_tokens to a realistic ceiling for each workload — generous enough that responses don't truncate, but not the model maximum by reflex. Under admission control, unused headroom in max_tokens is borrowed quota that other requests can't use while yours is running.The throughput math
A rough sizing model: your effective concurrency on mantle is bounded by input TPM ÷ (typical input tokens + max_tokens) per minute of request lifetime, not by tokens actually consumed. Two levers follow directly:
Right-size max_tokens per route. A classification endpoint that returns 50 tokens and a report generator that returns 20,000 should not share one config value. Splitting them can multiply admitted concurrency without any quota increase.
Shorten request lifetime. Reservations are released when generation completes, so anything that reduces time-in-flight (smaller prompts, less thinking-heavy configurations where appropriate) returns reserved quota to the pool faster.
Monitoring the reservation, not just the usage
This accounting also explains a confusing observability gap. AWS publishes an EstimatedTPMQuotaUsage CloudWatch metric that approximates token-quota consumption, but explicitly warns that it does not reflect the reservation-based accounting that actually drives throttling — reserved-but-unused tokens are invisible to it. AWS says not to use it as your sole capacity-planning signal. If your dashboards show comfortable TPM usage while 429s climb, reservations are the likely missing variable. Watch throttle-side signals too, and remember that mantle metrics live in their own CloudWatch namespace, separate from legacy Bedrock traffic.
What softens the blow
Two features interact favorably with admission control. First, cache-read tokens are exempt from the mantle input-TPM quota, so a workload with a high prompt-cache hit rate needs far smaller reservations on the input side than its raw prompt sizes suggest. Second, the unused-reservation refund means the system self-corrects between requests: over-reservation hurts concurrency while requests are in flight, but it never permanently burns quota. Published default quota figures for the endpoint (for example, AWS currently lists a 20M input TPM / 4M output TPM default for Claude Opus 4.7, while Anthropic's docs describe a 2M-input-TPM default expandable to 4M) change frequently and don't fully agree with each other — check the live quota page below for current values rather than planning against numbers in any article, this one included.
Where to go next
Read Bedrock's two quota pools for why mantle and bedrock-runtime never share capacity, and the max_tokens parameter for what the setting does on the API side. For raising the ceiling itself, see requesting a Bedrock quota increase.