💻 computer science

Token Budgets: An Empirical Catalog of 63 LLM-Agent Budget-Overrun Incidents, with an Affine-Typed Rust Mitigation as a Case Study

Este artigo apresenta um catálogo empírico de 63 excessos de orçamento de tokens em agentes de LLM e introduz o "token-budgets", uma crate de Rust com tipagem segura que utiliza propriedade afim para impor limites de gastos não contornáveis em tempo de compilação, prevenindo efetivamente as explosões de custos relacionadas à delegação que assolam soluções ad-hoc em tempo de execução.

Autores originais: Sajjad Khan

Publicado 2026-06-04

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Sajjad Khan

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

O Problema: O "Bug de Dinheiro Infinito" na IA

Imagine que você contrata um robô assistente para fazer algum trabalho para você. Você dá a ele uma regra estrita: "Não gaste mais de US$ 10 no meu cartão de crédito."

No entanto, o robô fica confuso. Ele entra em um loop, tentando resolver um problema repetidamente. Como o robô não possui um "botão de parada" integrado que verifica o preço antes de fazer uma chamada, ele continua gastando. Quando você acorda na manhã seguinte, o robô não gastou apenas seus US$ 10; ele gastou US$ 10.000.

Este artigo chama isso de "Estouro de Orçamento" (Budget Overrun). Os autores encontraram 63 exemplos reais disso acontecendo entre 2023 e 2026 em diversos frameworks de IA. Em alguns casos, usuários perderam milhares de dólares porque o software não interrompeu o gasto antes que ele ocorresse.

As Soluções Atuais: O Alarme "Depois do Fato"

A maioria das empresas atualmente tenta corrigir isso colocando um "segurança" que observa o gasto depois que o robô já fez a chamada.

A Analogia: Imagine que você vai a uma loja, compra 1.000 itens e, então, o caixa te para na porta e diz: "Opa, isso passou do seu limite!" Você ainda tem que pagar pelos itens que já pegou, ou tem que correr de volta para a prateleira para colocá-los de volta.
O Ponto do Artigo: Essas correções atuais são muito lentas. Elas detectam o erro, mas não evitam o dano.

A Nova Solução: A "Carteira Mágica" (Orçamentos de Tokens)

Os autores construíram uma nova ferramenta chamada Orçamentos de Tokens (escrita em uma linguagem de programação chamada Rust). Em vez de um segurança observando o gasto, eles mudaram a própria carteira.

A Analogia:
Imagine que você dá ao robô uma carteira física contendo exatamente US$ 10 em dinheiro vivo.

Sem Cópias: A carteira é feita de um material especial que não pode ser fotocopiado. O robô não pode fazer 100 cópias da carteira para gastar US$ 1.000.
Sem Duplo Gasto: Uma vez que o robô tira uma nota de US$ 1 para comprar algo, essa nota sumiu. Ele não pode colocar a mesma nota de volta no bolso e gastá-la novamente.
Sem Compartilhamento: Se o robprô dividir a carteira em duas carteiras menores para dar a dois ajudantes, a carteira original desaparece. Os ajudantes não podem voltar à carteira original para pegar mais dinheiro.

No mundo do código de computador, isso é chamado de "Propriedade Afim" (Affine Ownership). Isso força o computador a verificar as regras antes mesmo de o robô sair de casa. Se o robô tentar quebrar as regras (como copiar a carteira), o computador recusa-se a deixar o programa rodar de forma alguma. É como um segurança de boate que checa seu RG antes de você entrar; se você não tiver, você nem chega ao bar para pedir uma bebida.

O Que Eles Realmente Provaram

O artigo faz três afirmações principais, as quais testaram cuidadosamente:

O Catálogo de Falhas: Eles criaram um "Mural da Vergonha" listando 63 incidentes específicos onde agentes de IA tiveram gastos desenfreados. Eles também encontraram mais 47 casos onde desenvolvedores admitiram: "Ainda não temos uma maneira de impedir isso". Isso prova que o problema é real e acontece com frequência.
A "Carteira Mágica" Funciona: Eles testaram sua nova ferramenta Rust contra outras cinco formas populares de gerenciar custos de IA.
- O Resultado: Quando tentaram enganar o sistema para gastar demais (criando uma "condição de corrida" onde dois agentes tentam gastar o mesmo dinheiro ao mesmo tempo), os outros sistemas falharam 100% das vezes. O novo sistema de "Carteira Mágica" falhou zero vezes.
- Por quê? Porque os outros sistemas dependem que o programador se lembre de escrever um "bloqueio" para evitar o duplo gasto. Se o programador esquecer, o dinheiro vaza. O novo sistema força o programador a seguir as regras, ou o código sequer compila (não se transforma em um programa funcional).
Não é uma Solução Mágica para Tudo: Os autores são muito honestos sobre os limites.
- Só funciona em Rust: Esta "Carteira Mágica" específica só funciona se você estiver escrevendo seu software na linguagem de programação Rust. Não funciona para Python ou JavaScript (embora tenham feito uma versão em Python que age como um segurança normal, não como uma carteira mágica).
- Depende da empresa de IA: O sistema estima quanto uma tarefa custará. Se a empresa de IA (como OpenAI ou Anthropic) cobrar mais do que disse ou esconder alguns custos de "pensamento" (thinking costs), o sistema ainda pode se confundir. Ele confia na conta que recebe, mas se a conta estiver errada, a carteira pode secar.

A Conclusão

Este artigo diz: "Agentes de IA são perigosos atualmente porque podem acidentalmente esvaziar sua conta bancária. Encontramos 63 exemplos disso. Construímos uma nova ferramenta que usa regras de computador estritas para tornar impossível que o código acidentalmente copie ou duplique o dinheiro. Funciona perfeitamente para prevenir esses tipos específicos de erros, mas só funciona se você estiver usando a linguagem de programação Rust e se as empresas de IA disserem a verdade sobre seus preços."

Em resumo: Eles não construíram apenas um sistema de alarme melhor; eles construíram uma carteira que fisicamente não pode ser roubada ou duplicada.

Resumo Técnico: Orçamentos de Tokens

Definição do Problema
Extrapolações de orçamento em agentes de LLM representam uma classe documentada de falha em produção, onde loops de tentativa (retry loops) ilimitados ou padrões de delegação acumulam milhares de dólares em custos antes da detecção. As mitigações existentes são predominantemente mecanismos de tempo de execução (ex: callbacks do AgentGuard, orçamentos de proxy do LiteLLM) que rastreiam o gasto após uma chamada de API ter sido comprometida ou rejeitada na camada de rede. Essas abordagens falham em prevenir a condição de corrida "M-delegation-fanout", onde subagentes concorrentes ignoram um orçamento compartilhado devido à falta de atomicidade ou aliasing no código do operador. Além disso, muitos frameworks carecem inteiramente de um primitivo de orçamento de primeira classe, levando a lacunas estruturais onde o controle de custos está ausente ou é implementado via wrappers ad-hoc.

Metodologia
O artigo emprega uma abordagem de métodos mistos combinando engenharia de software empírica e implementação de sistemas:

Construção de Catálogo Empírico: Os autores construíram um catálogo de 110 entradas extraídas de 21 subprojetos de agentes de LLM em 18 ecossistemas (2023–2026). Isso inclui 63 incidentes confirmados em produção (extrapolações relatadas por usuários com evidência de perda financeira) e 47 entradas estruturais suplementares (lacunas reconhecidas pelos mantenedores ou solicitações de recursos). O catálogo foi validado via um estudo de confiabilidade inter-avaliador (IRR) independente por dois humanos, atingindo um coeficiente de Cohen $\kappa = 0,837$ no esquema de classificação de quatro classes.
Taxonomia de Falhas: Os incidentes foram organizados em oito clusters de mecanismos arquiteturais exploratórios, incluindo M-retry-loop, M-cost-observability, M-delegation-fanout e M-budget-primitive-missing.
Design de Mitigação (Orçamentos de Tokens): Os autores implementaram o token-budgets, um crate em Rust de 1.180 linhas que operacionaliza a posse afina (affine ownership) para gestão de orçamento. O tipo central Budget não é clonável nem copiável. Operações principais (spend, split, merge) consomem o orçamento por valor, impondo via verificador de empréstimos (borrow checker) do Rust que:
- Um orçamento não pode ser com um alias (aliasing).
- Um orçamento não pode ser gasto duas vezes (use-after-move).
- Um orçamento não pode ser usado após ser delegado (split).
- O limite de dólares é imposto via aritmética de tempo de execução (checked_sub) baseada em um estimador estratificado por provedor (ex: comprimento em bytes para OpenAI, consciente de loops de ferramentas para Anthropic).
Avaliação: O sistema foi avaliado contra cinco runtimes de produção (LangGraph, CrewAI, AutoGen, callbacks estilo AgentGuard, LiteLLM) e trabalho concorrente (Agent Contracts) através de três provedores. Os experimentos incluíram:
- Integridade em Tempo de Compilação: 9 testes trybuild verificando que padrões ruidosos (clonagem, gasto duplo) falham na compilação.
- Experimento do Operador Esquecido: Uma comparação de uma implementação ruidosa em Python (ultrapassa 30/30) contra Python disciplinado (com lock), Rust affine, e implementações Rust com shared-mutex.
- Varreduras de API ao Vivo: Testes estratificados por temperatura ( $T \in \{0.0, 0.3, 0.7, 1.0\}$ , $N=160$ ) e testes de teto de sub-piso para verificar zero extrapolação e zero recusas falsas.
- Solidez do Estimador: Validação dos estimadores estáticos e adaptativos contra o faturamento real do provedor.

Principais Contribuições

Catálogo Empírico: A primeira taxonomia de extrapolações de orçamento de agentes de LLM validada por inter-avaliador, documentando 63 incidentes confirmados e 47 lacunas estruturais em 21 frameworks. Isso estabelece a recorrência da classe de falha, particularmente o padrão M-budget-primitive-missing.
Disciplina de Orçamento Afim: Uma implementação em Rust que desloca a integridade do orçamento da disciplina de tempo de execução para a imposição em tempo de compilação. Ao tratar o orçamento como um valor afim, o sistema evita aliasing e gasto duplo no nível de tipo, garantindo que a condição de corrida "M-delegation-fanout" seja um erro de compilação em vez de um risco de tempo de execução.
Avaliação Operacional: Uma demonstração direta de que, embora alternativas de tempo de execução (contadores adequadamente travados/locked) possam alcançar o mesmo resultado de respeito ao teto, a disciplina afim garante unicamente a impossibilidade de bypass sob erro do operador em delegação multi-agente. A avaliação mostra que a implementação em Rust atinge 0/30 extrapolações, enquanto as bases ruidosas alcançam 30/30.

Resultos

Integridade: A suíte trybuild confirmou que todas as três classes de circunvenção de teto (aliasing, gasto duplo, uso após split) resultam em erros de compilação com diagnósticos específicos do rustc.
Comportamento de Respeito ao Teto: Em testes de API ao vivo ( $N=160$ ), a implementação Rust registrou zero violações de teto e zero recusas falsas. No experimento "Forgetful-Operator", a linha de base ruidosa em Python extrapolou o teto 30/30 vezes, enquanto a implementação affine de Rust extrapolou 0/30 vezes.
Comparação com Alternativas de Tempo de Execução: Quando os operadores implementam corretamente o travamento (locking) em Python ou Rust, o resultado de respeito ao teto é idêntico ao da abordagem afim. O valor distintivo do tipo afim é que ele torna o padrão incorreto (ruidoso) impossível de compilar, removendo o fardo da disciplina de concorrência do operador.
Desempenho do Estimador: O estimador padrão de comprimento de bytes reserva de 4 a 6 vezes o custo real. O AdaptiveEstimator reduz isso para uma mediana de 2.11× com latência desprezível, enquanto a estimativa direta via tokenizer atinge aproximadamente 1.0× ao custo de cerca de 1 segundo de latência por gasto.
Implantação: Uma única implantação de produção no framework Rig demonstrou a abordagem impondo um teto de sessão rígido através de subagentes concorrentes com zero extrapolação.

Alegações e Significância
O artigo posiciona sua contribuição modestamente como um estudo de engenharia de software empírica com um caso de estudo de sistemas específico:

Escopo da Alegação: Os autores declaram explicitamente que não reivindicam uma prova formal de solidez de teto em nível binário (a Conjectura 1 permanece aberta). As garantias de integridade são de nível de código-fonte (impostas pelo borrow checker em código tipado). O teto de dólares é uma propriedade aritmética de tempo de execução condicional às suposições do estimador (A1) e à veracidade do provedor (A7).
Valor Primário: A significância reside em abordar o modo de falha M-budget-primitive-missing estruturalmente. Para frameworks que carecem de um primitivo de orçamento, uma reimplementação em Rust usando token-budgets não pode regredir silenciosamente ou expor o orçamento apenas via callbacks.
Limitações: A abordagem é específica para implantações de agentes em Rust (uma minoria do ecossistema atual). Ela não resolve o erro de relatório de faturamento do lado do provedor, tokens de raciocínio ocultos em modelos de raciocínio (série OpenAI o, Anthropic extended-thinking) ou orçamento multi-tenant entre processos sem um serviço distribuído.
Conclusão: O artigo conclui que, embora as alternativas de tempo de execução possam alcançar o mesmo resultado operacional se escritas corretamente, a disciplina afim fornece uma garantia de "não-bypass" contra o erro do operador em delegação multi-agente, tornando-a o primitivo preferencial para novas implantações de agentes em Rust que exigem limites cumulativos de sessão. O catálogo serve como evidência de que esses modos de falha recorrem em todo o ecossistema, independentemente da linguagem de implementação.