Los límites de velocidad de Muse Wonder en la API Meta Model son 3.000 solicitudes por minuto y 4.000.000 de tokens por minuto. Ambos se aplican por modelo y por equipo, no por clave API: cada clave que crea su organización se extrae del mismo grupo. Las respuestas en segundo plano reciben una asignación separada de 600 nuevos envíos por minuto. No hay niveles de uso publicados ni forma documentada de solicitar más. Cuando excedes un límite, obtienes HTTP 429, y la guía de Meta es retroceso exponencial con fluctuación aleatoria comenzando alrededor de 500 ms, respetando Retry-After cuando esté presente.
Estos cuatro hechos deciden cómo arquitectas cualquier cosa que llame a muse-wonder-1.0 a escala. Esta publicación cubre qué significan los límites en la práctica, cómo un contexto de 1M de tokens consume un presupuesto de 4M TPM, cómo leer los encabezados, cómo construir y probar la ruta de reintento y qué hacer cuando 3.000 RPM no son suficientes. Para lo básico de la API, comienza con la guía de la API Muse Wonder.
Los límites
| Límite | Valor | Alcance |
|---|---|---|
| Solicitudes por minuto | 3,000 | Por equipo, por modelo |
| Tokens por minuto | 4,000,000 | Por equipo, por modelo |
| Envíos en segundo plano | 600 por minuto | Por equipo, además de lo anterior |
| Ventana de contexto | 1,048,576 tokens | Por solicitud |
| Niveles de uso | Ninguno publicado | |
| Aumentos de límite | No hay proceso documentado |
Las mismas cifras de 3,000/4M se aplican a Muse Spark 1.3; la variante Contributor de Spark tiene un límite inferior de 150 RPM y 3M TPM. Cada modelo tiene su propio grupo, por lo que el tráfico intenso de Wonder no agota un carril de Spark y viceversa. El contexto de dirección inyectado por Meta no se cuenta contra TPM y no aparece en usage.
Los tokens se agotan antes que las solicitudes
Con 4M de tokens por minuto, el límite de solicitudes rara vez es el restrictivo para un agente. Tres ilustraciones:
| Carga de trabajo | Tokens por solicitud | Solicitudes por minuto antes de que TPM restrinja |
|---|---|---|
| Turnos de chat cortos | 3,000 | 1,333 |
| Revisión de documentos | 50,000 | 80 |
| Turno largo de agente, contexto de 400K | 400,000 | 10 |
| Solicitud de ventana completa | 1,000,000 | 4 |
Un equipo que ejecuta un puñado de agentes con contextos grandes puede alcanzar 4M TPM con una docena de solicitudes concurrentes. La entrada almacenada en caché aún cuenta para TPM; el descuento de caché es un descuento de facturación, no un descuento de límite de velocidad. Los tokens de razonamiento cuentan para tu max_output_tokens y tu factura, y los tokens de salida también cuentan para TPM.
La consecuencia práctica: presupuesta TPM por tamaño de contexto, no por número de solicitudes. Un agente que reenvía una conversación de 300K tokens en cada turno es una solicitud de 300K tokens cada vez, y diez de esos agentes que avanzan una vez por minuto consumen tres cuartas partes del margen del equipo.
Planificar la concurrencia a partir de los números
El cálculo de capacidad es una línea: agentes concurrentes, por tokens por turno, por turnos por minuto, debe mantenerse por debajo de 4,000,000. Calcúlalo para tu carril más pesado antes de implementar.
| Agentes | Tokens por turno | Turnos por minuto cada uno | TPM necesario | Margen |
|---|---|---|---|---|
| 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 | sobre el límite |
Deja al menos un 40% de margen. Los turnos de los agentes son irregulares, una tormenta de reintentos después de un error transitorio duplica la demanda durante un minuto y cualquier otra persona del equipo consume del mismo grupo. La tercera fila parece bien en el papel y falla en la práctica la primera vez que dos agentes reintentan a la vez.
Dos palancas reducen el lado izquierdo de la ecuación. La compactación evita que los tokens por turno crezcan sin límite: resume o descarta resultados de herramientas antiguos cuando una ejecución supera un umbral, como describe la publicación de ventana de contexto. Y la reproducción cifrada sin estado en la API de Responses te permite controlar exactamente lo que reenvías, donde el historial administrado por el servidor con previous_response_id reenvía todo.
Un único grupo para todas las claves
Meta define los límites por equipo. Una clave para staging, una clave para producción y una clave para la computadora portátil de un compañero de equipo consumen del mismo 3,000/4M. Esto tiene dos consecuencias.
Primero, una prueba de carga de un desarrollador puede limitar la producción. Aísla los experimentos en el tiempo, o en un equipo separado si tu organización lo permite. Segundo, la supervisión por clave no te mostrará el panorama completo. Agrega los encabezados x-ratelimit-* en cada emisor, o verás 429 en una clave que parece estar muy por debajo de su límite.
leer los encabezados
Las respuestas basadas en tokens llevan encabezados x-ratelimit-*. Regístralos en cada llamada. El patrón que importa es la capacidad restante tendiendo a cero en todos los emisores dentro de un minuto, que es tu señal para reducir la velocidad antes de que llegue el 429. Las respuestas de transcripción no llevan estos encabezados; las de Wonder sí.
Cuando llega un 429, los documentos de Meta son específicos: retrocede exponencialmente con fluctuación aleatoria comenzando alrededor de 500 ms, y si Retry-After está presente, espera al menos ese tiempo. Un bucle de reintento que ignora Retry-After y golpea a intervalos fijos prolonga la interrupción para todos en tu equipo.
Construya la ruta de reintento
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")
Tres puntos de diseño. Limita el retroceso para que una interrupción larga no se convierta en una suspensión de 20 minutos. Mantén los reintentos idempotentes: una llamada de Responses que no crea nada de tu lado es segura de repetir, pero si las llamadas de herramientas de tu agente tienen efectos secundarios, reintenta la llamada del modelo, no la herramienta. Y muestra los reintentos en tus trazas para distinguir un modelo lento de uno limitado; la guía de trazado de llamadas de herramientas cubre qué registrar.
Utilice respuestas en segundo plano para la cola larga
Los trabajos largos no necesitan mantener una conexión. background: true pone la respuesta en cola, devuelve "status": "queued" y te permite consultar GET /v1/responses/{id}?stream=true para eventos del ciclo de vida. Los envíos en segundo plano tienen su propia asignación de 600 por minuto además de los límites principales, por lo que mover el trabajo por lotes allí libera RPM para el tráfico interactivo. Restricciones: no stream: true en el POST, un límite de cuerpo de 1 MiB y cancelas con POST /v1/responses/{id}/cancel.
Cuando 3.000 RPM no son suficientes
Meta no publica una escala de niveles ni un formulario para aumentar los límites. Tus opciones hoy:
- Reduce los tokens por solicitud. El almacenamiento en caché de prompts reduce tu factura pero no tu TPM; recortar el contexto hace ambos. La publicación de ventana de contexto cubre el recorte de resultados de herramientas.
- Distribuye entre modelos. Spark 1.3 tiene su propio grupo de 3,000/4M a un tercio del precio. Enruta allí el trabajo que no necesita la calidad de Wonder.
- Usa una puerta de enlace. Vercel AI Gateway y Cloudflare Workers AI sirven meta/muse-wonder-1.0. Si eso te da una asignación separada depende de cómo esté aprovisionada la puerta de enlace; verifícalo con ellos antes de depender de ello.
- Encola y suaviza. Un limitador de cubeta de tokens frente a la API que conoce todo el presupuesto del equipo superará a seis servicios adivinando cada uno.
Pruebe el manejo de límites en Apidog
No descubras tus errores de reintento en 3,001 solicitudes. En Apidog:
- Construye la solicitud de Responses con MODEL_API_KEY como variable secreta y agrega un posprocesador que lea los encabezados x-ratelimit-* en variables de entorno para que un escenario pueda afirmar que la capacidad restante nunca caiga por debajo de un umbral.
- Crea una simulación de /v1/responses con una expectativa simulada que devuelva 429 y un encabezado Retry-After: 2 cuando una solicitud lleve un encabezado como X-Test-Scenario: throttle. Apunta tu cliente a la simulación y afirma que espera al menos dos segundos y tiene éxito en el siguiente intento.
- Ejecuta una prueba de rendimiento que aumente el volumen de solicitudes contra la simulación para confirmar que tu limitador se activa antes de que lo haría la API.
- Coloca el escenario en CI con el CLI de Apidog para que un cambio en el código de reintento no se pueda enviar sin pasar.
Descarga Apidog para configurar la simulación y las afirmaciones en un proyecto.
Preguntas frecuentes
¿Los límites de velocidad de Muse Wonder son por clave o por cuenta? Por equipo. Todas las claves de un equipo comparten un grupo de 3,000 RPM/4M TPM por modelo.
¿La entrada almacenada en caché cuenta para TPM? Sí. El almacenamiento en caché reduce el precio de esos tokens, no su peso contra el límite de tokens por minuto.
¿Puedo solicitar un límite más alto? La página de precios y límites de velocidad de Meta no enumera niveles ni proceso. Revisa la página para cambios; los lanzamientos frontera a menudo agregan niveles en semanas.
¿Qué código de estado y encabezados obtengo? HTTP 429, opcionalmente con Retry-After, más encabezados x-ratelimit-* en respuestas basadas en tokens.
Siguiente paso
Mide los tokens por solicitud de tu turno de agente más pesado, multiplica por concurrencia y compáralo con 4,000,000. Si la respuesta está cerca, construye el limitador y la prueba simulada esta semana, antes de que el equipo comparta el grupo con producción.