O motivo pelo qual o desperdício de tokens não aparece é que ele não é uma falha, e sim duplicação: ler o mesmo arquivo duas vezes, tentar de novo com os mesmos argumentos, chamar novamente a mesma ferramenta. Então criei uma CLI que lê traces já finalizados e aponta em qual etapa algo que já tinha sido feito foi feito de novo!
[Experimente]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Roda localmente, sem cadastro. Como não baixa torch, a instalação termina em poucos segundos. Python 3.12 ou superior. Os arquivos de sessão do Claude Code ficam em ~/.claude/projects/.
Este é o output real rodando em uma sessão pública do Claude Code (258 turnos):
Result: WASTE DETECTED
- category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified
1. requery — Read on .../boot.ts
- turns: turn 50 → re-run at turn 58 (of 258 total)
- state: No modification of this file in between — re-read output is unchanged.
- re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
- estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
[Como a decisão é feita]
Não armazena nem visualiza traces como Langfuse ou Phoenix. Ele lê traces já concluídos e aponta apenas o desperdício.
São 2 etapas. Primeiro, agrupa chamadas da mesma ferramenta com os mesmos argumentos; depois verifica se o sha256 do output é exatamente igual. Se o output for diferente, significa que o estado mudou, então não é detectado.
Não há julgamento por LLM. Se você passar o mesmo trace, o resultado será sempre o mesmo.
O desperdício encontrado é classificado em quatro tipos: repetição de erro (tentar de novo o mesmo erro sem corrigir a causa), reexecução com efeito colateral (chamar de novo, com os mesmos argumentos, uma ferramenta que altera estado), zona cinzenta (repetição somente leitura — não tem efeito colateral, mas consome tokens) e indeterminado. Ferramentas como Bash ou PowerShell, cujo efeito pode mudar completamente conforme o conteúdo dos argumentos, não são classificadas apenas pelo nome e ficam como indeterminadas.
[O que foi encontrado nos dados públicos]
Rodei diretamente no benchmark Toolathlon (22 modelos frontier × 3 execuções, 6.780 traces, 176.270 tool spans) e apareceram 8.042 chamadas duplicadas.
Usar esse número diretamente seria inflado. 47% são zona cinzenta (repetição de declaração de conclusão da tarefa, recriação de diretório que já existe etc.); removendo isso, sobram 4.251 casos. 2,41% em relação aos tool spans.
O que chamou atenção foram 1.343 reexecuções duplicadas de ferramentas que alteram estado, e, dentro delas, 459 envios de e-mail repetidos com os mesmos argumentos. Mas isso é uma detecção de “a mesma ferramenta foi chamada duas vezes com os mesmos argumentos”; apenas pelo trace, não dá para confirmar se o e-mail foi realmente enviado duas vezes.
[O que foi inesperado]
O Claude Code em si foi mais eficiente do que eu imaginava. Medi seis vezes padrões candidatos como releitura de arquivos e novas tentativas sem sentido, e em cinco delas eles praticamente não existiam em sessões reais do CC. Caching e manutenção de contexto já estavam bloqueando isso.
Onde o desperdício era mais denso foi em ambientes com vários servidores MCP conectados. Houve uma diferença de 3× entre o CC com 20 ferramentas (0,80%) e o Toolathlon com 523 ferramentas (2,41%).
[Limitações]
Ainda não há casos medidos de economia. É possível detectar e estimar, mas há 0 dados de alguém que viu isso, corrigiu algo e teve a fatura realmente reduzida.
Os 47% de zona cinzenta não são filtrados; apenas classificados e mostrados. Se uma repetição somente leitura é desperdício real depende do contexto de execução, e essa é uma parte que eu não consigo julgar.
Cursor e Codex ainda não são compatíveis.
Detectores que falham na validação são descartados. Criei um detector de releitura de arquivos, mas ele ficou muito abaixo do limiar de 70% de precisão em uma amostra de 30 casos (mesmo sendo generoso, 3,3%; sendo rigoroso, 0%), então foi desativado, e deixei as previsões e os resultados juntos no documento de pré-registro.
[Para encerrar...]
Pretendo continuar pesquisando e validando essa área!
Peço desculpas pelo README estar em inglês... snif
Se você usar, gostaria de receber feedback sobre o que poderia ser melhorado e o que seria bom adicionar!
Conto com o interesse de vocês pelo clew daqui para frente. Obrigado...!!
1 comentários
[Para facilitar a leitura, incluí uma tradução do README para o português!]
Clew
Um detector determinístico que encontra trabalho desperdiçado em traces de agentes.
O Clew lê traces de execuções concluídas de agentes de IA e identifica etapas que repetiram trabalho já realizado — rechamar a mesma ferramenta com os mesmos argumentos, tentar novamente uma chamada que falhou com os mesmos argumentos, ou consultar de novo informações que já estavam no contexto. Como funciona sem julgamento de LLM, o mesmo trace sempre produz o mesmo resultado.
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Exemplo de saída real ao rodar em uma sessão pública do Claude Code:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsPor que isso importa
Em sessões de agentes de IA para programação, o desperdício só aparece na fatura. Todas as chamadas de ferramenta retornam 200 e nada gera erro, então o desperdício não fica visível. Mas, dentro do trace, o agente lê o mesmo arquivo duas vezes, tenta novamente uma chamada que falhou com os mesmos argumentos e chama de novo a mesma ferramenta com o mesmo payload.
Como operações de leitura (read) representam 65% a 90% dos tokens em sessões de agentes de programação, esse desperdício se acumula sem chamar atenção. Ferramentas de observabilidade mostram o trace, mas não indicam qual etapa foi duplicada.
O que ele detecta
O Clew procura três padrões de duplicação:
repeat — a mesma ferramenta/nó é chamada repetidamente
requery — a mesma ferramenta é rechamada com a mesma entrada (saída idêntica)
pingpong — dois agentes trocam conteúdo substancialmente igual (multiagente)
Cada achado é classificado em quatro categorias:
error_repeat — a saída é um erro, mas a mesma chamada é repetida
side_effect — uma ferramenta que altera estado (envio/escrita/criação etc.) é reexecutada
idempotent — repetição de uma ferramenta somente leitura/declarativa (sem efeito colateral, mas consome tokens)
unclassified — ferramenta que não está no mapeamento. Como o efeito depende do payload, não inferimos apenas pelo nome da ferramenta (Bash/PowerShell etc.)
[Como funciona]
É uma cascata em 2 etapas:
Gate estrutural — agrupa chamadas da mesma ferramenta com os mesmos argumentos (normalizados)
Gate de identidade — verifica se o sha256 da saída é exatamente igual. Se for diferente, significa que o estado mudou, então não marca
Uma verificação estrutural barata primeiro filtra os candidatos, e a verificação semântica cara (embedding + cosseno) só é executada quando necessário. Como não há julgamento de LLM, o resultado é determinístico — isso é importante se você quiser colocar no CI.
[Formatos de entrada]
Claude Code — analisa diretamente JSONL de sessão
LangGraph — detecta duplicações de cadeia no trace
LangChain·CrewAI·AutoGen·LlamaIndex etc. — faz parsing de traces instrumentados nos formatos padrão OpenTelemetry/OpenInference (suporte de formato; validação empírica por framework ainda em andamento)
Traces públicos de benchmark (Toolathlon, RedundancyBench)
Sessões do Cursor e do Codex ainda não são compatíveis — estamos analisando os formatos locais.
[Resultados de validação]
Benchmark público (Toolathlon, 6.780 traces, 176.270 tool spans):
Detectou 8.042 chamadas duplicadas. Destas, 47% são zona cinzenta (operações idempotentes, declarações de conclusão); excluindo-as, são 4.251 casos (2,41% dos tool spans). Cerca de 3 vezes mais que nas sessões do Claude Code (0,80%).
Foram detectadas 1.343 execuções duplicadas de ferramentas que alteram estado, incluindo 459 envios de e-mail repetidos com os mesmos argumentos. Porém, isso indica apenas que a mesma ferramenta foi chamada repetidamente com os mesmos argumentos; não foi confirmado se houve, de fato, efeito colateral.
Benchmark de rotulagem (RedundancyBench):
precision 0.826 (estimativa de limite inferior para duplicação dentro do arquivo). Uma parte considerável dos rótulos do RB é de duplicação entre arquivos (cross-file), fora do escopo do desenho de análise por sessão. O recall é baixo, 0.157.
[Limites honestos]
Ainda não há casos medidos de economia. É possível detectar e estimar, mas há 0 dados before/after em que um usuário real corrigiu algo e a fatura efetivamente diminuiu.
47% do que foi sinalizado no benchmark é zona cinzenta (reexecuções idempotentes). Não filtramos; apenas classificamos — porque saber se uma reexecução somente leitura foi desperdício depende de um contexto que não conseguimos ver.
Como exigimos correspondência perfeita por sha256, qualquer pequena diferença na saída faz com que não seja sinalizado. Esse é o motivo do recall baixo; o design privilegia precisão.
O Claude Code é excepcionalmente bem otimizado. Medimos seis padrões candidatos de desperdício em sessões reais do CC, e cinco deles simplesmente não existiam ali. O desperdício interessante apareceu não no CC em si, mas em ambientes MCP com múltiplas ferramentas.
A estimativa de custo (amplification) é uma estimativa, não uma medição, e só é possível no formato do Claude Code.
O que não é validado, descartamos
Criamos um detector de releitura de arquivos, mas o descartamos depois que anotações humanas em uma amostra de 30 casos ficaram muito abaixo do limiar pré-registrado de precisão (70%): 3,3% na avaliação generosa e 0% na rigorosa. As previsões e os resultados foram mantidos juntos no documento de pré-registro.