Muse Wonder Rate Limits Explained: A Team-Shared Pool of 3000 RPM and 4M TPM

Muse Wonder's rate limits on the Meta Model API are 3000 RPM and 4M TPM. Both figures are counted per team, per model—not allocated per API key. Every key created within an organization draws from the same pool.

This design means any system calling muse-wonder-1.0 at scale must be architected around team-level quotas, rather than assuming that separate keys imply separate capacity.

The Specific Numbers and What They Mean

Limit	Value	Scope
Requests per minute	3000	Per team, per model
Tokens per minute	4 million	Per team, per model
Background submissions	600/min	Per team, outside the main limits
Context window	1,048,576 tokens	Per request
Usage tiers	Undisclosed	—
Limit increases	No documented process	—

The key insight is hidden in the interaction between the token budget and request shape. When short conversation turns consume only about 1,300 tokens each, the RPM limit (3000) trips before the TPM limit (4M); but once you enter long-context scenarios, the situation flips entirely—an agent turn with a 400K context burns 400,000 tokens per request, so you can only fire 10 requests per minute, and TPM becomes the absolute bottleneck.

Request Shape	Tokens/Request	Max RPM under TPM Limit
Short conversation turn	1,333	3,000
Document review	50,000	80
Long agent turn (400K context)	400,000	10
Full-window request	1,000,000	4

A team running multiple long-context agents may hit the 4M TPM ceiling after only a dozen concurrent requests. Cached input still counts toward TPM—caching is a billing discount, not a rate-limit discount. Reasoning tokens count toward max_output_tokens and billing, and output tokens also count toward TPM.

The practical consequence: budget TPM by context size, not request count. An agent that resends a 300K-token conversation every turn burns 300K tokens per request.

RPM (Requests Per Minute) and TPM (Tokens Per Minute) are the two orthogonal dimensions of model API rate limiting. RPM constrains call frequency, independent of request body size; TPM constrains the total tokens consumed per unit time, regardless of whether those tokens are input or output. Both apply simultaneously, and hitting either ceiling first returns a 429. Tokens are usually counted as the number of units after BPE (Byte Pair Encoding) tokenization, not characters or words, so the same passage of Chinese and English text is not equivalent in token count. Notably, reasoning tokens generated by reasoning models also count toward TPM and billing, even if they never appear in the final reply. Understanding the independence of these two dimensions is the prerequisite for judging which wall your workload will hit first.

TPM Budget Planning under Multi-Agent Concurrency

Number of Agents	Tokens/Turn	Turns per Minute Each	Required TPM	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 limit

Keep at least 40% headroom. Agent turns are bursty, and a retry storm after transient errors can double request volume within a minute while other team members draw from the same pool. The row with 12 agents, 300K context, and 1 turn per minute each looks safe on paper (only 10% headroom), but it fails the moment two agents retry simultaneously.

There are two levers to shrink the left side of the equation. Compression prevents per-turn tokens from growing without bound: once a process crosses a threshold, summarize or discard old tool results. Stateless encrypted replay on the Responses API lets you precisely control what gets resent, whereas server-managed history using previous_response_id resends everything. Which approach you choose directly determines how fast TPM is consumed.

All Keys Share the Same Quota Pool

Meta sets limits per team. The key for pre-release, the key for production, the key on a colleague's laptop—all draw from the same 3000 RPM/4M TPM pool. This has two immediate consequences.

First, a single developer's load test can throttle production. Either isolate experiments in time or use a separate team if your organization allows it. Second, monitoring per key doesn't show the full picture. You need to aggregate the x-ratelimit-* headers across all callers, or you'll see 429s on keys that appear far below the limit.

Reading Response Headers and Building the Retry Path

Token-based responses carry x-ratelimit-* headers. The key pattern is remaining capacity approaching zero within a minute across all callers—that's the signal to slow down before 429s arrive. Transcription responses do not carry these headers; Wonder responses do.

When a 429 arrives, Meta's documentation is specific: use exponential backoff with jitter, starting around 500ms; if a Retry-After header is present, wait at least that long. A retry loop that ignores Retry-After and hammers the API at fixed intervals prolongs the outage for everyone on the team.

import os
import random
import time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api.meta.ai/v1", api_key=os.environ["MODEL_API_KEY"])

def call(input_text, attempts=6):
    delay = 0.5
    for _ 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:
            retry_after = error.response.headers.get("retry-after")
            if retry_after:
                wait = float(retry_after)
            else:
                wait = delay + random.uniform(0, delay)
                delay = min(delay * 2, 30)
            time.sleep(wait)
    raise RuntimeError("rate limited after retries")

Three design points: cap exponential backoff so a long outage doesn't turn into a 20-minute sleep; keep retries idempotent—Responses calls are safe to retry when nothing is produced locally, but if an agent tool call has side effects, retry the model call rather than the tool itself; and expose retries in tracing to distinguish between a slow model and a throttled model.

Exponential Backoff with Jitter is a general retry strategy for handling rate limits and transient failures: the wait time after each failure grows by a multiple (e.g., 500ms, 1s, 2s, 4s), capped to prevent unbounded growth; jitter means adding a random amount to the computed wait time so multiple clients don't all retry at the same instant and trigger a "retry storm." Retry-After is an HTTP standard response header the server uses to explicitly tell the client how many seconds to wait before making the next request; it takes priority over a self-computed backoff value. Retry idempotency requires that the retried operation doesn't produce duplicate side effects—pure model calls are naturally safe to retry, but for tool calls that write files, place orders, or send messages, only the model decision step should be retried, not the tool execution itself.

Using Background Responses for Long-Tail Work

Long tasks don't have to hold a connection. background: true queues the response, returns "status": "queued", and lets you poll GET /v1/responses/{id}?stream=true for lifecycle events. Background submissions have a separate quota of 600 per minute, outside the main limits, so moving batch-style work there frees up RPM for interactive traffic.

The boundaries are clear: stream: true is not supported on POST, the request body is capped at 1 MiB, and cancellation is done via POST /v1/responses/{id}/cancel.

Options When 3000 RPM Isn't Enough

Meta has not published a tier ladder or an increase form. The current viable paths include:

• Reduce tokens per request. Prompt caching lowers billing but not TPM; trimming context lowers both.
• Route to other models. Spark 1.3 has a separate 3000 RPM/4M TPM pool at one-third the price. Work that doesn't need Wonder's quality can be routed there.
• Use a gateway. Vercel AI Gateway and Cloudflare Workers AI offer meta/muse-wonder-1.0. Whether they provide separate quotas depends on how the gateway provisions; confirm with the gateway provider before relying on it.
• Queue and smooth. A token-bucket limiter in front of the API that understands the whole team's budget is far better than six services each guessing.

Prompt Caching is an optimization that reuses the computed results of a fixed prefix repeated across requests (such as system prompts, long documents, few-shot examples) on the server side, eliminating repeated prefill. It lowers latency and the billed price of input tokens, but tokens that hit the cache still occupy TPM quota, because the limiter counts the logical token volume of the request, not the actual compute performed. This also explains why "cached input still counts toward TPM" is an easy pitfall: teams often assume enabling caching will proportionally reduce rate-limit pressure, when in fact only the bill gets cheaper. If the goal is to genuinely lower TPM usage, you must attack the request body itself—trim history, summarize old turns, or use stateless replay to send only the necessary delta.

Testing Rate-Limit Handling in Apidog

Don't discover a bug in your retry code the first time you hit request number 3001. In Apidog:

1. Build a Responses request with MODEL_API_KEY as a secret variable, and add a post-processor to read the x-ratelimit-* headers into environment variables. The scenario can then assert that remaining capacity never drops below a threshold.
2. Create a mock for /v1/responses that is expected to return 429 with a Retry-After: 2 header when the request carries the X-Test-Scenario: throttle header. Point your client at the mock and assert that it waits at least two seconds and succeeds on the next attempt.
3. Run a performance test that ramps up request volume against the mock to confirm the limiter engages ahead of the API.
4. Bring the scenario into CI via the Apidog CLI, so changes to retry code cannot ship without passing.

FAQ

Are Muse Wonder's rate limits per key or per account? Per team. All keys on the same team share a single 3000 RPM/4M TPM pool per model.

Does cached input count toward TPM? Yes. Caching lowers the price of those tokens but not their weight against the per-minute token limit.

Can I request higher limits? Meta's pricing and rate-limit pages list no tiers or process. Check the pages periodically for changes; frontier model launches typically add tiers within a few weeks.

What status codes and headers will I receive? HTTP 429, optionally with Retry-After, plus x-ratelimit-* headers on token-based responses.

Next Steps

Measure the tokens per request of your heaviest agent turns, multiply by the concurrency rate, and compare against 4 million. If the result is already near the ceiling, build the limiter and mock test this week—before the entire team is sharing the same pool with production.

One-line Summary

Muse Wonder shares a 3000 RPM/4M TPM quota per team, and TPM is the main bottleneck under long contexts.

Paragraph Summary

Muse Wonder's rate limits on the Meta Model API are 3000 RPM and 4M TPM per team, per model, and all API keys on the same team share one quota pool, so a single person's load test can throttle production. The article notes that RPM trips first under short requests, while TPM becomes the absolute bottleneck in long-context scenarios—a 400K-token agent turn can only fire 10 times per minute, leaving just 10% headroom with 12 concurrent agents. Cached input still counts toward TPM, and only trimming context lowers both billing and rate-limit pressure. Mitigations include controlling tokens per request, routing to Spark 1.3 with its separate quota, using AI gateways, and deploying a token-bucket limiter. The article also provides a retry code template, the background response mechanism, and a rate-limit testing workflow in Apidog.