Muse Wonder’s rate limits on the Meta Model API are 3,000 requests per minute and 4,000,000 tokens per minute. Both apply per model and per team, not per API key: every key your organization creates draws from the same pool. Background responses get a separate allowance of 600 new submissions per minute. There are no published usage tiers and no documented way to request more. When you exceed a limit you get HTTP 429, and Meta’s guidance is exponential backoff with jitter starting around 500 ms, honoring Retry-After when present.
Those four facts decide how you architect anything that calls muse-wonder-1.0 at scale. This post covers what the limits mean in practice, how a 1M-token context eats a 4M TPM budget, how to read the headers, how to build and test the retry path, and what to do when 3,000 RPM is not enough. For the API basics, 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 / 4M 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
At 4M tokens per minute, the request limit is rarely the binding one for an agent. Three illustrations:
| 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, 400K context | 400,000 | 10 |
| Full-window request | 1,000,000 | 4 |
A team running a handful of agents with large contexts can hit 4M TPM with a dozen concurrent requests. Cached input still counts toward TPM; the cache discount is a billing discount, not a rate-limit one. Reasoning tokens count toward your max_output_tokens and your bill, and output tokens count toward TPM too.
The practical consequence: budget TPM by context size, not by request count. An agent that resends a 300K-token conversation every turn is a 300K-token request each time, and ten such agents stepping once per minute consume three quarters of the team’s allowance.
Plan concurrency from the numbers
The capacity math is one line: concurrent agents, times tokens per turn, times turns per minute, must stay under 4,000,000. Work it for your heaviest lane before you deploy.
| 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 turns are bursty, a retry storm after a transient error doubles demand for a minute, and anyone else on the team is drawing from the same pool. The third row looks fine on paper and fails in practice the first time two agents retry at once.
Two levers shrink the left side of the equation. Compaction keeps tokens per turn from growing without bound: summarize or drop old tool results once a run passes a threshold, as the context window post describes. And stateless encrypted replay on the Responses API lets you control exactly what you resend, where server-managed history with previous_response_id resends everything.
One pool for every key
Meta scopes limits per team. A key for staging, a key for production and a key for a teammate’s laptop all draw from the same 3,000 / 4M. This has two consequences.
First, a load test from one developer can throttle production. Isolate experiments in time, or in a separate team if your organization allows it. Second, per-key monitoring will not show you the whole picture. Aggregate x-ratelimit-* headers across every caller, or you will see 429s on a key that appears to be well under its limit.
Read the headers
Token-based responses carry x-ratelimit-* headers. Log them on every call. The pattern that matters is remaining capacity trending toward zero across all callers within a minute, which is your signal to slow down before the 429 arrives. Transcription responses do not carry these headers; Wonder’s do.
When a 429 does arrive, Meta’s docs are specific: back off exponentially with jitter starting around 500 ms, and if Retry-After is present, wait at least that long. A retry loop that ignores Retry-After and hammers at a fixed interval makes the outage longer for everyone on your team.
Build the retry path
import random, 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 i 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 e:
retry_after = e.response.headers.get("retry-after")
wait = float(retry_after) if retry_after else delay + random.uniform(0, delay)
time.sleep(wait)
delay = min(delay * 2, 30)
raise RuntimeError("rate limited after retries")
Three design points. Cap the backoff so a long outage does not turn into a 20-minute sleep. Keep retries idempotent: a Responses call that creates nothing on your side is safe to repeat, but if your agent’s tool calls have side effects, retry the model call, not the tool. And surface retries in your traces so you can tell a slow model from a throttled one; the tool-call tracing guide covers what to log.
Use background responses for the long tail
Long jobs do not need 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 their own 600-per-minute allowance in addition to the main limits, so moving batch-style work there frees RPM for interactive traffic. Constraints: no stream: true on the POST, a 1 MiB body cap, and you cancel with POST /v1/responses/{id}/cancel.
When 3,000 RPM is not enough
Meta publishes no tier ladder and no form for raising limits. Your options today:
- Reduce tokens per request. Prompt caching cuts your bill but not your TPM; trimming context does both. The context window post covers trimming tool results.
- Spread across models. Spark 1.3 has its own 3,000 / 4M pool at a third of the price. Route the work that does not need Wonder’s quality there.
- Use a gateway. Vercel AI Gateway and Cloudflare Workers AI serve
meta/muse-wonder-1.0. Whether that gives you a separate allowance depends on how the gateway is provisioned; check with them before relying on it. - Queue and smooth. A token-bucket limiter in front of the API that knows the team’s whole budget will out-perform six services each guessing.
Test the limit handling in Apidog
Do not discover your retry bugs at 3,001 requests. In Apidog:
- Build the Responses request with
MODEL_API_KEYas a secret variable, and add a post-processor that reads thex-ratelimit-*headers into environment variables so a scenario can assert remaining capacity never drops below a floor. - Create a mock of
/v1/responseswith a mock expectation that returns 429 and aRetry-After: 2header when a request carries a header such asX-Test-Scenario: throttle. Point your client at the mock and assert that it waits at least two seconds and succeeds on the next attempt. - Run a performance test that ramps request volume against the mock to confirm your limiter engages before the API would.
- Put the scenario in CI with the Apidog CLI so a change to the retry code cannot ship without passing it.
Download Apidog to set up the mock and the assertions in one project.
Frequently asked questions
Are Muse Wonder rate limits per key or per account? Per team. All keys in a team share 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 lists no tiers and no process. Check the page for changes; frontier launches often add tiers within weeks.
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 of your heaviest agent turn, multiply by concurrency, and compare it with 4,000,000. If the answer is close, build the limiter and the mock test this week, before the team shares the pool with production.
