Amazon Bedrock serves Claude through two different inference endpoints. The newer bedrock-mantle endpoint carries the current "Claude in Amazon Bedrock" surface — the Anthropic Messages API at https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages, called with the AnthropicBedrockMantle SDK client. The older bedrock-runtime endpoint carries the legacy InvokeModel and Converse APIs. AWS documents that each endpoint has its own per-model quota allocations, and traffic to the two is tracked against separate quotas even for the same model.
That one sentence is the whole trap. An organization that migrates some workloads to the new Messages API surface while others still call Converse now has two independent capacity ledgers for what looks, from the application's point of view, like "Claude Opus on Bedrock."
Two endpoints, two accounting systems
The separation goes deeper than just having two pools. The two endpoints don't even measure consumption the same way.
| bedrock-runtime (legacy) | bedrock-mantle (current) | |
|---|---|---|
| API surface | InvokeModel, Converse | Anthropic Messages API (plus OpenAI-compatible APIs) |
| Token quotas | One TPM quota per model counting input + output together, plus a tokens-per-day quota | Separate input-TPM and output-TPM quotas per model |
| Request quotas | Model-specific RPM quotas (some models, e.g. Opus 4.7/4.8, have none and are governed by tokens only) | No RPM quotas enforced |
| Increase path | Adjustable quotas via the Service Quotas console | AWS Support limit-increase case (not Service Quotas) |
| CloudWatch namespace | AWS/Bedrock | AWS/BedrockMantle |
The CloudWatch row matters for the same reason the quota rows do: dashboards and alarms built on the AWS/Bedrock namespace simply will not see bedrock-mantle traffic. A team watching its familiar Bedrock dashboard can conclude it has plenty of headroom while the mantle endpoint is throttling — the consumption is being recorded somewhere else. See the separate CloudWatch namespace for mantle for the monitoring side of this split.
What this means when you ask for more capacity
A quota increase is scoped to one endpoint, one region, one model, one quota name. Raising "On-demand InvokeModel tokens per minute" for a model does nothing for Messages API calls to the same model through bedrock-mantle, and vice versa. The request processes even go through different doors: adjustable bedrock-runtime quotas are raised through the Service Quotas console, while bedrock-mantle increases are submitted as an AWS Support case specifying the endpoint, region, model, and quota name.
AnthropicBedrockMantle (or the plain Anthropic client pointed at the mantle base URL) consumes mantle quota; AnthropicBedrock, boto3 invoke_model, and Converse consume bedrock-runtime quota. Ask for headroom where the traffic actually lands.AWS also notes that quota increases are not granted for models in Legacy or Deprecated lifecycle status, and that priority goes to accounts whose traffic already consumes their existing allocation — so a speculative "raise everything everywhere" request tends to fare worse than a targeted one backed by real usage.
The numbers, and why you shouldn't memorize them
At the time of writing, the published defaults illustrate how differently the two pools are sized. AWS's bedrock-mantle quota table lists Claude Opus 4.7 at 20,000,000 input TPM and 4,000,000 output TPM by default, with no published per-account TPM figures yet for other models on that endpoint. Anthropic's own documentation, meanwhile, states a default of 2 million input TPM for Claude in Amazon Bedrock, expandable to 4 million without additional Anthropic approval, with AWS enforcing RPM on the Bedrock side. The two officially published figures do not obviously reconcile, and both pages carry them today — a good reminder that quota numbers move frequently. Treat every figure here as subject to change and check the live quota pages (linked below) for the values that apply to your account, since actual allocations can also vary per account.
Planning across the split
If you run both surfaces during a migration, plan capacity as two workloads, not one. Forecast the Messages API traffic against mantle's separate input and output TPM pools — where admission control reserves your full max_tokens up front — and forecast legacy traffic against the combined input+output TPM quota on bedrock-runtime. The upside of the split is real, too: a migration can't starve the legacy path, because the new traffic draws from a pool the old traffic never touches.
Where to go next
For the taxonomy of Bedrock quota names, see Bedrock quota types explained; for the mechanics of filing an increase, see requesting a Bedrock quota increase. The platform overview covers how the two Bedrock surfaces differ beyond quotas.