Se você está desenvolvendo com o modelo mais recente da Anthropic e se perguntando sobre os limites de taxa do Claude Fable 5, aqui está a resposta honesta de imediato: a Anthropic não lançou um sistema de limite de taxa separado e exclusivo para o Fable-5 no lançamento. O Fable 5 (ID do modelo claude-fable-5, com preço de US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída, lançado em 9 de junho de 2026) usa a mesma API de Mensagens padrão e se baseia nos limites de taxa de API padrão, baseados em níveis, da sua organização. Esses limites aumentam com o uso e o histórico de gastos da sua conta, são aplicados por organização e por classe de modelo, e os números exatos que você obtém dependem do nível de uso em que você se encontra. Essa abordagem é importante, porque se você está tentando planejar a capacidade para um agente Fable 5, você está planejando em torno do sistema de níveis da Anthropic, e não em torno de um número mágico impresso no anúncio de lançamento. Se você é novo no modelo em si, a visão geral do Claude Fable 5 é uma boa leitura complementar.
TL;DR
O Claude Fable 5 usa os limites de taxa padrão baseados em níveis da Anthropic: requisições por minuto (RPM) mais tokens de entrada por minuto (ITPM) e tokens de saída por minuto (OTPM), aplicados por organização e por classe de modelo. Os limites aumentam à medida que seus gastos cumulativos o movem para níveis de uso superiores (1 a 4). Sempre confirme seus números reais no Console da Anthropic e lide com um erro 429 lendo seu cabeçalho retry-after.
Como funcionam os limites de taxa da Anthropic
A Anthropic não define um único "limite de API" global. Ela opera um sistema de níveis de uso, e seu nível decide a quantidade de throughput que você obtém. Existem dois conceitos relacionados: limites de gastos (quanto você pode ser cobrado por mês civil) e limites de taxa (com que rapidez você pode chamar a API). Este artigo trata do segundo, mas os dois estão vinculados, porque seu nível é o que avança ambos.

Os tipos de limite
Para a API de Mensagens, os limites de taxa são medidos em três dimensões, cada uma aplicada por minuto e por classe de modelo:
- Requisições por minuto (RPM). Quantas chamadas de API separadas você pode iniciar a cada minuto.
- Tokens de entrada por minuto (ITPM). Quantos tokens de entrada você pode enviar a cada minuto. Na maioria dos modelos atuais, apenas tokens de entrada não armazenados em cache contam aqui. Tokens lidos de um cache de prompt não contam para o ITPM, razão pela qual o cache pode aumentar seu throughput efetivo bem acima do número bruto.
- Tokens de saída por minuto (OTPM). Quantos tokens o modelo pode gerar para você a cada minuto. Isso é avaliado em tempo real à medida que os tokens são transmitidos, e seu teto
max_tokensnão é pré-cobrado contra isso. Definir ummax_tokensalto não, por si só, consome OTPM; apenas os tokens realmente produzidos contam.
A Anthropic aplica esses limites com um algoritmo de balde de tokens. Em vez de redefinir sua cota total no início de cada minuto, sua capacidade é recarregada continuamente até seu máximo. A consequência prática é que um limite como "50 RPM" pode se comportar como aproximadamente uma requisição por segundo, então uma sequência apertada de chamadas pode atingir um limite mesmo quando sua média por minuto parece boa. O tráfego suave e constante aproveita mais os mesmos números do que o tráfego em picos.
Por organização, por classe de modelo
Mais dois detalhes moldam como os números se aplicam a você. Primeiro, os limites são definidos no nível da organização, não por chave de API, então cada chave em sua organização usa o mesmo pool (você pode definir limites menores por espaço de trabalho se quiser proteger um espaço de trabalho do outro). Segundo, os limites são aplicados por classe de modelo. Isso significa que o tráfego do Fable 5 e, digamos, o tráfego do Opus são medidos contra seus próprios baldes separados. Você pode executar diferentes classes de modelo até seus respectivos limites ao mesmo tempo sem que uma prejudique a outra.
Como os níveis avançam
Os níveis avançam automaticamente à medida que suas compras cumulativas de crédito cruzam os limites. De acordo com os níveis publicados da Anthropic (verifique seu próprio status no Console), a estrutura é a seguinte: o Nível 1 é desbloqueado com uma compra de crédito de US$ 5, o Nível 2 com US$ 40 acumulados, o Nível 3 com US$ 200 acumulados e o Nível 4 com US$ 400 acumulados, com tetos de gastos mensais aumentando a cada etapa. Você avança no momento em que cruza um limite; você não precisa abrir um ticket. Acima do Nível 4, tetos mais altos são tratados por meio de vendas ou faturamento mensal.
Para uma análise mais aprofundada de como essas compras se traduzem em custo para este modelo específico, a análise de preços do Claude Fable 5 combina bem com esta seção.
O que isso significa especificamente para o Claude Fable 5
Aqui está a parte que as pessoas mais querem saber. O Fable 5 não recebe uma estrutura de limite exótica e específica do modelo. Ele se encaixa na tabela de níveis padrão como sua própria classe de modelo, então a pergunta "quais são os meus limites do Fable 5?" se resolve em "em que nível minha organização está e o que a linha do Fable 5 diz para esse nível?"
De acordo com os níveis de limite de taxa publicados da Anthropic (novamente, confirme os seus no Console, já que arranjos personalizados e empresariais diferem), a linha do Fable 5 escala aproximadamente assim:
- Nível 1: 50 RPM, 100.000 ITPM, 20.000 OTPM.
- Nível 2: 1.000 RPM, 500.000 ITPM, 100.000 OTPM.
- Nível 3: 2.000 RPM, 1.500.000 ITPM, 300.000 OTPM.
- Nível 4: 4.000 RPM, 4.000.000 ITPM, 800.000 OTPM.
Trate esses valores como a estrutura do sistema, não um contrato. A Anthropic atualiza as tabelas, o Nível Prioritário e os acordos empresariais mudam o cenário, e seu Console é a fonte da verdade. Se um número aqui discordar do que sua conta mostra, acredite na sua conta.
A dimensão que mais impacta o Fable 5 é o OTPM. O Fable 5 é construído para trabalhos de longo prazo, de milhões de tokens, o tipo de execução em que um agente realiza uma grande tarefa e emite muitos resultados ao longo do caminho. Uma geração longa não consome uma grande parte do OTPM no início; ela reduz seu orçamento de saída constantemente enquanto é transmitida. Assim, um único trabalho ambicioso do Fable 5 pode se aproximar de seu limite de OTPM por um período sustentado, e se você disparar vários desses trabalhos simultaneamente, o OTPM geralmente é a primeira parede que você atinge, não o RPM. Duas práticas decorrem disso: dimensione corretamente o max_tokens para que uma geração descontrolada não infle, e transmita saídas longas para que você não mantenha uma conexão aberta esperando por uma resposta gigante não transmitida (o que também o ajuda a evitar timeouts de requisição). Se você está conectando o modelo pela primeira vez, o guia da API do Claude Fable 5 explica a forma da requisição a que esses limites se aplicam.
Lendo e verificando seus limites
Nunca adivinhe seus limites a partir de uma postagem de blog, incluindo esta. Existem duas maneiras confiáveis de ver os números reais.
A primeira é o Console da Anthropic. A página de Limites nas configurações mostra o nível atual da sua organização e os limites de taxa por modelo em vigor, e a página de Uso exibe gráficos da sua taxa real de tokens de entrada e saída ao longo do tempo em relação ao seu limite, incluindo sua taxa de acertos de cache. Esses gráficos são a maneira mais rápida de responder "tenho folga, ou estou prestes a atingir um limite?" antes de aumentar o tráfego.
A segunda são os cabeçalhos de resposta em cada chamada de API. A Anthropic retorna um conjunto de cabeçalhos anthropic-ratelimit-* que informam exatamente onde você se encontra naquele momento:
anthropic-ratelimit-requests-limiteanthropic-ratelimit-requests-remainingpara RPM.anthropic-ratelimit-input-tokens-limiteanthropic-ratelimit-input-tokens-remainingpara ITPM.anthropic-ratelimit-output-tokens-limiteanthropic-ratelimit-output-tokens-remainingpara OTPM.- Um cabeçalho
*-resetcorrespondente para cada um, no formato RFC 3339, informando quando esse balde será totalmente reabastecido.
Os cabeçalhos de tokens restantes são arredondados para o milhar mais próximo, e os cabeçalhos de tokens combinados informam qual limite é mais restritivo no momento (por exemplo, um limite de nível de espaço de trabalho se você o tiver definido). Ler *-remaining em cada resposta permite que seu cliente se limite antes mesmo de receber um 429, o que é a diferença entre uma contrapressão graciosa e um fluxo de erros.
Lidando com 429s de forma elegante
Uma resposta 429 significa que você atingiu um dos limites. O corpo informa qual, e, crucialmente, a resposta carrega um cabeçalho retry-after com o número de segundos a esperar antes de tentar novamente. Tentar novamente antes do que retry-after indica resultará em falha novamente, então respeite-o.
A boa notícia é que os SDKs oficiais já fazem a coisa certa. O SDK da Anthropic tenta automaticamente novamente respostas 429 e 5xx com backoff exponencial (duas tentativas por padrão), lendo retry-after para cronometrar cada tentativa. Para a maioria das aplicações, esse comportamento integrado é suficiente, e você não deve criar um loop de nova tentativa manual, a menos que precise de algo que o SDK não oferece. Aqui está a chamada base com o Fable 5:
import anthropic
client = anthropic.Anthropic() # lê ANTHROPIC_API_KEY do ambiente
# Aumente max_retries acima do padrão de 2 para uma carga de trabalho em lote propensa a 429.
resilient = client.with_options(max_retries=5)
message = resilient.messages.create(
model="claude-fable-5",
max_tokens=4096,
messages=[
{"role": "user", "content": "Rascunhe um resumo de lançamento para nosso changelog de junho."}
],
)
print(message.content[0].text)
Se você precisar de controle explícito, por exemplo, para exibir um estado de "estamos ocupados, tentando novamente" em sua própria UI, você pode capturar a exceção tipada e ler o cabeçalho você mesmo:
import anthropic
client = anthropic.Anthropic()
try:
message = client.messages.create(
model="claude-fable-5",
max_tokens=4096,
messages=[{"role": "user", "content": "Resuma este relatório de incidente."}],
)
except anthropic.RateLimitError as exc:
wait_seconds = int(exc.response.headers.get("retry-after", "60"))
print(f"Limite de taxa atingido. Aguardando por {wait_seconds}s antes de tentar novamente.")
Além das retentativas, a correção duradoura para pressão sustentada é enfileirar. Se o seu tráfego for em rajadas, coloque as requisições em uma fila e drene-a a uma taxa que seu nível possa absorver, usando os cabeçalhos anthropic-ratelimit-*-remaining para controlar o ritmo da drenagem. Isso transforma uma parede de 429s em um pipeline suave e ligeiramente mais lento, que é quase sempre o que você realmente deseja. A mesma disciplina de limitação e enfileiramento aparece quando você testa qualquer API com limite de taxa, e os padrões em testar a API do ChatGPT com Apidog se transferem diretamente para o trabalho com Claude.
Aumentando seus limites e reduzindo a pressão
Quando você continua atingindo os limites, você tem duas alavancas: obter mais folga, ou precisar de menos.
Para obter mais folga, avance seu nível. Como os níveis se movem com as compras cumulativas de crédito, o uso real constante o leva automaticamente para cima na tabela, e cada etapa aumenta significativamente o RPM, ITPM e OTPM. Se você precisar saltar à frente do cronograma automático, ou precisar de limites personalizados ou empresariais, entre em contato com as vendas através da página de Limites no Console; o Nível Prioritário e o faturamento mensal existem precisamente para cargas de trabalho comprometidas e de alto volume.
Para precisar de menos folga, ataque o throughput de tokens em si:
- Use a API de Batches para trabalhos que não são sensíveis à latência. Ela processa requisições da API de Mensagens assincronamente a aproximadamente 50% do custo padrão, e tem seu próprio pool separado de limites de taxa, para que mantenha os trabalhos em massa de competir com seu tráfego interativo ao vivo.
- Ative o cache de prompt para contextos repetidos. Como os tokens de entrada em cache geralmente não contam para o ITPM, o armazenamento em cache de um grande prompt de sistema, conjunto de ferramentas ou documento de referência em um lote Fable 5 pode multiplicar sua taxa de transferência de entrada efetiva sem alterar seu nível. Observe sua taxa de acerto de cache na página de Uso para confirmar que está funcionando.
- Dimensionar corretamente o
max_tokens. Não há penalidade de OTPM para um teto alto, mas ummax_tokensgeneroso permite que uma única resposta se estenda e consuma OTPM por mais tempo. Defina-o para o que a tarefa realmente precisa. - Transmita saídas longas. O streaming protege você de timeouts de requisição em grandes gerações e permite que você observe a saída acumular em tempo real, o que se associa naturalmente à leitura dos cabeçalhos OTPM.
Essas técnicas se complementam. Um pipeline Fable 5 com cache, em lote e bem transmitido pode fazer muito mais trabalho dentro do mesmo nível do que um ingênuo. Para cargas de trabalho no estilo de agente especificamente, o passo a passo do agente Claude Fable 5 mostra como essas alavancas se encaixam em um loop de longa duração. E se você está comparando classes de modelo para um trabalho sensível ao throughput, o guia da API do Claude Opus 4.8 e as notas de preços do Opus 4.8 são pontos de referência úteis, já que cada classe de modelo tem seu próprio balde de limite separado.
Monitore seu uso do Fable 5 com Apidog
A maneira mais clara de entender seus limites reais é observá-los em requisições ao vivo, e um cliente de API torna isso concreto. Com o Apidog, você pode construir uma requisição Fable 5 contra a Messages API, enviá-la e inspecionar a resposta completa, incluindo os cabeçalhos anthropic-ratelimit-* e o objeto usage que informa a contagem de tokens de entrada, saída e em cache para essa chamada. Ver esses números lado a lado, requisição após requisição, informa exatamente o quão perto você está de atingir o ITPM e o OTPM, e o quanto o cache está realmente economizando, sem esperar por um 429 para descobrir.

Um ciclo prático enquanto você está construindo: envie um prompt representativo do Fable 5 no Apidog, leia anthropic-ratelimit-output-tokens-remaining e o valor de usage.output_tokens da resposta, e observe o quão rápido uma geração longa reduz a contagem restante. Em seguida, adicione um prompt de sistema em cache, envie novamente e confirme que usage.cache_read_input_tokens aumenta enquanto seu consumo de ITPM mal se move. Essa comparação de duas requisições transforma a tabela de níveis abstrata em uma sensação da sua própria capacidade. Você também pode salvar a requisição, variar max_tokens e observar como o consumo de OTPM rastreia a saída real em vez do seu limite, que é a maneira mais rápida de se convencer de que um max_tokens alto é seguro. Baixe o Apidog se você quiser executar esse experimento com sua própria chave e fique de olho nos cabeçalhos de resposta enquanto ajusta sua taxa de requisições. Equipes já padronizadas no Apidog para design e teste de API podem integrar o monitoramento do Fable 5 ao mesmo espaço de trabalho que usam para tudo o mais.
