Muse-Wonder-Ratenlimits: 3.000 RPM und 4 Mio. TPM, teamweit geteilt

Die Ratenbegrenzungen von Muse Wonder für die Meta Model API liegen bei 3.000 Anfragen pro Minute und 4.000.000 Token pro Minute. Beide gelten pro Modell und pro Team, nicht pro API-Schlüssel: Jeder Schlüssel, den Ihre Organisation erstellt, greift auf denselben Pool zu. Hintergrundantworten erhalten ein gesondertes Kontingent von 600 neuen Einsendungen pro Minute. Es gibt keine veröffentlichten Nutzungsstufen und keine dokumentierte Möglichkeit, weitere anzufordern. Wenn Sie einen Grenzwert überschreiten, erhalten Sie HTTP 429, und Metas Empfehlung ist exponentielles Backoff mit Jitter ab etwa 500 ms unter Berücksichtigung von Retry-After, falls vorhanden.

Diese vier Fakten entscheiden, wie Sie alles archivieren, was muse-wonder-1.0 im Maßstab aufruft. Dieser Beitrag behandelt, was die Limits in der Praxis bedeuten, wie ein 1M-Token-Kontext ein 4M-TPM-Budget verbraucht, wie Sie die Header lesen, wie Sie den Wiederholungspfad erstellen und testen und was zu tun ist, wenn 3.000 RPM nicht ausreichen. Für die API-Grundlagen beginnen Sie mit der Muse Wonder API-Anleitung.

Die Grenzen

Die gleichen 3.000/4M-Zahlen gelten für Muse Spark 1.3; Die Contributor-Variante von Spark ist auf eine niedrigere Obergrenze von 150 RPM und 3 Mio. TPM begrenzt. Jedes Modell verfügt über einen eigenen Pool, sodass starker Wonder-Verkehr nicht dazu führt, dass eine Spark-Lane ausgehungert wird und umgekehrt. Der injizierte Steuerungskontext von Meta wird nicht auf TPM angerechnet und erscheint nicht in usage.

Die Token gehen vor den Anfragen aus

Bei 4M Token pro Minute ist das Anfragelimit für einen Agenten selten das bindende. Drei Illustrationen:

Ein Team, das eine Handvoll Agenten mit großen Kontexten betreibt, kann mit einem Dutzend gleichzeitiger Anfragen 4M TPM erreichen. Zwischengespeicherte Eingaben zählen weiterhin zu TPM; der Cache-Rabatt ist ein Abrechnungsrabatt, kein Ratenlimit-Rabatt. Reasoning-Token zählen zu Ihrem max_output_tokens und Ihrer Rechnung, und Ausgabe-Token zählen ebenfalls zu TPM.

Die praktische Konsequenz: Budgetieren Sie TPM nach Kontextgröße, nicht nach Anzahl der Anfragen. Ein Agent, der in jeder Runde ein 300K-Token-Gespräch erneut sendet, ist jedes Mal eine 300K-Token-Anfrage, und zehn solcher Agenten, die einmal pro Minute agieren, verbrauchen drei Viertel des Teamkontingents.

Planen Sie die Parallelität anhand der Zahlen

Die Kapazitätsmathematik ist eine Zeile: Gleichzeitige Agenten, mal Token pro Runde, mal Runden pro Minute, muss unter 4.000.000 bleiben. Rechnen Sie es für Ihre stärkste Spur, bevor Sie bereitstellen.

Lassen Sie mindestens 40 % Kopffreiheit. Agentenwechsel sind stoßweise, ein Wiederholungssturm nach einem vorübergehenden Fehler verdoppelt die Nachfrage für eine Minute und alle anderen im Team schöpfen aus demselben Pool. Die dritte Reihe sieht auf dem Papier gut aus und schlägt in der Praxis fehl, wenn zwei Agenten es zum ersten Mal gleichzeitig versuchen.

Zwei Hebel verkleinern die linke Seite der Gleichung. Komprimierung verhindert, dass Token pro Runde unbegrenzt wachsen: Fassen Sie alte Tool-Ergebnisse zusammen oder verwerfen Sie sie, sobald ein Lauf einen Schwellenwert überschreitet, wie der Kontextfenster-Beitrag beschreibt. Und zustandsloses verschlüsseltes Replay auf der Responses API lässt Sie genau steuern, was Sie erneut senden, wo serververwaltete Historie mit previous_response_id alles erneut sendet.

Ein gemeinsamer Pool für alle Schlüssel

Meta begrenzt Limits pro Team. Ein Schlüssel für Staging, ein Schlüssel für Produktion und ein Schlüssel für den Laptop eines Teamkollegen greifen alle auf dieselben 3.000/4M zu. Das hat zwei Folgen.

Erstens kann ein Belastungstest eines Entwicklers die Produktion drosseln. Isolieren Sie Experimente zeitlich oder in einem separaten Team, wenn Ihre Organisation dies erlaubt. Zweitens zeigt Ihnen die Überwachung pro Schlüssel nicht das ganze Bild. Aggregieren Sie x-ratelimit-*-Header über jeden Aufrufer, sonst sehen Sie 429s auf einem Schlüssel, der weit unter seinem Limit zu liegen scheint.

Lesen Sie die Überschriften

Tokenbasierte Antworten tragen x-ratelimit-*-Header. Protokollieren Sie sie bei jedem Aufruf. Das Muster, das zählt, ist verbleibende Kapazität, die innerhalb einer Minute über alle Aufrufer gegen Null tendiert, Ihr Signal, vor dem 429 zu verlangsamen. Transkriptionsantworten tragen diese Header nicht; die von Wonder schon.

Wenn ein 429 eintrifft, sind die Dokumente von Meta spezifisch: Gehen Sie exponentiell zurück, wobei der Jitter bei etwa 500 ms beginnt, und wenn Retry-After vorhanden ist, warten Sie mindestens so lange. Eine Wiederholungsschleife, die Retry-After ignoriert und in einem festen Intervall hämmert, verlängert den Ausfall für alle Mitglieder Ihres Teams.

Erstellen Sie den Wiederholungspfad

import random, time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api.meta.ai/v1", [REDACTED CREDENTIAL] 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")

Drei Designpunkte. Begrenzen Sie das Backoff, damit ein langer Ausfall nicht zu einem 20-minütigen Schlaf wird. Halten Sie Wiederholungen idempotent: Ein Responses-Aufruf, der auf Ihrer Seite nichts erstellt, kann sicher wiederholt werden, aber wenn die Tool-Aufrufe Ihres Agenten Nebeneffekte haben, wiederholen Sie den Modellaufruf, nicht das Tool. Und zeigen Sie Wiederholungen in Ihren Traces, damit Sie ein langsames Modell von einem gedrosselten unterscheiden können; der Tool-Call-Tracing-Guide behandelt, was protokolliert werden soll.

Verwenden Sie Hintergrundantworten für den langen Schwanz

Langlaufende Jobs müssen keine Verbindung halten. background: true stellt die Antwort in eine Warteschlange, gibt "status": "queued" zurück und ermöglicht Ihnen, GET /v1/responses/{id}?stream=true auf Lebenszyklusereignisse abzufragen. Hintergrundübermittlungen haben zusätzlich zu den Hauptlimits ein eigenes Kontingent von 600 pro Minute, sodass das Verlagern von Batch-Arbeiten dort RPM für interaktiven Verkehr freisetzt. Einschränkungen: kein stream: true beim POST, eine 1-MiB-Body-Obergrenze und Sie stornieren mit POST /v1/responses/{id}/cancel.

Wenn 3.000 RPM nicht ausreichen

Meta veröffentlicht keine Stufenleiter und kein Formular zum Erhöhen von Limits. Ihre Optionen heute:

• Reduzieren Sie Token pro Anfrage. Prompt-Caching reduziert Ihre Rechnung, aber nicht Ihr TPM; das Kürzen des Kontexts tut beides. Der Kontextfenster-Beitrag behandelt das Kürzen von Tool-Ergebnissen.
• Verteilen Sie über Modelle. Spark 1.3 hat einen eigenen 3.000/4M-Pool zu einem Drittel des Preises. Leiten Sie Arbeit, die Wonders Qualität nicht benötigt, dorthin.
• Verwenden Sie ein Gateway. Vercel AI Gateway und Cloudflare Workers AI dienen meta/muse-wonder-1.0. Ob das Ihnen ein separates Kontingent gibt, hängt davon ab, wie das Gateway bereitgestellt wird; prüfen Sie das mit ihnen, bevor Sie sich darauf verlassen.
• Warteschlange und Glättung. Ein Token-Bucket-Limiter vor der API, der das gesamte Teambudget kennt, wird sechs Dienste übertreffen, die jeweils raten.

Testen Sie die Limit-Verwaltung in Apidog

Entdecken Sie Ihre Wiederholungsfehler nicht bei 3.001 Anfragen. In Apidog:

1. Erstellen Sie die Responses-Anfrage mit MODEL_API_KEY als geheime Variable und fügen Sie einen Postprozessor hinzu, der die x-ratelimit-*-Header in Umgebungsvariablen liest, damit ein Szenario behaupten kann, dass die verbleibende Kapazität nie unter einen Schwellenwert fällt.
2. Erstellen Sie ein Mock von /v1/responses mit einer Mock-Erwartung, die 429 und einen Retry-After: 2-Header zurückgibt, wenn eine Anfrage einen Header wie X-Test-Scenario: throttle enthält. Richten Sie Ihren Client auf das Mock und behaupten Sie, dass er mindestens zwei Sekunden wartet und beim nächsten Versuch erfolgreich ist.
3. Führen Sie einen Leistungstest durch, der das Anfragevolumen gegen das Mock erhöht, um zu bestätigen, dass Ihr Limiter aktiv wird, bevor die API es tun würde.
4. Bringen Sie das Szenario mit dem Apidog-CLI in CI, damit eine Änderung am Wiederholungscode nicht ohne Bestehen ausgeliefert werden kann.

Laden Sie Apidog herunter, um das Mock und die Assertionen in einem Projekt einzurichten.

Häufig gestellte Fragen

Gibt es bei Muse Wonder Ratenlimits pro Schlüssel oder pro Konto? Pro Team. Alle Schlüssel in einem Team teilen sich einen 3.000 RPM/4M TPM-Pool pro Modell.

Zählt zwischengespeicherte Eingabe zu TPM? Ja. Caching senkt den Preis dieser Token, nicht ihr Gewicht gegenüber dem Token-Minutenlimit.

Kann ich ein höheres Limit anfordern? Metas Seite zu Preisen und Ratenlimits listet keine Stufen und keinen Prozess. Prüfen Sie die Seite auf Änderungen; Frontier-Starts fügen oft innerhalb von Wochen Stufen hinzu.

Welchen Statuscode und welche Header erhalte ich? HTTP 429, optional mit Retry-After, plus x-ratelimit-*-Header auf tokenbasierten Antworten.

Nächster Schritt

Messen Sie die Tokens pro Anfrage Ihrer leistungsstärksten Agentenrunde, multiplizieren Sie sie mit der Parallelität und vergleichen Sie sie mit 4.000.000. Wenn die Antwort nah dran ist, bauen Sie den Begrenzer und den Mock-Test diese Woche, bevor das Team den Pool mit der Produktion teilt.