A maior parte dos tokens do seu agente de IA morre onde você nunca olha

Você fica de olho no medidor de dólares da assinatura. Nunca olha onde os tokens morrem de fato. Eles morrem em três lugares, e dá para tapar os três sem mexer no modelo.

Todo mundo fica obcecado com o preço por milhão de tokens. É o número errado para ficar encarando. O modelo cobra por cada token que lê, e a maior parte do que ele lê é lixo que você jamais colaria ali por conta própria: duzentos testes passando na tela para esconder os três que falharam, o mesmo arquivo lido cinco vezes numa sessão, o stack reexplicado no início de cada conversa nova.

Esse desperdício não é culpa do modelo. É o harness entregando uma enxurrada ao modelo e chamando isso de contexto. Este texto acompanha o de harness engineering, com zoom total em um eixo só: a conta de tokens. Aqui está para onde os tokens vão e o stack que uso para estancar o sangramento.

Os tokens vazam em três lugares

Observe uma sessão real e o desperdício se separa sozinho em três camadas. Cada uma vaza de um jeito, então cada uma pede uma correção diferente. Pendure um modelo maior e você paga mais pelos mesmos vazamentos. Corrija as camadas e toda sessão fica mais barata de uma vez.

Três vazamentos, três camadas

1. L1

   Output das ferramentas, o vazamento barulhento

   Cada comando que o agente roda despeja o output completo na janela. Um git status num repositório movimentado dá dois mil tokens. Uma rodada completa de testes dá vinte e cinco mil. O modelo precisava das três falhas, não dos duzentos sucessos.

   git status  → 2.000 tokens
   rodada de testes → 25.000 tokens

   +
2. L2

   Histórico repetido, o vazamento silencioso

   Ao longo dos turnos, a transcrição se repete. O mesmo arquivo lido cinco vezes. O mesmo erro impresso três vezes. O plano reafirmado em cada passo. O modelo relê tudo isso em todo turno, e você paga por cada releitura.

   mesmo arquivo × 5 leituras
   mesmo erro × 3 impressões

   +
3. L3

   Reexplicação, o vazamento invisível

   Toda sessão nova começa do zero. Você reexplica o stack, as convenções, as decisões que já tomou semana passada. É o vazamento mais barato de ignorar e o mais caro ao longo de um mês, porque você também paga com o seu tempo.

   início da sessão → reexplicar tudo
   próxima sessão   → de novo

Corrija primeiro o vazamento barulhento: comprima o output das ferramentas

A mudança de maior retorno em qualquer harness é um filtro no output das ferramentas, porque é ali que os tokens jorram e ninguém olha. O output passa rolando no terminal, parece normal e come em silêncio um terço da sua janela.

A ferramenta que uso para isso é o RTK, um proxy de CLI open source. Ele fica entre o shell e o modelo. O agente roda um comando, o RTK reescreve o output para um equivalente comprimido antes que ele chegue ao context window, e o modelo vê sinal em vez de ruído. Filtragem inteligente, agrupamento, deduplicação, truncamento. Nos comandos de dev do dia a dia, ele economiza de 60 a 90 por cento, e um hook de shell o torna invisível: o agente digita git status, o hook reescreve para rtk git status e ninguém lá em cima precisa mudar nada.

O que o filtro devolve

60-90%

menos tokensnos comandos de dev do dia a dia

2k → ~0

git statusde enxurrada a um punhado

25k

tokens de uma rodada de testesreduzidos às falhas que importam

0

mudanças no workflowo hook de shell é invisível

Corrija o vazamento silencioso: comprima a conversa

O output de uma ferramenta é uma chamada. A conversa é o histórico inteiro, reenviado a cada turno. Quando o agente lê o mesmo arquivo cinco vezes, as cinco cópias vão junto no contexto do turno seis. Quando um erro foi impresso três vezes, o modelo relê os três. A janela se enche dos próprios ecos.

A correção é uma passada de compressão entre os turnos: deduplicar as leituras, reduzir passos bem-sucedidos a uma linha, manter os turnos recentes intactos e resumir os antigos. O modelo vê o delta, e não a transcrição de novo. Esta é a camada que ainda estou construindo, então não vou te entregar um benchmark inventado. O mecanismo é o mesmo da camada de ferramentas, um nível acima: coloque o filtro onde está a repetição e pare de pagar para reler o que não mudou. A compressão é uma tática dentro da disciplina maior de context engineering: decidir o que o modelo vê a cada turno.

A mesma sessão, dois harnesses

Quatro vazamentos, quatro filtros. Nenhum deles é um modelo mais inteligente. Todos são encanamento.

Para onde vão os tokens	Harness ingênuo	Harness com filtro
Output das ferramentas	despejo cru, 2k a 25k por chamada	comprimido na origem, 60 a 90% a menos
Leituras repetidas	o mesmo arquivo reenviado todo turno	deduplicado, uma cópia só
Turnos antigos	transcrição completa, todo turno	resumidos, turnos recentes intactos
Início da sessão	reexplicar o projeto na mão	contexto carregado automaticamente da memória

Corrija o vazamento invisível: dê uma memória ao harness

O terceiro vazamento cobra duas vezes, em tokens e no seu tempo. A cada sessão nova você redigita o stack, as convenções, as decisões. O modelo começa em branco porque o harness deixou.

A correção é contexto persistente carregado no início da sessão: as decisões e convenções vivem em arquivos, e o harness injeta as relevantes antes da primeira mensagem. O agente começa sabendo em vez de perguntando. Na prática, é um AGENTS.md que o harness lê automaticamente, mais um armazenamento de memória para o que é grande demais para um arquivo só. Escrevi a versão em arquivo no guia do AGENTS.md. O ponto aqui é mais estreito: reexplicação é um vazamento de tokens como qualquer outro, e a correção é parar de fazer na mão o que um arquivo faz uma vez só.

O stack e o status real

Três vazamentos, três camadas. Isto é o que eu rodo de fato, e o que ainda está na bancada. Não vou te vender as partes que ainda não coloquei em produção.

O stack de tokens em três camadas

• ✓Obrigatório:
  RTK na camada de ferramentas, em produção e essencialProxy de CLI open source, comprime o output dos comandos de 60 a 90 por cento. Uso todo dia. É o que vale copiar hoje.
• •Opcional:
  Compressão na camada da conversa, em construçãoDeduplicar leituras e resumir turnos antigos entre os prompts. O mecanismo já está provado na camada de ferramentas; a versão para a conversa é o que estou ligando agora.
• •Opcional:
  Memória na camada de conhecimento, em construçãoCarregar automaticamente as decisões e convenções do projeto no início da sessão. O AGENTS.md já cobre o caso em arquivo; o armazenamento indexado é o próximo.
• •Opcional:
  Um proxy local na frente de qualquer agenteA direção: juntar as três camadas num único proxy local-first que fica entre qualquer agente e o modelo, para o stack ir junto no pi, no Claude Code ou em qualquer coisa que fale com um endpoint compatível com OpenAI.

O plano não é esperto, e é justamente essa a ideia. Um proxy que fala o mesmo protocolo compatível com OpenAI que todo agente já fala, fazendo três trabalhos chatos antes de a requisição chegar ao modelo.

O que o proxy faz com uma requisição

Entrada

Um agente prestes a enviar um turno ao modelo

↓

1. MEMORYInjetar o que importa

   Puxar do armazenamento as decisões e convenções relevantes do projeto e colocá-las no system prompt, para o modelo começar a sessão já conhecendo a base de código.

   ↓
2. COMPRESSCortar a repetição

   Deduplicar leituras repetidas e resumir turnos antigos, para o modelo pagar pelo delta em vez de reler a transcrição inteira.

   ↓
3. FORWARDEnviar o payload enxuto

   Rotear a requisição enxugada para o provedor. O RTK já cortou o output das ferramentas antes, no shell, então o que chega é sinal.

↓

Saída

A mesma resposta, com uma fração dos tokens, em todo agente que você usa

O número que vale acompanhar

Pare de acompanhar o preço por milhão de tokens. Você não controla esse número, e ele cai sozinho a cada poucos meses de qualquer jeito. Acompanhe os tokens por tarefa concluída. Esse número é puro harness, e é o que você consegue cortar pela metade esta semana. Se a pergunta real é se um plano fixo compensa mais do que pagar por token, fiz essa conta em se vale a pena o Claude Max.

Tem mais uma alavanca aqui: rotear um modelo barato para a exploração e um forte só para a construção. Automatizo isso por fase no pi com um pequeno pacote de troca de modelo que muda o modelo e o esforço de raciocínio quando uma skill carrega, explicado no guia do pi. Os turnos exploratórios param de ser cobrados a preço premium por um trabalho que nunca precisou disso.

Coloque um filtro no output das ferramentas e você fez a coisa de maior retorno ao seu alcance. Tudo depois disso é o mesmo movimento em outra camada: encontre onde os tokens se repetem e pare de pagar para lê-los duas vezes.

Custo em tokens, respostas rápidas

Qual é o jeito mais rápido de cortar o custo em tokens do meu agente de IA de código?+

Comprimir o output das ferramentas no shell antes que ele chegue ao modelo. Um git status pode dar dois mil tokens e uma rodada de testes vinte e cinco mil, e o modelo não precisava de quase nada disso.

Um proxy de CLI como o RTK faz isso e economiza de 60 a 90 por cento nos comandos do dia a dia, sem mudança nenhuma no seu workflow. É a mudança de maior retorno que existe num harness.

Um context window maior resolve o desperdício de tokens?+

Não. Uma janela maior deixa o desperdício acessível, não ausente. O vazamento continua lá, você só bate no limite mais tarde e paga mais por turno até lá.

Corrija o vazamento na origem: filtre o output das ferramentas, deduplique o histórico repetido e carregue a memória do projeto para parar de reexplicar. Aí uma janela normal sobra.

O que é o RTK?+

O RTK é um proxy de CLI open source que intercepta comandos comuns de shell e reescreve o output para um equivalente comprimido antes que ele chegue ao context window do modelo, cortando de 60 a 90 por cento dos tokens nos comandos de dev do dia a dia. Um hook de shell o torna invisível para o agente.

Para onde vão de fato os tokens numa sessão de agente?+

Três lugares. Output de ferramentas que despeja a enxurrada inteira quando o modelo precisava de uma linha. Histórico repetido que reenvia as mesmas leituras e erros a cada turno. E reexplicação, quando cada sessão nova começa em branco e você redigita o contexto do projeto.

Cada vazamento tem sua correção: comprimir o output, comprimir a conversa e dar uma memória ao harness.