Muse Wonder Rate Limits: 3,000 RPM, 4M TPM, Shared by Your Whole Team

Muse Wonder’s rate limits on the Meta Model API are 3,000 requests per minute and 4,000,000 tokens per minute. Both limits apply per model and per team, not per API key: every key created by your organization draws from the same shared pool. Background responses receive a separate allowance of 600 new submissions per minute. Meta publishes no usage tiers and documents no process for requesting more. When you exceed a limit, the API returns HTTP 429; Meta recommends exponential backoff with jitter starting around 500 ms and honoring Retry-After when it is present.

Try Apidog today

Those constraints determine how you should architect anything that calls muse-wonder-1.0 at scale. This article explains what the limits mean in practice, how a 1M-token context consumes a 4M TPM budget, how to interpret rate-limit headers, how to build and test a retry path, and what to do when 3,000 RPM is not enough. For API fundamentals, start with the Muse Wonder API guide.

The limits

Limit	Value	Scope
Requests per minute	3,000	Per team, per model
Tokens per minute	4,000,000	Per team, per model
Background submissions	600 per minute	Per team, on top of the above
Context window	1,048,576 tokens	Per request
Usage tiers	None published
Limit increases	No documented process

The same 3,000 RPM / 4M TPM figures apply to Muse Spark 1.3. The Contributor variant of Spark is capped lower at 150 RPM and 3M TPM. Each model has its own pool, so heavy Wonder traffic does not starve a Spark lane, and vice versa. Meta’s injected steering context is not counted against TPM and does not appear in usage.

Tokens run out before requests do

With a 4M TPM limit, the request limit is rarely the first constraint for agent workloads:

Workload	Tokens per request	Requests per minute before TPM binds
Short chat turns	3,000	1,333
Document review	50,000	80
Long agent turn with 400K context	400,000	10
Full-window request	1,000,000	4

A small set of agents using large contexts can consume 4M TPM with only a dozen concurrent requests. Cached input still counts toward TPM; prompt caching provides a billing discount, not a rate-limit discount. Reasoning tokens count toward max_output_tokens and your bill, and output tokens also count toward TPM.

Budget TPM by context size, not by request count. An agent that resends a 300K-token conversation every turn sends a 300K-token request each time. Ten such agents stepping once per minute consume three quarters of the team’s allowance.

Plan concurrency from the numbers

Use one capacity equation:

concurrent agents × tokens per turn × turns per minute per agent < 4,000,000

Calculate this for your heaviest lane before deployment.

Agents	Tokens per turn	Turns per minute each	TPM needed	Headroom
4	150,000	2	1,200,000	70%
8	250,000	1	2,000,000	50%
12	300,000	1	3,600,000	10%
20	300,000	1	6,000,000	Over the limit

Leave at least 40% headroom. Agent traffic is bursty, retries can briefly double demand, and every other team member consumes the same pool. A configuration with only 10% theoretical headroom can fail as soon as two agents retry simultaneously.

Two levers reduce demand. First, compaction prevents context growth from becoming unbounded: summarize or remove old tool results after a threshold, as described in the context window guide. Second, stateless encrypted replay on the Responses API lets you control exactly what is resent. Server-managed history with previous_response_id, by contrast, resends everything.

One pool for every key

Meta scopes rate limits per team. Staging, production, and developer-laptop API keys all consume the same 3,000 RPM / 4M TPM pool.

That has two operational consequences. A load test run by one developer can throttle production, so isolate experiments by time or use a separate team when your organization permits it. Also, per-key monitoring cannot show the full picture. Aggregate x-ratelimit-* headers across every caller; otherwise, you may see 429s on a key that appears to be well below its own apparent limit.

Read the headers

Token-based responses include x-ratelimit-* headers. Log them on every call. The important signal is remaining capacity trending toward zero across all callers within a minute—that is your warning to slow down before a 429 occurs. Transcription responses do not include these headers, but Wonder responses do.

When a 429 arrives, Meta’s guidance is specific: use exponential backoff with jitter starting around 500 ms, and wait at least the duration specified by Retry-After when present. A retry loop that ignores Retry-After and retries at a fixed interval extends the throttling period for the entire team.

Build the retry path

import os
import random
import time

from openai import OpenAI, RateLimitError

client = OpenAI(
    base_url="https://api.meta.ai/v1",
    [REDACTED CREDENTIAL],
)

def call(input_text, attempts=6):
    delay = 0.5

    for attempt in range(attempts):
        try:
            return client.responses.create(
                model="muse-wonder-1.0",
                input=input_text,
                reasoning={"effort": "medium"},
                max_output_tokens=4096,
            )
        except RateLimitError as error:
            if attempt == attempts - 1:
                raise RuntimeError("rate limited after retries") from error

            retry_after = error.response.headers.get("Retry-After")
            fallback_delay = delay + random.uniform(0, delay)
            wait = (
                max(float(retry_after), fallback_delay)
                if retry_after
                else fallback_delay
            )

            time.sleep(wait)
            delay = min(delay * 2, 30)

Three design points matter. Cap the backoff so a prolonged outage does not produce a 20-minute sleep. Keep retries idempotent: repeating a Responses API call that creates nothing on your side is safe, but if your agent’s tool calls have side effects, retry the model call rather than the tool. Finally, record retries in traces so you can distinguish a slow model response from a throttled one. The tool-call tracing guide covers what to log.

Use background responses for the long tail

Long-running jobs do not need to hold an open connection. Setting background: true queues the response, returns "status": "queued", and lets you poll GET /v1/responses/{id}?stream=true for lifecycle events.

Background submissions have their own 600-per-minute allowance in addition to the main limits, so moving batch-style work there can free RPM for interactive traffic. Constraints include:

• No stream: true on the POST request.
• A 1 MiB request-body cap.
• Cancellation through POST /v1/responses/{id}/cancel.

When 3,000 RPM is not enough

Meta publishes neither a tier ladder nor a limit-increase form. Your current options are:

• Reduce tokens per request. Prompt caching reduces cost but not TPM consumption. Trimming context reduces both. The context window guide explains how to trim tool results.
• Spread work across models. Muse Spark 1.3 has its own 3,000 RPM / 4M TPM pool at one third of the price. Route work that does not require Wonder’s quality to Spark.
• Use a gateway. Vercel AI Gateway and Cloudflare Workers AI serve meta/muse-wonder-1.0. Whether that provides a separate allowance depends on how the gateway is provisioned, so confirm with the provider before relying on it.
• Queue and smooth traffic. A central token-bucket limiter that knows the team’s full budget will perform better than multiple services independently guessing at capacity.

Test limit handling in Apidog

Do not wait until request 3,001 to discover a retry bug. In Apidog:

1. Build the Responses request with MODEL_API_KEY stored as a secret variable. Add a post-processor that reads x-ratelimit-* headers into environment variables so a scenario can assert that remaining capacity never drops below a chosen floor.
2. Create a mock for /v1/responses with an expectation that returns 429 and Retry-After: 2 when a request includes a test header such as X-Test-Scenario: throttle. Point your client at the mock and verify that it waits at least two seconds and succeeds on the next attempt.
3. Run a performance test that ramps request volume against the mock to confirm your limiter engages before the real API would throttle.
4. Add the scenario to CI with the Apidog CLI so retry changes cannot ship without passing the test.

Download Apidog to set up the mock, assertions, and performance scenario in one project.

Frequently asked questions

Are Muse Wonder rate limits per key or per account?

Per team. Every key in a team shares one 3,000 RPM / 4M TPM pool per model.

Does cached input count toward TPM?

Yes. Caching lowers the price of those tokens, not their weight against the per-minute token limit.

Can I request a higher limit?

Meta’s pricing and rate-limits page currently lists no tiers and no request process. Check the page for changes; new tiers may appear after frontier-model launches.

What status code and headers do I get?

HTTP 429, optionally with Retry-After, plus x-ratelimit-* headers on token-based responses.

Next step

Measure the tokens per request for your heaviest agent turn, multiply by concurrency and turns per minute, then compare the result with 4,000,000. If the number is close to the limit, build the central limiter and mock test now—before the whole team starts sharing the pool with production.