Amazon Bedrock has two inference endpoints, and they meter traffic differently. The legacy bedrock-runtime endpoint (InvokeModel and Converse) counts input and output tokens together against one per-model quota. The current bedrock-mantle endpoint — the one serving the Anthropic Messages API that the AnthropicBedrockMantle client talks to — tracks two separate quotas per model: "Bedrock Mantle input tokens per minute" and "Bedrock Mantle output tokens per minute." There are no requests-per-minute quotas on that endpoint at all, and the two endpoints' quotas are tracked separately even for the same model.
Admission control: pay first, refund later
The part that surprises teams is when the input quota is charged. Bedrock Mantle uses admission control: at the moment your request arrives, the service reserves your actual input tokens plus your full max_tokens value (or the model maximum, if you didn't set one) against the input-TPM quota. If that reservation would exceed the quota, the request is rejected with a 429 immediately — before any output is produced. Output tokens are then counted against the separate output-TPM quota as they are generated, and whatever part of the reservation you didn't use is replenished after the request completes.
The practical consequence: a single large pending request can hold a huge slice of your per-minute budget hostage. Suppose your input quota is 2,000,000 tokens per minute. A request with 300,000 tokens of context and max_tokens set to 128,000 reserves 428,000 tokens the instant it is admitted — over a fifth of the minute's budget — even if the model ultimately writes a two-sentence answer. Five such requests in flight and the sixth gets a 429, with the model idle.
max_tokens to what you actually expect the response to need, not to the model maximum "just in case." Every unused token in that field is quota you temporarily can't spend elsewhere.What does and doesn't count
One helpful carve-out: input tokens served from the prompt cache do not count against the Mantle input-TPM quota. If your workload reuses a large shared prefix — a long system prompt, a stable document set — prompt caching doesn't just cut your bill, it multiplies your effective throughput under the same quota. Only uncached input plus the max_tokens reservation is charged at admission.
Monitoring is also endpoint-specific. Mantle traffic reports to its own CloudWatch namespace, AWS/BedrockMantle, so dashboards and alarms built on the classic AWS/Bedrock namespace will show nothing for this traffic. And AWS cautions that its estimated-quota-usage metric does not reflect the reservation-based accounting that actually drives throttling, so don't use a metric alone to predict when 429s will start.
How big is the quota, and how do you raise it?
Here the official sources diverge, so treat exact numbers cautiously. Anthropic's documentation states a default of 2 million input tokens per minute for Claude in Amazon Bedrock, expandable to 4 million without additional Anthropic approval, with AWS enforcing request-rate limits on its side. AWS's own Bedrock Mantle quota table, meanwhile, publishes a default of 20 million input TPM and 4 million output TPM for Claude Opus 4.7, with no published per-account figures yet for other models on that endpoint. Check your own account's live values rather than relying on either figure.
The increase process is different from what AWS veterans expect: Bedrock Mantle quota increases are not processed through the Service Quotas console. You submit an AWS Support limit-increase case specifying the endpoint, region, model, and quota name. (Adjustable bedrock-runtime quotas still go through Service Quotas as usual.)
Designing around the reservation
Three habits keep admission-control 429s rare. First, right-size max_tokens per call type — a classification call doesn't need six figures. Second, cap concurrency so that (uncached input + max_tokens) × in-flight requests stays comfortably under your input-TPM quota; the reservation model makes this arithmetic exact, which is actually a gift for capacity planning. Third, lean on prompt caching for shared context, since cache reads are quota-free on this endpoint. When a 429 does arrive, back off and retry — the reservation from completed requests replenishes continuously.
Where to go next
For the general shape of Bedrock quotas, see Bedrock quota types explained and how to request a quota increase. For how the first-party API meters the same traffic differently, read rate-limit headers on the Claude API.