Amazon Bedrock now surfaces its Mantle endpoint's tokens-per-minute quotas in the standard AWS Service Quotas console. You can read the per-model input-tokens-per-minute and output-tokens-per-minute limits directly, and request increases through the same workflow you already use for everything else in AWS. That sounds like a small console change. For anyone running multi-agent systems in production, it is the difference between planning your capacity and discovering it as a wall of 429s.

The useful reframing is this: for agentic workloads, tokens per minute, not requests per minute, is your real scaling limit. Most teams do not internalise that until an agent fleet that worked fine in a demo starts getting throttled under real traffic. Now that the number is visible, the job is to treat it like a capacity plan instead of a surprise.

What Mantle is, quickly

The Bedrock Mantle endpoint (bedrock-mantle) is the one that gives you the OpenAI Responses API, the OpenAI Chat Completions API, and the Anthropic Messages API on Bedrock, with minimal changes to code written against those native APIs. It is what lets you point an existing OpenAI- or Anthropic-shaped agent at Bedrock without rewriting your call sites. The quota change means each model behind that endpoint now reports its input and output TPM limits as first-class Service Quotas entries.

Why TPM is the ceiling for agents, not RPM

A traditional API-backed app spends tokens roughly in proportion to the number of users. One request, one response, predictable size. Request-per-minute limits are the thing you watch.

Agentic systems break that proportionality. A single user task fans out: a planner agent decomposes it, spawns sub-agents, each sub-agent makes several tool calls, each call carries the system prompt, the accumulated context, the tool schemas, and the model's reasoning back out again. The token cost of one user-visible task is not one prompt and one completion. It is dozens of them, and the context tends to grow at each hop.

So your token spend scales with agents times steps times context size, not with users. You can be nowhere near any request-rate limit and still blow straight through your tokens-per-minute ceiling, because each request is large and there are many of them per task. That is precisely why the per-model TPM number is the one to watch, and why having it in Service Quotas matters.

The failure mode, in order

When you cross the TPM line, Bedrock returns a ThrottlingException (an HTTP 429). On its own that is fine. The problem is what a multi-agent system does next:

  • The throttled call retries with backoff. So do the other agents that hit the same per-model quota in the same minute.
  • Retries are themselves token spend against the same ceiling, so a fleet under load can keep itself throttled.
  • Latency climbs as calls queue behind backoff timers. A task that took eight seconds now takes forty, or times out.
  • Partial failures leave agents in inconsistent states: the planner thinks a sub-task ran, the sub-agent never got a token of output.

None of this shows up in a single-user dev environment, because one developer never generates enough tokens per minute to trip the limit. It shows up the first time real concurrency arrives, which is the worst possible time to learn your ceiling.

Model your token budget before you ship

The math is not hard, and it is worth doing on paper before it is done by an incident. For a given model, estimate:

tokens_per_minute =
    concurrent_tasks
  × agents_per_task
  × model_calls_per_agent
  × avg_tokens_per_call        # input + output
  × (1 / task_duration_minutes)

Then compare input and output separately against the input-TPM and output-TPM quotas you can now read, because they are governed independently and agentic output (reasoning, long tool arguments) is easy to underestimate. If your projected number sits anywhere above roughly 70 percent of the quota at expected peak, you do not have headroom, you have a future incident with a date on it.

Watch it, do not assume it

You can list the quotas straight from the CLI rather than clicking through the console:

aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'tokens per minute')].[QuotaName,Value]" \
  --output table

Pair that with the Bedrock usage metrics in CloudWatch and set an alarm at 70 to 80 percent of each model's TPM. The goal is to find out you are approaching the ceiling from a dashboard, on a Tuesday, not from your users on a Friday night.

Mitigations that are not "ask for more quota"

Requesting an increase is the obvious lever, and sometimes the right one. But raising the number does not fix an architecture that spends tokens carelessly. Before you file the ticket:

  • Trim the context. The biggest agentic token sink is dragging the full history and every tool schema into every hop. Pass only what the step needs.
  • Cache prompts. Stable system prompts and tool definitions are the same tokens on every call. Prompt caching takes them off the meter.
  • Cap concurrency and queue. A bounded worker pool in front of the model turns a token spike into a slightly slower but surviving system, instead of a throttling storm.
  • Route by difficulty. Not every step needs the frontier model. Send the cheap, mechanical steps to a smaller, cheaper model and reserve the expensive one for reasoning that earns it.
  • Separate input and output discipline. Long outputs are billed and throttled on their own quota. Constrain max output tokens per step so a runaway generation cannot eat your output TPM alone.

When you do request an increase

Open the request in Service Quotas against the specific model's input or output TPM entry, and bring the budget math above. AWS approves increases faster when you can show projected peak load and the per-task token breakdown, rather than a round number plucked from optimism. Treat it as a capacity request, because that is what it is.

The takeaway

Surfacing Mantle's token quotas in Service Quotas is necessary, not sufficient. The number being visible does not protect you. It just means you no longer have an excuse for being surprised by it. For agentic systems, tokens per minute is the load-bearing limit, and the teams that ship reliable agents are the ones who model that budget, monitor it, and design their token spend down before they ever ask AWS to raise the ceiling.

Read this next

For the infrastructure and platform side of running this safely at scale, the cloud field notes live at ercan.cloud, including multi-party approval for the high-risk operations agents should never run alone. For consulting on AWS, AI, and platform work, or just to say hello, start at ercanermis.com.