Segundo episódio de Economizando com IA. O primeiro — Headroom: o editor entre você e o modelo — descreveu o que a ferramenta promete e a configurou. Este traz o que os comprovantes dizem. Na semana que vem, o episódio três: a mesma ferramenta, configurada como a documentação dela descreve, e não como eu improvisei.
Há oito dias eu coloquei um proxy entre o meu agente de código e o modelo, escrevi as regras do teste antes da primeira requisição passar, e prometi publicar o que os comprovantes dissessem. É isto.
A versão curta: economizou US$ 439, e cerca de US$ 1.200 voltaram em outra linha da mesma fatura.
As duas metades são reais. Entender como as duas podem ser verdade ao mesmo tempo é o ponto inteiro deste episódio, e vale mais que qualquer um dos dois números.
O que ela fez, exatamente como anunciado
Seis dias de trabalho comum. 3.994 requisições, cada uma registrada com o que entrou antes do proxy tocar e o que saiu depois.
6,4% menos texto enviado ao modelo. No claude-opus-5, que concentra 91% do
que eu gasto, a contabilidade do próprio proxy põe a economia em US$ 438,94.
Não é estimativa de fornecedor nem conta minha — é a ferramenta prestando contas
do próprio trabalho, e o meu registro de requisições concorda com ela.
O editor fez o serviço. Encurtou o dossiê antes de ele sair pela porta.
E a fatura foi para o outro lado
Aqui está a parte que eu não vi chegando.
Um agente não tem memória, então cada passo reenvia a conversa inteira. O provedor guarda essa conversa e cobra muito pouco para lê-la de volta — um décimo da tarifa base. Guardar de novo custa 1,25× a tarifa base. Entre reaproveitar o que está guardado e guardar outra vez há um fator de doze e meio, pelas mesmas palavras.
O proxy encolhe a mensagem editando o começo dela: as definições de ferramenta, o catálogo, as instruções que vêm antes de tudo. E o começo da mensagem é exatamente o que o cache usa como chave. Mude um byte ali e nada depois pode ser reaproveitado. A conversa inteira é guardada de novo, na tarifa cara.
Pior: o quanto ele apara varia de requisição para requisição — vinte e oito ferramentas diferidas numa chamada, vinte e uma na seguinte, seis na outra. O prefixo nunca assenta. Então o cache nunca tem chance de se pagar.
O que isso parece, dia a dia:
É o mecanismo inteiro. Menos texto, mais dinheiro, nenhuma contradição.
As regras que escrevi antes de medir
O episódio um se comprometeu com três números por antecipação, justamente para que eu não pudesse torcê-los depois. Eis o placar.
| A regra que eu fixei | O que os comprovantes dizem | |
|---|---|---|
| Tokens por requisição caírem 15% ou mais | 6,4% | não |
| Re-leituras e recuperações subirem no máximo um quinto | re-leituras caíram 31%; recuperações foram 28 eventos em 3.994 requisições | sim |
| Latência acrescentada abaixo de 4 segundos no percentil noventa | 9,5 segundos (p99: 31s) | não |
Duas de três falharam, e a regra que eu escrevi dizia o que fazer nesse caso: voltar ao modo cache ou à compactação sem perda, e dizer isso em voz alta. Estou dizendo.
A parte que de fato me ensinou algo
Olhe de novo para a linha do meio. Ela passou.
As re-leituras não subiram — caíram, quase um terço. As recuperações foram erro de arredondamento. Pela letra da minha própria regra, o critério foi atendido; e se eu tivesse olhado só para o que disse que ia olhar, teria concluído que o editor estava se comportando bem.
Enquanto isso, as regravações por requisição subiram 527%.
Construí uma regra para me impedir de mover a trave, e a regra tinha um ponto cego exatamente onde o dinheiro foi. Eu estava vigiando a metade barata do cache e não tinha escrito nada sobre a metade cara.
Se você levar uma coisa deste episódio, leve essa. Não é “proxy de compressão é ruim” — não é. A medição que você desenha antes do experimento é ela mesma uma hipótese, e pode estar errada de um jeito que o experimento não vai te contar. A minha estava.
Onde ela funciona
A mesma ferramenta, a mesma semana, três modelos diferentes:
De seis a oito vezes mais eficaz nos modelos baratos do que no caro — e o caro é onde está praticamente todo o dinheiro.
Isso não é defeito da ferramenta, é descasamento entre onde ela alcança e onde o meu gasto mora. Minhas sessões no modelo grande são longas, e o que as enche é a conversa acumulada, não a saída das ferramentas. No período inteiro, resultado de ferramenta foi menos de 1% do tráfego. Um proxy que comprime saída de ferramenta não move um número dominado pela conversa sendo relida.
Em trabalho curto, barato e descartável — um subagente que lê três arquivos e responde — ela vai muito bem.
O que eu não rodei
Preciso ser direto sobre o alcance deste veredito, porque ele é mais estreito que a manchete.
Rodei a configuração básica: subir o proxy, apontar o agente para ele, proteger conteúdo de arquivo da compressão, truncar descrição de ferramenta. Foi o que o episódio um descreveu, e foi o que eu medi.
Não é o que a documentação descreve. Quatro capacidades da ferramenta nunca foram ligadas, e uma delas reduz a resposta em vez da pergunta — o lado da saída, que no modelo caro custa cinco vezes o que custa a entrada, e que no meu caso nunca produziu uma única medição. O roteamento também está incompleto: algumas das minhas sessões passaram por fora do proxy, o que significa que estes números subestimam o tráfego e superestimam a parte do dano que cabe à ferramenta, ao mesmo tempo.
Então isto é uma leitura da minha configuração. Não é um veredito sobre a ferramenta.
Antes de comprar eficiência para o seu gasto com IA
Cinco perguntas, na ordem em que eu gostaria de tê-las feito.
Qual unidade ela otimiza, e é essa a unidade da sua fatura? Token, requisição, janela de contexto e dólar são quatro coisas diferentes, e uma otimização pode ganhar numa e perder em outra.
Se ela mexe no começo do prompt, meça o cache. Qualquer coisa que reescreva o prefixo invalida tudo depois dele. Acompanhe guardado-de-novo contra reaproveitado, não só volume total.
Compare dinheiro em dias comparáveis. Minha primeira tentativa de análise anunciou 18% de melhora, que evaporou assim que controlei como os dias estavam estruturados. Porcentagem de texto é fácil e enganosa; dólar por unidade comparável de trabalho é difícil e honesto.
Aponte para onde o gasto realmente está. Se 90% da sua conta é um modelo, uma ferramenta que brilha nos outros 10% não vai aparecer na fatura.
Defina um teto antes de ligar qualquer coisa. Eu não tinha nenhum. Uma otimização que custa mais em silêncio é exatamente o modo de falha que um teto pega.
Episódio três
Na semana que vem, a mesma ferramenta, configurada como a documentação dela descreve: o redutor de saída ligado, o roteamento tornado durável para que toda sessão passe mesmo por ele, o trabalho apontado para os modelos onde ela já performa, e um teto de gasto definido.
Aí eu meço de novo e publico esse número também, para o lado que ele for. Se ele merecer a cadeira, eu digo. Ainda não mereceu.
Versões: Headroom 0.36.5, Claude Code 2.1.278, setembro de 2026. Os números vêm das minhas próprias transcrições do Claude Code e do log de requisições do proxy, num projeto real que não é o assunto e não é nomeado. Os US$ 439 e as porcentagens são medidos; os ~US$ 1.200 e o saldo de ~−US$ 750 são estimativa — três recortes independentes põem o excesso entre US$ 1.110 e US$ 1.271, e 290 pausas de mais de uma hora no período quebram o cache por conta própria, o que faz desse valor um teto do que o proxy sozinho custou.