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.

As camadas, de dentro pra fora:

max_tokens é a camada mais barata. 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.

Os três controles pra configurar hoje

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