Seu agente continua trabalhando. Mas ainda está avançando?

Cento e treze vezes. Duzentos e cinquenta e quatro vezes. Um relato que circulou no TLDR descreve execuções de agentes de código que repetiram a mesma consulta SQL bem-sucedida centenas de vezes seguidas. O número exato não é o ponto — sem o texto completo da fonte original, o episódio serve apenas como ilustração do absurdo. O ponto é a diferença entre um agente que "ainda está rodando" e um agente que "ainda está progredindo". Atividade intensa, resultado que não muda. O runtime consome orçamento de API, a máquina gasta ciclos, o relógio avança, e o estado do problema continua exatamente no mesmo lugar de vinte turnos atrás.

O paper TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents (Li et al., UC Berkeley, Microsoft Research e Microsoft Security, arXiv:2610.22732) ataca esse desperdício em sequências reais de tarefas. O desenho experimental foge do laboratório de tarefas isoladas: os autores olham para repositórios onde o mesmo ambiente e os mesmos padrões operacionais se repetem ao longo de várias sessões. O custo recorrente que eles identificam aparece em três frentes:

• A primeira é a rediscoberta de fatos do ambiente (aquele comando específico que funciona aqui, a variável de ambiente obrigatória, a ordem de build que não pode ser alterada).

• A segunda é a insistência em ferramentas que não ajudam.

• A terceira é o loop de falha improdutivo, no qual o agente insiste no mesmo caminho sem alterar o estado útil do problema.

O TokenEconomizer atua como um controlador externo. Ele não toca nos pesos do modelo, não reescreve o código do loop do agente. Ele observa a trajetória e intervém em três frentes: injeta micro-skills aprendidas de sessões anteriores no mesmo repositório, poda ferramentas que consistentemente não ajudam, e interrompe quando detecta um padrão de estagnação. Em testes com Claude Code, Codex e GitHub Copilot CLI, equipados com modelos de fronteira, o método reportou uma redução média de custo de 18,4% a 30,9% no benchmark SWE-Bench, mantendo o Pass@1 comparável ou melhor em quatro das cinco combinações de agente e modelo. Em tarefas de web e auditoria de segurança, a faixa ficou entre 6,4% e 21,2%, dependendo de como a tarefa estava estruturada.

O custo invisível das primeiras seis tarefas

Há um detalhe de implementação que os números agregados escondem e que muda radicalmente a expectativa de um time de engenharia. A economia não começa no primeiro uso. Em quase todos os repositórios testados (todos, exceto um), o custo sob o TokenEconomizer é maior do que a linha de base padrão nas primeiras tarefas. Ele só se torna mais barato a partir da sexta tarefa em diante. O motivo é estrutural: o controlador aprende com o histórico do repositório. Sem histórico, não há micro-skill para injetar, não há ferramenta para podar, não há padrão de falha conhecido para interromper. Esse é um período de warm-up real, não um detalhe de rodapé.

Imagine um time que trabalha com microsserviços e troca de repositório a cada duas semanas. Ou um time que mede o ROI da ferramenta a cada sprint de duas semanas. Eles vão olhar para os primeiros dias de uso, ver a fatura subir em vez de cair, e concluir que o método não funciona. A conclusão estará errada. O controlador simplesmente não teve tempo de aprender o ambiente. Para extrair o ganho, o time precisa rodar as primeiras cinco ou seis tarefas com a ferramenta em modo de observação, aceitando o custo de aprendizado, para só depois colher a economia no estado estacionário. Em um monorepo de longa duração, onde o time toca o mesmo código por meses, o warm-up é absorvido naturalmente. Em ambientes fragmentados, a política precisa ser desenhada de outra forma, ou o ganho nunca aparece.

A quinta combinação e a solução que o resumo não conta

A segunda lacuna é mais sutil e atinge diretamente quem usa Claude Code com Opus 4.8. O paper afirma que o Pass@1 foi comparável ou melhor em quatro das cinco combinações testadas. O que essa frase esconde é que, na quinta combinação — exatamente Claude Code com Opus 4.8 —, o TokenEconomizer sozinho cai cerca de um ponto percentual abaixo da linha de base. Não é um desastre, mas também não é "comparável" no sentido estrito. É uma perda mensurável de qualidade.

O paper resolve esse problema de uma forma que o resumo original deixou de fora e que é vital para quem vai implementar a solução. A combinação do TokenEconomizer com outras ferramentas de contexto, especificamente o RepoMap ou o RTK, recupera a qualidade acima do padrão nesse cenário específico. Mais do que isso: essa combinação de controlador com ferramenta de mapeamento de contexto atinge toda a fronteira de Pareto de custo e qualidade no experimento. O time que lê apenas o resumo vai ver "quatro de cinco" e não vai procurar a solução para o quinto caso. Vai implementar a ferramenta isolada, ver a perda de um ponto, e talvez descartar o método inteiro. A diferença entre um dado de pesquisa e uma decisão de arquitetura é justamente essa.

Governança e métricas de progresso

A analogia com a série "Engenharia de Software Assistida por IA" ajuda a fixar a lógica. O limite de tokens ou de passos corta o custo de forma cega, e pode interromper um trabalho que estava prestes a avançar. Intervir apenas quando o humano "acha que o agente travou" depende de atenção intermitente e não escala. O que o TokenEconomizer formaliza é uma política baseada na experiência do próprio repositório: o que já falhou de forma repetida, o que já foi descoberto e não precisa ser redescoberto, quando a sequência de ações deixou de mudar o estado do problema de forma útil.

Progresso, nessa arquitetura, não é o número de tool calls nem a quantidade de linhas geradas. É a mudança observável em direção ao objetivo. O teste que passa, o erro que desaparece, o arquivo que deixa de ser reescrito em loop, a consulta cujo resultado informa a próxima decisão em vez de ser reexecutada de forma idêntica. Sem um sinal explícito de estagnação — mesmo que imperfeito —, o agente pode consumir orçamento enquanto o humano apenas assiste ao espetáculo de "ainda está trabalhando". Para times que já medem custo por tarefa, o próximo passo concreto é registrar, por repositório, quantas sessões redescobrem o mesmo fato operacional e quantas vezes a mesma ação é repetida sem alteração de estado. Aí a decisão de interromper ou redirecionar deixa de ser um feeling no meio do turno e passa a ser uma política de engenharia.

Aprofunde-se no tema de forma estruturada — do contexto à governança de agentes — consultando a série Engenharia de Software Assistida por IA, disponível na Amazon e no Kindle Unlimited.

https://livro-engenharia-de-software-assistida-por-ia.aspepper.workers.dev/?utm_source=hashnode&utm_medium=article&utm_campaign=serie_ia

• Cupom de 30% OFF: LEIA30

Fontes de pesquisa consultadas

• Li, A. J. et al. — TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents, arXiv:2610.22732 (15 out. 2026). UC Berkeley, Microsoft Research, Microsoft Security.
• Repositório oficial do projeto: [github.com/microsoft/TokenEconomizer](https://github.com/microsoft/TokenEconomizer) e tokeneconomizer.github.io
• Discussões no Hacker News e TLDR sobre o paper e o caso da consulta SQL repetida (out. 2026)
• Hugging Face Papers — TokenEconomizer (trending, out. 2026)
• The Batch (DeepLearning.AI) — cobertura sobre controle de custo em agentes autônomos (2026)
• Análises independentes sobre a fronteira de Pareto custo-qualidade e a integração com RepoMap/RTK (2026)

#EngenhariaDeSoftware #IA #AgentesDeCodigo #TokenEconomizer #CustoDeAgentes #SWEBench #SoftwareEngineering #AI #CodeAgents #Progresso #OtimizacaoDeCusto #GovernancaDeAgentes #EngenhariaDeSoftwareAssistidaPorIA