Muse Wonder Rate Limits Explained: 3,000 RPM and 4M TPM Shared Quota

Meta Model API's Muse Wonder has an easily overlooked engineering constraint: rate limits are shared per team, per model, not calculated independently per API key. All keys within a team—production, staging, even a test key on a colleague's laptop—draw from the same quota pool.

The specific rate limit values

Muse Wonder's official limits are as follows:

Limit	Value	Scope
Requests/minute	3,000	Per team, per model
Tokens/minute	4,000,000	Per team, per model
Background submissions	600/minute	Per team, outside the limits above
Context window	1,048,576 tokens	Per request

Muse Spark 1.3 uses the same 3,000 RPM and 4M TPM values, but Spark's Contributor variant has lower limits—just 150 RPM and 3M TPM. Each model has its own independent quota pool, so Wonder's high traffic won't crowd out Spark's channel, and vice versa. Meta-injected instruction context isn't counted toward TPM and doesn't appear in the usage field.

How TPM and RPM are calculated is the foundation for all subsequent capacity estimates. RPM (Requests Per Minute) only counts the number of requests reaching the API, regardless of request body size; TPM (Tokens Per Minute) counts the total tokens consumed per request, calculated as input tokens plus output tokens. Input tokens include not only user messages but also system prompts, tool definitions, and the entire conversation history returned in prior Agent turns; output tokens include visible text and reasoning tokens. Meta-injected instruction context isn't counted toward TPM, meaning a portion of fixed overhead is exempted, but user-controllable context is still fully billed. In practice, TPM consumption rate is often far higher than RPM, because a single long-context call can be equivalent to hundreds of short conversations—which is why large-context Agent scenarios must plan capacity by TPM rather than request count.

Tokens run out faster than requests

With 4M TPM, request count limits rarely become the bottleneck for Agent-type applications. Here's a comparison of four representative workloads:

Workload type	Tokens per request	Requests/minute before hitting TPM
Short conversation turn	3,000	1,333
Document review	50,000	80
400K-context Agent long turn	400,000	10
Fully loaded context request	1,000,000	4

When a handful of Agent applications run concurrently with 300K-token contexts, just over a dozen concurrent requests can hit the 4M TPM ceiling. Note especially: cache-hit input still counts toward TPM—the cache discount reduces billing cost, not rate consumption. Reasoning tokens count toward max_output_tokens and billing, and output tokens also consume TPM.

The direct engineering implication is: plan your TPM budget by context size, not request count. An Agent that resends a 300K-token conversation every turn consumes 300K tokens per call. Ten Agents each advancing once per minute already consume three-quarters of the team's quota.

Prompt Caching is the implicit premise of this section, and its boundary with rate limits deserves a separate explanation. The caching mechanism works like this: when a request's system prompt or prefix exactly matches a recent request, the server reuses the already-computed intermediate state, reducing latency and offering a billing discount. But one common misconception needs clarification—a cache hit doesn't mean zero quota consumption. Meta's accounting is that cache-hit input tokens still count fully toward TPM, and the discount only shows up in the final cost. In other words, caching is a way to save money, not a way to save quota. The only thing that truly reduces both billing and rate consumption is reducing per-request context size—for example, summarizing old conversations, discarding stale tool results, or switching to stateless encrypted replay to precisely control what gets resent. Therefore, when planning your TPM budget, you can't treat cache hit rate as deductible headroom.

Concurrent capacity calculation

Capacity estimation can be condensed into a single formula:

Number of concurrent Agents × tokens per turn × turns per minute < 4,000,000

Here's headroom analysis for several typical configurations:

Agent count	Tokens per 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

We recommend keeping at least 40% headroom. Agent turns are inherently uneven, a retry storm after a transient error can double demand within a minute, and anyone else on the team is consuming the same quota pool. The third row looks feasible, but it will fail when two Agents retry simultaneously.

Compression strategies can control per-turn token growth: when a run exceeds a threshold, summarize or discard old tool results. Stateless encrypted replay in the Responses API allows precise control over what gets resent, whereas server-managed history via previous_response_id resends everything.

Hidden risks of a single quota pool

Meta defines limits per team, which means two easily overlooked consequences.

First, a developer's load test can bring down production. Isolate experiments in time, or use a separate team if your organization allows it. Second, monitoring per key won't reflect the global picture. You must collect x-ratelimit-* response headers at every caller and aggregate them, otherwise you'll get 429 errors on a key that appears well below its individual limit.

Reading response headers and retry strategy

Token-based responses return x-ratelimit-* headers, which should be logged on every call. The key pattern is: remaining capacity across all callers approaches zero within the same minute—this is the signal to proactively slow down before 429s arrive. Transcript responses don't include these headers, but Wonder's responses do.

On receiving a 429, Meta's documentation gives clear guidance: implement exponential backoff with random jitter starting at about 500ms, and if a Retry-After header is present, wait at least that long. Ignoring Retry-After or using a fixed-interval retry loop extends the outage for the entire team.

The following Python retry code embodies three key design decisions:

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")
            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: Backoff time needs a cap, so a prolonged outage doesn't turn into a 20-minute pause; retries should stay idempotent—Responses calls themselves are safe to retry, but if Agent tools have side effects, retry the model call rather than the tool call; log retry events in tracing to distinguish slow model responses from rate-limit-induced latency.

Exponential Backoff with Jitter is the most universal retry pattern for rate-limited scenarios, and its core lies in two things. First, backoff time grows exponentially with the number of failures (e.g., 0.5s, 1s, 2s, 4s…), avoiding continued fixed-frequency hammering when the server is already overloaded and giving the quota pool room to recover. Second, add a random amount (jitter) on top of each backoff value, so multiple concurrent callers within the same team stagger their retry moments. Without jitter, multiple Agents might retry synchronously at the same millisecond, creating a new spike that actually prolongs the rate limit duration. The Retry-After response header is the authoritative wait duration from the server, taking priority over locally computed backoff values; ignoring it or using a shorter fixed interval amounts to actively fighting the server's capacity buffer. Capping backoff at around 30 seconds prevents a single rate limit from escalating into minutes—or even 20 minutes—of service unavailability.

Background responses handle long task queues

Long-running tasks don't need to keep a connection open. With background: true, the response enters a queue and the call returns "status": "queued", and lifecycle events can be received via GET /v1/responses/{id}?stream=true.

Background submissions have their own 600/minute quota, separate from the main limits. Migrating batch workloads to that channel frees up RPM for interactive traffic. Limitations to note: you can't use stream: true in the POST request; request body is capped at 1 MiB; cancellation is POST /v1/responses/{id}/cancel.

Background Responses essentially transform the synchronous request/response pattern into an asynchronous task queue pattern. Normal calls require keeping the HTTP connection open until the model finishes generating, while with background: true the POST request immediately returns a response object in "status": "queued" state, and the actual inference proceeds independently on the server. The client then subscribes to lifecycle events via GET /v1/responses/{id}?stream=true and retrieves completion results as needed. The value of this pattern is decoupling submission from waiting: batch tasks can deliver large numbers of tasks at once without occupying interactive connection concurrency, and the separate 600/minute background channel also relieves RPM pressure. On constraints: background submissions can't carry stream: true, request bodies are limited to 1 MiB, and cancellation is done via POST /v1/responses/{id}/cancel.

What to do when 3,000 RPM isn't enough

Meta hasn't published a tiered plan, nor a documented process for raising limits. Currently available options include:

Compress tokens per request. Prompt caching reduces billing but not TPM. Reducing context reduces both.

Distribute load across models. Spark 1.3 has an independent 3,000 RPM and 4M TPM quota pool, at one-third the price. Tasks that don't need Wonder's quality can be routed there.

Use a gateway. Vercel AI Gateway and Cloudflare Workers AI both offer meta/muse-wonder-1.0. Whether you can get independent quota depends on how the gateway is configured—verify it yourself.

For testing, you can build a Responses request in Apidog, add a post-processor to read x-ratelimit-* headers into environment variables, so test scenarios can assert remaining capacity is above a threshold. Create a stub service that simulates /v1/responses, returning 429 with a Retry-After: 2 header when the request contains a specific marker, then multiply that value by your expected concurrency and compare against 4,000,000. If the result approaches the limit, you should complete your rate limiter implementation and simulate tests before your team shares the quota pool with production.

One-line Summary

Muse Wonder's rate limits are shared per team and model; in large-context Agent scenarios, TPM runs out before RPM, so you need to plan capacity by tokens, not request count.

Paragraph Summary

The article systematically breaks down the rate limit mechanism of Muse Wonder in Meta Model API. The core constraint is that 3,000 RPM and 4M TPM are shared per team, per model—all API keys within a team consume the same quota pool, and per-key monitoring can't reflect real usage. For large-context Agent applications, TPM becomes the bottleneck before RPM: at 300K context, just over a dozen concurrent requests can hit the 4M ceiling, and cache-hit input still counts toward TPM—caching only reduces billing, not rate consumption. The article provides a concurrency capacity formula and headroom analysis, recommending at least 40% headroom to handle retry storms. Retries should follow Meta's guidance, with exponential backoff plus random jitter starting at about 500ms, respecting Retry-After, and remaining idempotent. Background responses offer an independent 600/minute quota to isolate batch and interactive traffic. Meta hasn't published tiered plans or a limit-increase process, and countermeasures include compressing context, routing to Spark 1.3's independent quota pool, or accessing via a gateway.