Rate Limits da API do Claude: Estratégias que Funcionam

Um pipeline RAG que manda 4.000 tokens de system prompt mais 3.000 tokens de contexto recuperado por requisição esgota o teto de TPM do Claude 3.5 Sonnet cerca de 4x mais rápido do que a contagem de requisições indicaria. O problema raramente é requisições por minuto. É consumo de tokens por minuto, causado por decisões arquiteturais tomadas semanas antes de alguém notar o travamento.

TPM é o teto real, e tokens de input são o que mata

A Anthropic aplica três limites simultâneos: requisições por minuto (RPM), tokens de input por minuto (ITPM) e tokens de output por minuto (OTPM). Segundo a documentação oficial de rate limits da Anthropic, contas novas começam com limites menores nos três eixos, com aumentos disponíveis via console conforme o uso cresce.

A maioria das equipes olha para RPM porque é a unidade mais intuitiva: uma requisição, um tick no contador. O ITPM escala com o tamanho do contexto que você manda, não com o número de chamadas. Um pipeline que envia 7.000 tokens de contexto por chamada consome 7.000 ITPM por requisição. Uma conta Tier 1 com 500.000 ITPM aguenta aproximadamente 71 dessas requisições por minuto, não o teto de RPM.

O custo em tokens se acumula rápido em arquiteturas RAG. Imagine um chatbot de suporte ao cliente que carrega um system prompt base com persona, tom, políticas e regras de formatação, depois recupera 2 a 4 chunks de documentação por consulta. Se o system prompt tem 3.500 tokens e a recuperação adiciona 2.500 tokens de contexto, cada requisição queima 6.000 tokens de input antes mesmo de processar a mensagem do usuário. Com 50 sessões simultâneas, são 300.000 ITPM consumidos só em contexto, sobrando pouca margem para a conversa em si.

Tokens de output raramente são o gargalo em produção, porque a maioria das respostas é curta em relação ao contexto que exigiram. A proporção de input para output pode facilmente ser 5:1 ou 10:1, que é exatamente por isso o ITPM bate primeiro.

Resolver isso é um problema de arquitetura, não operacional. Antes de pensar em upgrade de tier ou em retry logic, a pergunta correta é: quanto desse contexto é realmente variável por requisição?

Prompt caching reduz consumo efetivo de TPM sem mudar de tier

O recurso de prompt caching da Anthropic permite marcar um prefixo do prompt como cacheável. Quando o mesmo prefixo aparece em requisições subsequentes dentro de uma janela de cache, a Anthropic cobra taxas de input significativamente menores pela porção em cache e, mais relevante para rate limits, tokens em cache contam de forma diferente no ITPM.

Voltando ao exemplo RAG: se o system prompt de 3.500 tokens é estático em todas as sessões, marcá-lo como prefixo cacheável faz com que o custo efetivo de ITPM dessa porção caia nos cache hits. Dependendo do padrão de requisições e da taxa de acerto do cache, isso pode cortar o consumo efetivo de TPM em 60 a 70% na parte estática do contexto, sem mudar tier, sem alterar estratégia de retry, sem mexer na lógica da aplicação.

A implementação exige que você estruture o prompt de forma que o conteúdo estático venha primeiro. O prefixo cacheável precisa aparecer no início do array de mensagens ou do system prompt, seguido do conteúdo dinâmico. Essa é uma restrição arquitetural, não um toggle de configuração. Equipes que tentam boltar o caching em um pipeline existente frequentemente descobrem que a construção do prompt mistura conteúdo estático e dinâmico de formas que tornam prefixos limpos impossíveis sem um refactor.

Janelas de cache atualmente duram cinco minutos para a maioria dos casos de uso. Para aplicações com tráfego em rajadas em vez de fluxo contínuo, a taxa de cache hits vai ser menor, o que reduz o benefício. Para pipelines com carga alta e contínua, a matemática é convincente o suficiente para que o caching no system prompt estático seja uma das primeiras otimizações avaliadas.

Um padrão que funciona bem na prática: separar o system prompt em um bloco estático grande (persona, políticas, formato de output, conhecimento de domínio) e um bloco dinâmico pequeno (contexto específico da sessão, data de hoje, nível do usuário). Cachear o bloco estático, mandar o bloco dinâmico sem cache. Para a maioria dos casos de uso empresarial, o bloco estático representa 70 a 90% dos tokens totais do system prompt.

Arquitetura de contexto antes de retry logic: onde a maioria erra a ordem

O conselho padrão para quem bate em rate limits segue mais ou menos esta sequência: implemente exponential backoff, faça cache de respostas onde possível, agrupe requisições em batch, considere upgrade de tier. Nenhum desses conselhos está errado, mas a ordem cria a impressão falsa de que o problema é operacional quando a causa raiz é quase sempre estrutural.

Exponential backoff resolve picos transitórios bem e vale implementar independentemente do perfil de carga. A Message Batches API da Anthropic suporta até 10.000 queries por batch com 50% de desconto no custo e janelas de processamento de 24 horas, o que é genuinamente útil para cargas de trabalho que não dependem de latência baixa: jobs noturnos de enriquecimento, classificação em bulk, geração de relatórios. São ferramentas boas. Elas não resolvem o problema de orçamento de tokens na raiz.

O design do retrieval é onde a conversa difícil acontece. Em pipelines RAG, a tentação é mandar mais contexto por requisição com a teoria de que mais informação produz respostas melhores. Isso é verdade até certo ponto, mas o ganho marginal de qualidade ao mandar 5.000 tokens de conteúdo recuperado versus 2.000 raramente é proporcional ao aumento de 2,5x no consumo de ITPM. Minha leitura, a partir de projetos onde instrumentei custo e qualidade ao mesmo tempo, é que a curva de retorno do contexto adicional dobra para baixo antes do que intuitivamente parece.

Abordagens práticas para avaliar antes de adicionar mais contexto:

• Chunking mais agressivo no retrieval: envie menos chunks, mais relevantes, em vez de janelas de contexto largas.
• Use um modelo mais leve, como Haiku (US$ 1,00/US$ 5,00 por milhão de tokens versus US$ 3,00/US$ 15,00 do Sonnet, segundo análise de preços da Finout de junho de 2026), para etapas de ranking ou classificação inicial, passando só o conteúdo selecionado para o modelo mais pesado.
• Separe o system prompt em camadas cacheáveis e não-cacheáveis antes de qualquer outra otimização.

Haiku também tem limites de rate padrão maiores que Opus exatamente porque custa menos por requisição. Usar Haiku em etapas do pipeline que não exigem as capacidades do Sonnet é uma escolha racional, não uma concessão de qualidade.

O contexto de expansão de capacidade que vale saber

Em maio de 2026, a Anthropic aumentou significativamente os rate limits padrão após um acordo de infraestrutura com a xAI. Os tokens de input por minuto do Tier 1 saltaram de 30.000 para 500.000, segundo análise do MindStudio. No evento para desenvolvedores da empresa, Dario Amodei atribuiu as restrições anteriores a um crescimento que não estava no planejamento: o uso cresceu aproximadamente 80x anualizado no primeiro trimestre de 2026 contra premissas de planejamento de 10x por ano.

Equipes que bateram em limites duros há seis meses podem descobrir que esses limites mudaram, o que torna os valores de tier algo que vale conferir no console antes de investir tempo de engenharia em soluções alternativas que talvez não sejam mais necessárias. Mesmo assim, o conselho estrutural acima permanece válido independentemente dos valores absolutos de tier, porque eficiência arquitetural se acumula. Um pipeline com prompt caching bem configurado e contexto bem dimensionado fica mais barato e rápido à medida que o uso escala, mesmo quando os limites brutos são generosos.

A Anthropic também oferece um nível de serviço Priority Tier com SLA de 99,5% de uptime, compute priorizado e gasto previsível, segundo a documentação oficial. Para sistemas em produção onde variância de latência causa problemas visíveis para o cliente, esse tier vale ser avaliado como linha de orçamento antes de investir tempo de engenharia em infraestrutura complexa de retry.

Na prática

No contexto de e-commerce, pipelines que consomem a API do Claude tendem a aparecer em dois lugares: geração de conteúdo de produto em bulk e agentes de suporte ao cliente. Os dois têm perfis de consumo de token completamente diferentes e erros opostos.

Geração de conteúdo em bulk bate no ITPM quando o system prompt carrega todo o guia de tom de voz da marca, regras de SEO, exemplos de títulos aprovados e especificações de formato em cada requisição individual. Esse bloco é 100% estático. Cachear ele é a primeira coisa a fazer, não a última.

Agentes de suporte têm um problema diferente: a recuperação de contexto. Cada pergunta do usuário dispara uma busca em base de conhecimento que devolve chunks inteiros de FAQ, manuais e políticas, independentemente da relevância. Instrumentar o tamanho médio do contexto recuperado e correlacionar com a qualidade das respostas quase sempre revela que metade do contexto recuperado não contribui para a resposta, só para a conta de ITPM. Reduzir o número de chunks ou aumentar o limiar de similaridade antes de tentar qualquer outra otimização resolve mais do que parece.

Se você usa system prompts bem estruturados, a separação entre bloco estático e dinâmico provavelmente já está implícita na sua arquitetura, só falta torná-la explícita no nível de caching.

FAQ

Minha assinatura Claude Pro ou Max conta para os rate limits da API?

Não. Planos de assinatura (Pro, Max, Team) são separados do acesso à API. Usar o Claude via API significa pagar por token, independentemente de ter assinatura. Os créditos da assinatura não se transferem para uso de API, e a cobrança é independente, governada pelos tiers de uso configurados no console da Anthropic.

Qual a diferença entre RPM, ITPM e OTPM?

RPM limita o número de requisições por minuto. ITPM limita o total de tokens de input por minuto em todas as requisições. OTPM limita o total de tokens de output por minuto. Os três se aplicam simultaneamente, então você pode bater no teto de ITPM muito antes de chegar perto do teto de RPM se suas requisições carregam contextos grandes. Os valores atuais por tier e modelo estão na página oficial de rate limits.

Prompt caching reduz consumo de TPM ou só reduz custo?

Os dois. Cache hits reduzem tanto o custo quanto o consumo efetivo de ITPM para os tokens em cache. O benefício é real nas duas dimensões, mas exige um prefixo estável e estático, além de frequência de requisições suficiente para gerar cache hits consistentes dentro da janela de cinco minutos. Cargas de trabalho esparsas ou de baixa frequência têm taxas de cache hit menores e, portanto, menos alívio de TPM.

Devo usar a Message Batches API para evitar rate limits?

Batches são úteis para cargas de trabalho que toleram até 24 horas de delay no processamento e se beneficiam do desconto de 50% no custo. Casos de uso em tempo real ou interativos são um problema diferente, e batching não ajuda aí. Para esses pipelines, arquitetura de contexto e prompt caching são as alavancas certas.

Equipes que lidam bem com rate limits tendem a ter incluído o orçamento de contexto na conversa inicial de design do pipeline, não na retrospectiva pós-incidente. Quando um pipeline bate no teto de TPM em produção, as decisões arquiteturais que causaram isso costumam ter meses de idade e são caras de desfazer.