# 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