Rate limits

The MAG limits how fast each user can send requests. The limits apply to each user, whichever project or key the request is billed to. They are separate from budgets, which limit how much you can spend.

Limit	Value	Meaning
Parallel requests	20	Requests from one user that are in progress at the same time
Requests per minute	120	Requests from one user in a one-minute window

A streaming response counts as one parallel request until it finishes.

Handle a 429 response

A request over either limit returns 429 Too Many Requests. The response includes these headers:

Header	Meaning
retry-after	Seconds to wait. It is the length of the rate-limit window (60), so it is an upper bound. A parallel-request limit usually clears sooner.
rate_limit_type	The limit that was exceeded.
reset_at	Time when the limit resets.

Retry with exponential backoff and jitter. Start at 1 second, double the delay after each failed attempt, cap it at the retry-after value, and add a random amount to each delay so that parallel clients do not retry together. Stop after a fixed number of attempts.

import random, time

def call_with_backoff(send, max_attempts=6):
    delay = 1.0
    for attempt in range(max_attempts):
        response = send()
        if response.status_code != 429:
            return response
        cap = float(response.headers.get("retry-after", 60))
        time.sleep(min(cap, delay) * random.uniform(0.5, 1.0))
        delay *= 2
    raise RuntimeError("Rate limit not cleared after retries")

The OpenAI and Anthropic SDKs retry 429 responses automatically. To change the number of retries, use the max_retries client option.

Reduce parallel requests

Tools that run agents or subagents in parallel can reach the limit of 20 parallel requests.

• Claude Code: Set CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=20. See Claude Code.
• Other tools: Lower the tool's setting for parallel agents, workers, or concurrent requests.

Workloads with many parallel agents

MAG users share the upstream model endpoints, so the limits keep each user's share of bandwidth fair. Higher limits can be granted, but they are not the first answer to a large workload.

If you run a swarm of many agents, first change how the work is scheduled:

• Put the tasks in a message queue.
• Run a fixed pool of LLM workers that take tasks from the queue. Size the pool to stay under your parallel-request limit.
• Retry failed tasks with backoff, as described above.

If a bounded worker pool cannot meet your needs, contact AmSC support to discuss a higher limit and describe the workload.