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

Die Muse-Wonder-Limits 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 Ihrer Organisation greift auf denselben Pool zu. Hintergrundantworten erhalten ein zusätzliches Kontingent von 600 neuen Einsendungen pro Minute. Es gibt derzeit keine veröffentlichten Nutzungsstufen und keinen dokumentierten Prozess für Limit-Erhöhungen. Bei Überschreitung erhalten Sie HTTP 429; Meta empfiehlt exponentielles Backoff mit Jitter ab etwa 500 ms und die Berücksichtigung von Retry-After, falls vorhanden.

Probieren Sie Apidog noch heute aus

Diese Fakten bestimmen, wie Sie Aufrufe von muse-wonder-1.0 im Maßstab archivieren. Dieser Beitrag erklärt, was die Limits praktisch bedeuten, wie ein 1M-Token-Kontext ein 4M-TPM-Budget verbraucht, wie Sie die Header lesen, wie Sie Wiederholungen 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

Limit	Wert	Bereich
Anfragen pro Minute	3.000	Pro Team, pro Modell
Token pro Minute	4.000.000	Pro Team, pro Modell
Hintergrundübermittlungen	600 pro Minute	Pro Team, zusätzlich zu den Hauptlimits
Kontextfenster	1.048.576 Token	Pro Anfrage
Nutzungsstufen	Keine veröffentlicht
Limit-Erhöhungen	Kein dokumentierter Prozess

Dieselben 3.000 RPM und 4 Mio. TPM gelten für Muse Spark 1.3. Die Contributor-Variante von Spark ist auf 150 RPM und 3 Mio. TPM begrenzt. Jedes Modell hat einen eigenen Pool, daher kann starker Wonder-Verkehr eine Spark-Lane nicht verhungern lassen und umgekehrt. Der von Meta injizierte Steuerungskontext wird nicht auf TPM angerechnet und erscheint nicht in usage.

Die Token gehen vor den Anfragen aus

Mit 4 Mio. Token pro Minute ist das Anfragelimit für Agenten selten der engste Begrenzer. Die notwendige Anfragezahl hängt direkt von der Kontextgröße ab:

Arbeitslast	Token pro Anfrage	Anfragen pro Minute, bevor TPM bindend wird
Kurze Chat-Runden	3.000	1.333
Dokumentenprüfung	50.000	80
Lange Agentenrunde mit 400K-Kontext	400.000	10
Vollfensteranfrage	1.000.000	4

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

Budgetieren Sie TPM daher nach Kontextgröße, nicht nach Anzahl der Anfragen. Ein Agent, der in jeder Runde ein 300K-Token-Gespräch erneut sendet, erzeugt jedes Mal eine 300K-Token-Anfrage. Zehn solche Agenten, die einmal pro Minute agieren, verbrauchen drei Viertel des Teamkontingents.

Planen Sie die Parallelität anhand der Zahlen

Die Kapazitätsmathematik ist kompakt:

Gleichzeitige Agenten
× Token pro Runde
× Runden pro Minute
< 4.000.000

Berechnen Sie diesen Wert für Ihre stärkste Pipeline, bevor Sie sie bereitstellen:

Agenten	Token pro Runde	Runden pro Minute jeweils	Benötigtes TPM	Spielraum
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	Über dem Limit

Planen Sie mindestens 40 % Kopffreiheit ein. Agentenarbeit tritt oft stoßweise auf, ein Wiederholungssturm nach einem vorübergehenden Fehler kann die Nachfrage für eine Minute verdoppeln, und alle anderen im Team nutzen denselben Pool. Die dritte Zeile wirkt auf dem Papier sicher, scheitert aber in der Praxis, wenn zwei Agenten beim ersten Versuch gleichzeitig laufen.

Zwei Hebel verkleinern den Bedarf:

• Komprimierung: Verhindern Sie, dass der Tokenbedarf pro Runde unbegrenzt wächst. Fassen Sie alte Tool-Ergebnisse zusammen oder verwerfen Sie sie, sobald ein Lauf einen Schwellenwert überschreitet, wie im Kontextfenster-Beitrag beschrieben.
• Zustandsloses verschlüsseltes Replay: Die Responses API ermöglicht es Ihnen, genau zu steuern, was Sie erneut senden. Serververwaltete Historie mit previous_response_id sendet dagegen alles erneut.

Ein gemeinsamer Pool für alle Schlüssel

Meta begrenzt die Nutzung pro Team. Ein Schlüssel für Staging, ein Schlüssel für Produktion und ein Schlüssel auf dem Laptop einer Teamkollegin oder eines Teamkollegen greifen alle auf dieselben 3.000 RPM und 4 Mio. TPM zu.

Daraus folgen zwei Regeln:

1. Ein Belastungstest eines Entwicklers kann die Produktion drosseln. Isolieren Sie Experimente zeitlich oder in einem separaten Team, wenn Ihre Organisation das erlaubt.
2. Überwachung pro Schlüssel zeigt nicht das ganze Bild. Aggregieren Sie x-ratelimit-*-Header über jeden Aufrufer, sonst sehen Sie 429-Fehler auf einem Schlüssel, der scheinbar weit unter seinem Limit liegt.

Lesen Sie die Header

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

Bei einem 429 ist Metas Empfehlung konkret: Verwenden Sie exponentielles Backoff mit Jitter ab etwa 500 ms, und warten Sie mindestens die in Retry-After angegebene Zeit, wenn der Header vorhanden ist. Eine Wiederholungsschleife, die Retry-After ignoriert und in einem festen Intervall weiterfragt, verlängert die Drosselung für Ihr gesamtes Team.

Erstellen Sie den Wiederholungspfad

Ein robuster Wiederholungspfad kombiniert Retry-After, exponentielles Backoff, Jitter und eine Obergrenze für die Wartezeit:

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:
                wait = float(retry_after)
            else:
                wait = delay + random.uniform(0, delay)

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

    raise RuntimeError("rate limited after retries")

Drei Designpunkte sind wichtig:

1. Backoff begrenzen: Verhindern Sie, dass ein langer Ausfall zu einer 20-minütungen in Ihren Traces, damit Sie ein langsames Modell von einem gedrosselten unterscheiden können. Der Tool-Call-Tracing-Guide beschreibt, was protokolliert werden sollte.

Verwenden Sie Hintergrundantworten für langlaufende Jobs

Langlaufende Jobs müssen keine Verbindung halten. background: true stellt die Antwort in eine Warteschlange"zurück und ermöglicht das Abfragen vonGET /v1/responses/{id}?stream=true` für Lebenszyklusereignisse.

Hintergrundübermittlungen haben zusätzlich zu den Hauptlimits ein eigenes Kontingent von 600 pro Minute. Das Verlagern von Batch-Arbeiten kann daher RPM für interaktiven Verkehr freisetzen.

Beachten Sie die Einschränkungen:

• stream: true ist beim POST nicht zulässig.
• Der Anfrage-Body ist auf 1 MiB begrenzt.
• Der Abbruch erfolgt mit POST /v1/responses/{id}/cancel.

Wenn 3.000 RPM nicht ausreichen

Meta veröffentlicht derzeit keine Stufen und kein Formular für Limit-Erhöhungen. Ihre heutigen Optionen sind:

• Reduzieren Sie Token pro Anfrage. Prompt-Caching reduziert Ihre Rechnung, aber nicht Ihr TPM. Das Kürzen des Kontexts reduziert beides. Der Kontextfenster-Beitrag behandelt das Kürzen von Tool-Ergebnissen.
• Verteilen Sie Arbeit über Modelle. Muse 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 Ihnen das ein separates Kontingent gibt, hängt von der Bereitstellung des Gateways ab-Management in Apidog

Entdecken Sie Wiederholungsfehler nicht erst bei Anfrage 3.001. In Apidog:

1. Erstellen Sie die Responses-Anfrage mit MODEL_API_KEY als geheime Variable. Fügen Sie einen Postprozessor hinzu, der die x-ratelimit-*-Header in Umgebungsvariablen speichert, damit ein Szenario behaupten kann, dass die verbleibende Kapazität nie unter einen Schwellenwert fällt.
2. Erstellen Sie ein Mock für /v1/responses, dessen Erwartung HTTP 429 und den Header Retry-After: 2 zurückgibt, wenn die Anfrage einen Header wie X-Test-Scenario: throttle enthält. Richten Sie Ihren Client auf das Mock und prüfen Sie, dass er mindestens zwei Sekunden wartet und beim nächsten Versuch erfolgreich ist.
3. Führen Sie einen Leistungstest aus, der das Anfragevolumen gegen das Mock erhöht, um zu bestätigen, dass Ihr Limiter aktiv wird, bevor die echte API drosseln würde.
4. Bringen Sie das Szenario mit der Apidog-CLI in CI, damit Änderungen am Wiederholungscode nur mit bestehenden Tests ausgeliefert werden können.

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 Pool von 3.000 RPM und 4 Mio. TPM 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 derzeit keine Stufen und keinen Prozess. Prüfen Sie die Seite auf Änderungen; neue Modelle ergänzen oft innerhalb weniger Wochen Nutzungsstufen.

Welchen Statuscode und welche Header erhalte ich bei einer Überschreitung?

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 das Ergebnis mit 4.000.000. Wenn die Antwort nah an diesem Wert liegt, erstellen Sie den Begrenzer und den Mock-Test diese Woche, bevor Ihr Team denselben Pool mit der Produktion teilt.