Limites de taxa do Muse Wonder: 3.000 RPM e 4M TPM, compartilhados por toda a equipe

Os limites de taxa do Muse Wonder na API Meta Model são 3.000 solicitações por minuto e 4.000.000 de tokens por minuto. Ambos se aplicam por modelo e por equipe, não por chave de API: cada chave que sua organização cria é extraída do mesmo pool. As respostas em segundo plano recebem uma permissão separada de 600 novos envios por minuto. Não há níveis de uso publicados e nenhuma forma documentada de solicitar mais. Quando você excede um limite, você obtém HTTP 429, e a orientação do Meta é recuo exponencial com jitter começando em torno de 500 ms, respeitando Retry-After quando presente.

Esses quatro fatos decidem como você arquiteta qualquer coisa que chama muse-wonder-1.0 em escala. Este post cobre o que os limites significam na prática, como um contexto de 1M tokens consome um orçamento de 4M TPM, como ler os cabeçalhos, como construir e testar o caminho de nova tentativa e o que fazer quando 3.000 RPM não são suficientes. Para o básico da API, comece com o guia da API Muse Wonder.

Os limites

Os mesmos números de 3.000/4M se aplicam ao Muse Spark 1.3; a variante Contributor do Spark tem um limite inferior de 150 RPM e 3M TPM. Cada modelo tem seu próprio pool, para que o tráfego intenso do Wonder não deixe a Spark Lane de fome e vice-versa. O contexto de direção injetado do Meta não é contabilizado no TPM e não aparece em usage.

Os tokens acabam antes das solicitações

Com 4M tokens por minuto, o limite de solicitações raramente é o restritivo para um agente. Três ilustrações:

Uma equipe executando um punhado de agentes com contextos grandes pode atingir 4M TPM com uma dúzia de solicitações simultâneas. A entrada em cache ainda conta para o TPM; o desconto de cache é um desconto de faturamento, não um desconto de limite de taxa. Os tokens de raciocínio contam para seu max_output_tokens e sua fatura, e os tokens de saída também contam para o TPM.

A consequência prática: orce o TPM pelo tamanho do contexto, não pelo número de solicitações. Um agente que reenvia uma conversa de 300K tokens a cada turno é uma solicitação de 300K tokens a cada vez, e dez desses agentes avançando uma vez por minuto consomem três quartos da permissão da equipe.

Planeje a simultaneidade a partir dos números

A matemática de capacidade é uma linha: agentes simultâneos, vezes tokens por turno, vezes turnos por minuto, deve ficar abaixo de 4.000.000. Calcule para sua faixa mais pesada antes de implantar.

Deixe pelo menos 40% de margem. Os turnos dos agentes são intermitentes, uma tempestade de novas tentativas após um erro transitório dobra a demanda por um minuto e qualquer outra pessoa da equipe está consumindo do mesmo pool. A terceira linha parece boa no papel e falha na prática na primeira vez que dois agentes tentam novamente ao mesmo tempo.

Dos alavancas reduzem o lado esquerdo da equação. A compactação impede que os tokens por turno cresçam sem limite: resuma ou descarte resultados de ferramentas antigos quando uma execução passa de um limite, como a postagem da janela de contexto descreve. E o replay criptografado sem estado na API de Responses permite controlar exatamente o que você reenvia, onde o histórico gerenciado pelo servidor com previous_response_id reenvia tudo.

Um único pool para todas as chaves

Meta define limites por equipe. Uma chave para staging, uma chave para produção e uma chave para o laptop de um colega de equipe consomem do mesmo 3.000/4M. Isso tem duas consequências.

Primeiro, um teste de carga de um desenvolvedor pode limitar a produção. Isole experimentos no tempo, ou em uma equipe separada se sua organização permitir. Segundo, o monitoramento por chave não mostrará todo o quadro. Agregue os cabeçalhos x-ratelimit-* em todos os chamadores, ou você verá 429s em uma chave que parece estar bem abaixo de seu limite.

Leia os cabeçalhos

Respostas baseadas em tokens carregam cabeçalhos x-ratelimit-*. Registre-os em cada chamada. O padrão que importa é a capacidade restante tendendo a zero em todos os chamadores dentro de um minuto, que é seu sinal para desacelerar antes do 429 chegar. Respostas de transcrição não carregam esses cabeçalhos; as do Wonder sim.

Quando um 429 chega, os documentos do Meta são específicos: recue exponencialmente com jitter começando em torno de 500 ms, e se Retry-After estiver presente, espere pelo menos esse tempo. Um loop de nova tentativa que ignora Retry-After e martela em um intervalo fixo torna a interrupção mais longa para todos em sua equipe.

Crie o caminho de nova tentativa

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")

Três pontos de design. Limite o recuo para que uma interrupção longa não se transforme em um sono de 20 minutos. Mantenha as novas tentativas idempotentes: uma chamada de Responses que não cria nada do seu lado é segura de repetir, mas se as chamadas de ferramenta do seu agente tiverem efeitos colaterais, tente novamente a chamada do modelo, não a ferramenta. E mostre novas tentativas em seus rastreamentos para diferenciar um modelo lento de um limitado; o guia de rastreamento de chamadas de ferramenta cobre o que registrar.

Use respostas em segundo plano para a cauda longa

Trabalhos longos não precisam manter uma conexão. background: true enfileira a resposta, retorna "status": "queued" e permite pesquisar GET /v1/responses/{id}?stream=true por eventos de ciclo de vida. Envios em segundo plano têm sua própria permissão de 600 por minuto além dos limites principais, então mover trabalho em lote para lá libera RPM para tráfego interativo. Restrições: sem stream: true no POST, um limite de corpo de 1 MiB e você cancela com POST /v1/responses/{id}/cancel.

Quando 3.000 RPM não são suficientes

Meta não publica uma escada de níveis nem um formulário para aumentar limites. Suas opções hoje:

• Reduza tokens por solicitação. O cache de prompts reduz sua fatura, mas não seu TPM; cortar o contexto faz ambos. A postagem da janela de contexto cobre o corte de resultados de ferramentas.
• Espalhe entre modelos. Spark 1.3 tem seu próprio pool de 3.000/4M por um terço do preço. Encaminhe para lá o trabalho que não precisa da qualidade do Wonder.
• Use um gateway. Vercel AI Gateway e Cloudflare Workers AI servem meta/muse-wonder-1.0. Se isso dá a você uma permissão separada depende de como o gateway é provisionado; verifique com eles antes de confiar.
• Enfileire e suavize. Um limitador de balde de tokens na frente da API que conhece todo o orçamento da equipe superará seis serviços cada um adivinhando.

Teste o tratamento de limites no Apidog

Não descubra seus bugs de nova tentativa em 3.001 solicitações. No Apidog:

1. Construa a solicitação de Responses com MODEL_API_KEY como variável secreta e adicione um pós-processador que lê os cabeçalhos x-ratelimit-* em variáveis de ambiente para que um cenário possa afirmar que a capacidade restante nunca caia abaixo de um piso.
2. Crie uma simulação de /v1/responses com uma expectativa simulada que retorna 429 e um cabeçalho Retry-After: 2 quando uma solicitação carrega um cabeçalho como X-Test-Scenario: throttle. Aponte seu cliente para a simulação e afirme que ele espera pelo menos dois segundos e tem sucesso na próxima tentativa.
3. Execute um teste de desempenho que aumenta o volume de solicitações contra a simulação para confirmar que seu limitador entra em ação antes da API.
4. Coloque o cenário no CI com o CLI do Apidog para que uma alteração no código de nova tentativa não seja enviada sem passar.

Baixe o Apidog para configurar a simulação e as afirmações em um projeto.

Perguntas frequentes

Os limites de taxa do Muse Wonder são por chave ou por conta? Por equipe. Todas as chaves em uma equipe compartilham um pool de 3.000 RPM/4M TPM por modelo.

A entrada em cache conta para o TPM? Sim. O cache reduz o preço desses tokens, não o peso deles contra o limite de tokens por minuto.

Posso solicitar um limite maior? A página de preços e limites de taxa do Meta não lista níveis nem processo. Verifique a página para mudanças; lançamentos de fronteira frequentemente adicionam níveis em semanas.

Que código de status e cabeçalhos recebo? HTTP 429, opcionalmente com Retry-After, além de cabeçalhos x-ratelimit-* em respostas baseadas em tokens.

Próxima etapa

Meça os tokens por solicitação do turno do seu agente mais pesado, multiplique pela simultaneidade e compare com 4.000.000. Se a resposta estiver próxima, construa o limitador e o teste simulado esta semana, antes que a equipe compartilhe o pool com produção.