Como Funcionam os Limites de Requisição do Claude Fable 5

Se você está desenvolvendo com o modelo mais recente da Anthropic e precisa planejar os limites de taxa do Claude Fable 5, comece por aqui: a Anthropic não lançou um limite separado e exclusivo para o Fable 5 no lançamento. O Fable 5 (claude-fable-5, 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 API de Mensagens padrão e os limites de taxa por nível da sua organização. Na prática, você deve dimensionar sua aplicação com base no nível de uso da sua conta, não em um número fixo do modelo. Se você ainda está avaliando o modelo, leia também a visão geral do Claude Fable 5.

Experimente o Apidog hoje

TL;DR

O Claude Fable 5 usa os limites de taxa padrão da Anthropic, baseados em níveis:

• RPM: requisições por minuto.
• ITPM: tokens de entrada por minuto.
• OTPM: tokens de saída por minuto.

Esses limites são aplicados por organização e por classe de modelo. Eles aumentam conforme seus gastos cumulativos movem sua conta entre os níveis 1 a 4. Para produção, sempre confirme os números reais no Console da Anthropic e trate erros 429 usando o cabeçalho retry-after.

Como os limites de taxa da Anthropic funcionam

A Anthropic não trabalha com um único “limite global” para toda a API. Ela usa um sistema de níveis de uso. Seu nível define quanto throughput sua organização pode consumir.

Existem dois conceitos relacionados:

1. Limites de gastos: quanto sua organização pode gastar no mês civil.
2. Limites de taxa: com que velocidade sua aplicação pode chamar a API.

Este artigo foca nos limites de taxa, mas os dois conceitos estão conectados porque o mesmo sistema de níveis influencia ambos.

Tipos de limite que você precisa monitorar

Para a API de Mensagens, a Anthropic mede os limites em três dimensões.

1. RPM: requisições por minuto

O RPM define quantas chamadas separadas sua organização pode iniciar por minuto.

Exemplo prático: se sua aplicação dispara muitas chamadas pequenas em paralelo, você pode atingir o RPM mesmo com baixo uso de tokens.

2. ITPM: tokens de entrada por minuto

O ITPM mede quantos tokens de entrada você envia por minuto.

Na maioria dos modelos atuais, tokens de entrada lidos do cache de prompt não contam para o ITPM. Isso torna o cache importante quando você reutiliza:

• prompts de sistema longos;
• definições de ferramentas;
• documentos de referência;
• instruções fixas de agente.

3. OTPM: tokens de saída por minuto

O OTPM mede quantos tokens o modelo gera por minuto.

Esse limite é avaliado em tempo real enquanto a resposta é produzida. O valor de max_tokens não é cobrado antecipadamente contra o OTPM. Apenas os tokens realmente gerados contam.

Isso significa que:

max_tokens=8192

não consome 8.192 tokens automaticamente. Mas se o modelo gerar uma resposta longa, esses tokens reduzirão seu orçamento de OTPM conforme forem produzidos.

Por que rajadas causam 429 mesmo com média baixa

A Anthropic aplica limites usando um algoritmo de balde de tokens. A capacidade é recarregada continuamente, não apenas no início de cada minuto.

Na prática, um limite como 50 RPM pode se comportar como algo próximo de uma requisição por segundo. Se você enviar 20 chamadas ao mesmo tempo, pode receber 429, mesmo que sua média por minuto pareça aceitável.

Para evitar isso:

• distribua chamadas ao longo do tempo;
• use filas;
• limite concorrência;
• leia os cabeçalhos anthropic-ratelimit-*;
• aplique backoff quando receber 429.

Limites são por organização e por classe de modelo

Dois detalhes são importantes para implementação.

Primeiro, os limites são definidos no nível da organização, não por chave de API. Todas as chaves da organização compartilham o mesmo pool. Você pode definir limites menores por workspace se quiser isolar ambientes ou times.

Segundo, os limites são aplicados por classe de modelo. O tráfego do Fable 5 usa um balde separado de outras classes, como Opus. Isso permite executar diferentes classes de modelo ao mesmo tempo sem que uma consuma diretamente o limite da outra.

Como os níveis avançam

Os níveis aumentam automaticamente conforme suas compras cumulativas de crédito cruzam os limites publicados pela Anthropic.

A estrutura publicada é:

• Nível 1: desbloqueado com compra de crédito de US$ 5.
• Nível 2: US$ 40 acumulados.
• Nível 3: US$ 200 acumulados.
• Nível 4: US$ 400 acumulados.

Cada etapa aumenta os tetos mensais de gasto e os limites de taxa. Você avança quando cruza o limite; não precisa abrir ticket.

Acima do Nível 4, limites maiores normalmente passam por vendas ou faturamento mensal.

Para entender como isso se relaciona ao custo do modelo, veja a análise de preços do Claude Fable 5.

O que isso significa para o Claude Fable 5

O Fable 5 não tem uma estrutura de limite especial. Ele entra na tabela padrão da Anthropic como sua própria classe de modelo.

Então a pergunta correta não é:

“Qual é o limite fixo do Fable 5?”

A pergunta correta é:

“Qual é o nível da minha organização e quais são os limites do Fable 5 nesse nível?”

De acordo com os limites de taxa publicados pela Anthropic, a linha do Fable 5 escala aproximadamente assim:

Nível	RPM	ITPM	OTPM
Nível 1	50	100.000	20.000
Nível 2	1.000	500.000	100.000
Nível 3	2.000	1.500.000	300.000
Nível 4	4.000	4.000.000	800.000

Trate esses números como referência estrutural, não como contrato. A Anthropic pode atualizar tabelas, contas empresariais podem ter arranjos diferentes e o Console da Anthropic é sempre a fonte da verdade.

O limite mais crítico para Fable 5 costuma ser OTPM

O Fable 5 é voltado a tarefas longas, incluindo execuções com muitos tokens e agentes que trabalham por mais tempo.

Nesse tipo de uso, o gargalo geralmente não é RPM. É OTPM.

Exemplo:

• você inicia poucos jobs;
• cada job gera uma resposta longa;
• as respostas são transmitidas por bastante tempo;
• o consumo de tokens de saída permanece alto por vários minutos.

Nesse cenário, mesmo com poucas requisições, você pode atingir o OTPM.

Para reduzir risco:

1. Defina max_tokens com base no tamanho real esperado da resposta.
2. Use streaming para respostas longas.
3. Controle concorrência de jobs longos.
4. Monitore anthropic-ratelimit-output-tokens-remaining.

Se você está conectando o modelo pela primeira vez, o guia da API do Claude Fable 5 mostra o formato da requisição.

Como verificar seus limites reais

Não dimensione produção apenas com base em uma postagem de blog. Verifique os números reais da sua organização.

Você tem duas fontes principais.

1. Console da Anthropic

No Console da Anthropic, verifique:

• o nível atual da organização;
• os limites de taxa por modelo;
• gráficos de uso;
• consumo de tokens de entrada;
• consumo de tokens de saída;
• taxa de acerto de cache.

Use essa tela antes de aumentar tráfego, ativar novos workers ou liberar uma feature para mais usuários.

2. Cabeçalhos de resposta da API

Cada chamada retorna cabeçalhos anthropic-ratelimit-*.

Monitore estes campos:

anthropic-ratelimit-requests-limit
anthropic-ratelimit-requests-remaining

anthropic-ratelimit-input-tokens-limit
anthropic-ratelimit-input-tokens-remaining

anthropic-ratelimit-output-tokens-limit
anthropic-ratelimit-output-tokens-remaining

Também existem cabeçalhos *-reset em formato RFC 3339, indicando quando o balde será totalmente reabastecido.

Exemplo de lógica de monitoramento:

def log_rate_limits(response):
    headers = response.headers

    print("RPM restante:", headers.get("anthropic-ratelimit-requests-remaining"))
    print("ITPM restante:", headers.get("anthropic-ratelimit-input-tokens-remaining"))
    print("OTPM restante:", headers.get("anthropic-ratelimit-output-tokens-remaining"))

Ler esses valores permite que seu cliente desacelere antes de receber 429.

Como lidar com erros 429

Um erro 429 significa que você atingiu um limite de taxa.

A resposta inclui um cabeçalho importante:

retry-after

Esse valor informa quantos segundos você deve aguardar antes de tentar novamente. Se você tentar antes, a nova chamada provavelmente falhará também.

Use as retentativas do SDK

Os SDKs oficiais da Anthropic já fazem retentativas automáticas para respostas 429 e 5xx, com backoff exponencial. Por padrão, são duas tentativas.

Exemplo em Python:

import anthropic

client = anthropic.Anthropic()  # lê ANTHROPIC_API_KEY do ambiente

# Aumente max_retries para cargas em lote mais propensas 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)

Para a maioria das aplicações, isso é suficiente. Evite criar um loop manual de retry se o SDK já cobre seu caso.

Controle manual quando necessário

Se você precisa mostrar estado na UI, registrar métricas específicas ou controlar uma fila, capture a exceção tipada:

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. "
        f"Aguardando {wait_seconds}s antes de tentar novamente."
    )

Use fila para tráfego em rajadas

Retentativas resolvem falhas temporárias. Para pressão sustentada, use fila.

Um padrão simples:

1. Receba as requisições do usuário.
2. Coloque-as em uma fila.
3. Drene a fila com concorrência controlada.
4. Ajuste a taxa com base nos cabeçalhos anthropic-ratelimit-*-remaining.
5. Reagende itens que receberem 429 usando retry-after.

Pseudoestrutura:

while queue.has_items():
    if rate_limit_budget_is_low():
        sleep_until_reset_or_retry_after()
        continue

    job = queue.pop()
    process_fable_5_job(job)

Esse padrão transforma uma sequência de erros 429 em um pipeline mais previsível.

Os mesmos princípios de teste e limitação aparecem ao trabalhar com outras APIs. Os padrões em testar a API do ChatGPT com Apidog também se aplicam ao Claude.

Como aumentar limites ou reduzir consumo

Quando você atinge limites com frequência, há duas estratégias:

1. Conseguir mais capacidade.
2. Consumir menos tokens por unidade de trabalho.

1. Aumente seu nível

Como os níveis sobem com compras cumulativas de crédito, uso constante leva sua conta para níveis maiores. Cada etapa aumenta RPM, ITPM e OTPM.

Se você precisa antecipar esse crescimento ou obter limites personalizados, use a página de Limites no Console para falar com vendas. Nível Prioritário e faturamento mensal existem para cargas de trabalho maiores e mais previsíveis.

2. Use Batches para jobs assíncronos

Para tarefas que não exigem baixa latência, use a API de Batches.

Ela processa requisições da API de Mensagens de forma assíncrona, com aproximadamente 50% do custo padrão, e possui um pool separado de limites de taxa.

Use Batches para:

• processamento de documentos;
• classificação em massa;
• geração offline;
• análises que podem esperar;
• tarefas recorrentes de backoffice.

3. Ative cache de prompt

Se você reutiliza contexto, cache de prompt pode reduzir pressão sobre ITPM.

Bons candidatos:

• prompt de sistema longo;
• políticas internas;
• documentação fixa;
• catálogo de ferramentas;
• instruções de agente;
• documentos de referência usados em várias chamadas.

Depois de ativar, confira no Console se a taxa de acerto de cache está subindo.

4. Ajuste max_tokens

Um max_tokens alto não consome OTPM antecipadamente, mas permite que uma resposta longa continue gerando tokens por mais tempo.

Defina o valor com base no que a tarefa precisa.

Exemplo:

# Resumo curto
max_tokens = 512

# Relatório detalhado
max_tokens = 4096

# Execução longa com agente
max_tokens = 8192

Use limites diferentes por tipo de tarefa, em vez de um único valor alto para tudo.

5. Use streaming para respostas longas

Streaming ajuda em dois pontos:

• reduz risco de timeout em gerações grandes;
• permite observar a saída enquanto o modelo gera.

Exemplo conceitual:

import anthropic

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-fable-5",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": "Gere um plano técnico detalhado para migração de API."
        }
    ],
) as stream:
    for text in stream.text_stream:
        print(text, end="")

Para cargas no estilo de agente, o passo a passo do agente Claude Fable 5 mostra como essas alavancas se encaixam em um loop de longa duração.

Se você está comparando classes de modelo para workloads sensíveis a throughput, veja também o guia da API do Claude Opus 4.8 e as notas de preços do Opus 4.8.

Monitore seu uso do Fable 5 com Apidog

A forma mais prática de entender seus limites reais é observar requisições ao vivo.

Com o Apidog, você pode montar uma chamada para o Fable 5 na Messages API, enviar a requisição e inspecionar a resposta completa, incluindo:

• cabeçalhos anthropic-ratelimit-*;
• objeto usage;
• tokens de entrada;
• tokens de saída;
• tokens lidos do cache.

Isso permite ver, chamada por chamada, quão perto você está de atingir ITPM ou OTPM.

Um fluxo simples de teste:

1. Crie uma requisição Fable 5 no Apidog.
2. Envie um prompt representativo.
3. Leia anthropic-ratelimit-output-tokens-remaining.
4. Compare com usage.output_tokens.
5. Aumente ou reduza max_tokens.
6. Repita com cache de prompt.
7. Verifique se usage.cache_read_input_tokens aumenta.
8. Observe se o consumo de ITPM diminui.

Esse teste transforma a tabela de limites em dados concretos da sua própria aplicação.

Você pode baixar o Apidog para executar esse experimento com sua chave e acompanhar os cabeçalhos de resposta enquanto ajusta sua taxa de requisições. Equipes que já usam o Apidog para design e teste de APIs podem adicionar o monitoramento do Fable 5 ao mesmo workspace.