Token budget por agente: o rate limiter que protege o seu orçamento

Rate limiter é problema resolvido em backend: cada requisição consome tokens de um balde que enche a taxa fixa; sem saldo, o servidor rejeita. O padrão segura picos e limita consumo excessivo por cliente. Com agentes de LLM, ele continua necessário, mas deixou de ser suficiente. Rate limit controla velocidade; token budget controla o total gasto. Um agente em loop abaixo do rate limit pode queimar caixa a noite inteira sem ver um único 429.

O mesmo algoritmo dos dois lados

Aqui a analogia nem precisa de esforço. A documentação da Anthropic declara que a API usa o algoritmo de token bucket, com capacidade reposta de forma contínua até o limite máximo. O mesmo mecanismo que times de backend implementam no gateway roda do lado de lá.

Os três provedores principais medem limites em eixos parecidos:

ITPM e OTPM, na nomenclatura da Anthropic, separam tokens de input e de output por minuto; no Gemini, o TPM conta input. Anthropic e OpenAI expõem headers com o estado atual (anthropic-ratelimit-*, x-ratelimit-*). E o playbook clássico funciona: ler os headers, aplicar backoff exponencial e respeitar o retry-after quando ele vier. Até aqui, o conhecimento de sistemas distribuídos transfere direto.

Onde a analogia quebra

Três pontos.

Taxa não é total. Rate limit limita tokens por minuto. Não limita tokens por tarefa, por cliente ou por mês. Um agente preso em loop a 50% dos limites de taxa passa em todos os checks do provedor. E ainda assim pode consumir o orçamento do mês em dias.

A chamada que custa é a que funciona. Em microserviço, 429 é backpressure saudável: a requisição rejeitada normalmente não gera cobrança e o retry costuma resolver. Com agente, o gasto perigoso vem das chamadas que dão certo. Cada iteração do loop devolve resposta bem formada, confiante e paga. Não existe erro pra tratar; existe fatura pra descobrir.

A granularidade é da conta, não do agente. A Anthropic declara que os limites existem pra reduzir overspend acidental e distribuir capacidade entre usuários. Só que o teto vale pra organização inteira, por modelo. Seu produto tem vários agentes e vários tenants dividindo o mesmo teto. O provedor não sabe qual agente gastou, e um agente descontrolado ainda rouba a banda dos outros. Atribuir gasto e repartir capacidade entre os seus agentes é problema seu.

Token budget: limite de estoque, não de taxa

Token budget é um teto de consumo acumulado, em tokens ou em dólares, por unidade que importa pro negócio: request, sessão, agente, tenant. O rate limiter repõe capacidade de forma contínua; o token budget só acumula, até cruzar o teto e bloquear a chamada seguinte. Um limita vazão; o outro, o acumulado.

As camadas, de dentro pra fora:

max_tokens é a camada mais barata e a mais esquecida. Na API da Anthropic, ele nem entra no cálculo de OTPM, que conta só os tokens de fato gerados. Ou seja: como controle de rate limit ele não ajuda, mas como teto do custo de output por chamada ele é o primeiro freio.

Na camada de sessão, o LiteLLM oferece teto de iterações e de gasto por sessão, amarrados a um trace ID. É o controle que mira exatamente o loop descontrolado: a sessão estoura o teto e o gateway rejeita as chamadas seguintes. Parar de verdade depende do agente tratar esse 429 como fim de tarefa, não como convite pra retry.

Na camada de chave, o token budget por chave virtual fecha o caso do agente: uma chave por agente, cada uma com teto próprio. Exemplo adaptado da doc do LiteLLM:

curl 'http://0.0.0.0:4000/key/generate' \
  --header 'Authorization: Bearer {master-key}' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "team_id": "whatsapp-bot",
    "max_budget": 10,
    "budget_duration": "30d"
  }'

Quando a chave cruza o max_budget, medido em dólares, as chamadas seguintes falham. O budget_duration reseta o acumulado no fim do período. Detalhe que morde: o default de max_budget é null, sem verificação nenhuma. O budget que ninguém configurou não existe.

Na ponta do provedor, a rede de segurança final. O console da Anthropic aceita spend limit configurável, com teto dado pelo seu tier. O Gemini aplica limite de gasto automático em janela móvel de 10 minutos, conforme o tier e o histórico de billing da conta. Útil, mas com a granularidade errada pro nosso problema: é freio de conta, não de agente.

Um post de abril de 2026 do AI Security Gateway propõe cinco estratégias no mesmo espírito, incluindo roteamento por classe de modelo e circuit breaker. E defende aplicar todas no gateway. O argumento central: enforcement no gateway independe de framework e o agente não consegue contornar. O agente que decide o próprio limite é o mesmo que entrou em loop.

Cache muda a conta

Um detalhe da doc da Anthropic conecta este artigo ao resto da série: pra maioria dos modelos Claude, só o input não cacheado conta no ITPM. Cache bem usado aumenta o throughput efetivo dentro do mesmo limite e reduz o custo do input repetido. O artigo sobre prompt caching, mais adiante na série, desce nesse detalhe.

Fechando

No vocabulário do artigo dos quatro eixos: rate limit do provedor administra a capacidade do lado de lá; token budget protege o seu eixo de custo. E budget estourado vira decisão de produto que a infra executa: falhar a chamada, degradar pra um modelo mais barato ou escalar pra um humano. Essas três saídas rendem artigos próprios nesta série, do LLM gateway ao kill switch de agente.

Comece pelo mínimo: max_tokens em toda chamada, uma chave por agente com max_budget definido, spend limit no console. São três controles. O runaway agent que eles seguram não avisa antes de acontecer.

Fontes

• Anthropic: Rate limits
• OpenAI: Rate limits
• Google: Gemini API rate limits
• LiteLLM: Budgets, Rate Limits
• LiteLLM: Agent Iteration Budgets
• AI Security Gateway: LLM Token Budget Strategies for Agents (2026)
• Wikipedia: Token bucket