Rate limiting em APIs de IA opera em múltiplas dimensões simultaneamente, e entender cada uma previne muita frustração. A maioria dos provedores aplica pelo menos dois limites: requisições por minuto (RPM) e tokens por minuto (TPM). RPM limita quantas chamadas de API você pode fazer independentemente do tamanho — o plano gratuito da Anthropic pode permitir 5 RPM, enquanto planos pagos oferecem mais de 1.000 RPM. TPM limita o volume total de tokens (entrada + saída) fluindo por minuto. Você pode atingir qualquer limite independentemente. Uma surpresa comum: você está bem abaixo do seu limite de RPM mas atingindo TPM porque está enviando prompts longos com janelas de contexto grandes. Alguns provedores também aplicam requisições por dia (RPD) e tokens por dia (TPD), criando um teto diário que reinicia à meia-noite UTC.
A mecânica de como provedores aplicam esses limites segue alguns padrões padrão. O mais comum é o algoritmo de token bucket (ou seu primo próximo, janela deslizante). Imagine um balde que comporta, digamos, 60 tokens de capacidade. Ele se reabastece a uma taxa de um por segundo. Cada requisição drena do balde proporcionalmente à sua contagem de tokens. Se o balde está vazio, sua requisição é rejeitada com um HTTP 429 (Too Many Requests). Os headers de resposta dizem o que você precisa saber: x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-reset-requests, e seus equivalentes de tokens. Código de cliente inteligente lê esses headers proativamente em vez de esperar receber um 429. Anthropic, OpenAI e a maioria dos outros provedores incluem esses headers em cada resposta.
Quando você é rate-limited, a abordagem padrão é exponential backoff com jitter. Espere 1 segundo após o primeiro 429, depois 2 segundos, depois 4, depois 8 — e adicione um componente aleatório (jitter) para que se 50 dos seus workers paralelos todos receberam 429 ao mesmo tempo, não tentem todos novamente no mesmo instante e recebam 429 de novo imediatamente. A maioria dos SDKs de provedores (SDK Python da Anthropic, SDK da OpenAI) lida com lógica básica de retry automaticamente, mas sistemas de produção geralmente precisam de abordagens mais sofisticadas: filas de requisição com níveis de prioridade, rate limiting adaptativo que limita proativamente com base na cota restante, e circuit breakers que falham rápido quando um provedor está claramente sobrecarregado em vez de acumular mais retries.
As implicações estratégicas dos rate limits moldam como aplicações sérias são arquitetadas. Se você precisa processar 100.000 documentos pelo Claude, não pode simplesmente disparar 100.000 chamadas de API concorrentes. Você precisa gerenciar concorrência, provavelmente rodando 20-50 requisições paralelas e alimentando-as de uma fila. A Anthropic oferece uma Batch API com um limite de taxa separado e mais alto com 50% de desconto no custo — projetada especificamente para esse caso de uso. A OpenAI tem um endpoint de batch similar. Para aplicações que precisam de capacidade garantida, planos enterprise e acordos de uso comprometido oferecem throughput dedicado protegido do pool compartilhado. A realidade não dita é que rate limits não são apenas sobre justia — são sobre alocação de GPU. Cada requisição que você faz exige tempo de GPU, e provedores só podem atender tantas requisições concorrentes quantas GPUs tiverem. Rate limits são o mecanismo que mantém oferta e demanda em equilíbrio.