Terceiro episódio de Economizando com IA. O episódio 1, Headroom: o editor entre você e o modelo, instalou uma ferramenta que promete uma conta mais leve enviando menos texto ao modelo. O episódio 2, Uma ferramenta para gastar menos com IA aumentou a minha conta, trouxe os primeiros comprovantes. Este não é mais sobre a ferramenta. É sobre o número que toda ferramenta desse mercado mostra, e por que esse número já não diz o que você vai pagar.
Todo produto que promete cortar a sua conta de IA mostra o mesmo gráfico: uma linha chamada tokens caindo. Sessenta por cento a menos. Noventa e cinco por cento a menos. O gráfico costuma ser verdadeiro.
A fatura é outro documento. Abrimos a nossa linha por linha, em 44 dias úteis e quatro projetos, e os dois documentos discordam. No projeto em que enviamos menos texto ao modelo, o texto relido caiu 46% por rodada de trabalho e o custo por rodada subiu 14%.
Este episódio é a anatomia dessa discordância. Se você paga IA por mês, ele muda qual número você deve pedir à sua equipe.
Token não é preço
Um token é mais ou menos três quartos de uma palavra. É a unidade que o provedor conta. É também, desde 2024, não a unidade que o provedor cobra, e essa é a história inteira.
Um agente de código trabalha em rodadas. Em cada rodada ele envia ao modelo a conversa inteira até ali (toda instrução, todo arquivo que leu, todo resultado que recebeu) e recebe uma resposta. A conversa cresce a cada rodada, então à tarde cada rodada carrega centenas de milhares de tokens.
Enviar tudo isso a preço cheio seria ruinoso, então o provedor oferece um acordo chamado cache. O texto que o modelo já viu pode ser relido por um décimo do preço do texto novo. Em troca, na primeira vez que um trecho é guardado, você paga um ágio para gravá-lo: 1,25 vez o preço do texto novo para um cache de cinco minutos, o dobro para um de uma hora. E a resposta que o modelo escreve custa cinco vezes o texto novo.
Então uma rodada de trabalho são quatro linhas na fatura, a quatro preços diferentes:
| O que é cobrado | Preço, em relação ao texto novo |
|---|---|
| texto relido do cache | 0,1× |
| texto novo, nunca visto | 1× |
| texto gravado no cache (5 min / 1 hora) | 1,25× / 2× |
| a resposta que o modelo gera | 5× |
Um token da primeira linha vale um cinquenta avos de um token da última. “Os tokens caíram” é uma frase sobre a soma de quatro quantidades que nunca deveriam ter sido somadas.
Onde estão os tokens, e onde está o dinheiro
Eis o nosso corpo de dados: 44 dias, quatro projetos, 11,9 bilhões de tokens, US$ 10.206 a preço de lista. A primeira barra é onde estão os tokens. A segunda é onde está o dinheiro.
Noventa e seis por cento de cada token que enviamos era releitura de cache. É a massa que uma ferramenta de compressão enxerga, e a massa que ela comprime. Ela carrega metade do dinheiro.
A outra metade mora em dois lugares que uma contagem de tokens mal registra. As gravações em cache são 4% dos tokens e 42% do dinheiro. As respostas do próprio modelo são 0,3% dos tokens e 8% do dinheiro.
Esta é a primeira morte. Uma ferramenta que apara a barra grande só consegue tocar metade da conta, e precisa aparar muito token barato para movê-la.
Quatro dias, os mesmos tokens, três preços
A segunda morte é mais simples de ver. Pegue quatro dias comuns de trabalho de um projeto, no mesmo modelo, escolhidos porque cada rodada de trabalho enviou quase exatamente a mesma quantidade de texto ao modelo. Se token fosse preço, os quatro dias custariam o mesmo.
O dia 1 e o dia 4 enviaram o mesmo texto, e o dia 4 custou três vezes mais. A diferença está inteira numa linha da fatura: no dia 1, três mil tokens por rodada foram gravados no cache; no dia 4, setenta e dois mil. Todo o resto, as releituras e as respostas, é quase idêntico.
Nos trinta dias desse projeto nessa família de modelo, saber quantos tokens um dia enviou explica cerca de metade do que ele custou. Saber quanto ele gravou no cache explica quase tudo.
Nada aqui é veredito sobre ferramenta alguma. É uma descrição da fatura. A conta segue as gravações. O volume é espectador.
O que a ferramenta faz com essas quatro linhas
Agora a ferramenta. Um proxy se coloca entre o agente e o modelo e encurta o que o agente envia: apara um log comprido, dobra uma listagem repetida, troca um resultado de busca prolixo por um resumo que pode ser expandido a pedido. Ele faz isso bem. No nosso tráfego, removeu texto exatamente como anunciado.
A pergunta é o que isso faz com a fatura. Abaixo, uma rodada de trabalho, linha por linha, no mesmo projeto e na mesma tabela de preços: a barra cinza é uma rodada sem o proxy, a azul é uma rodada com ele.
Leia de cima para baixo.
Primeira linha, releitura, a 0,1×. É o que o proxy comprime, e funcionou: quase metade do volume sumiu. É o gráfico que o produto mostra para você.
Segunda linha, gravação, a até 2×. É o preço de comprimir. O cache do provedor é uma promessa de que este exato texto será visto de novo. No momento em que o proxy muda o texto, o provedor vê texto novo, guarda de novo e cobra o ágio da gravação. A gravação quase triplicou.
Terceira linha, a resposta, a 5×. Respostas mais longas. Parte disso é o modelo mais novo, não o proxy; está aqui porque está na fatura.
Última linha, o total. Um token poupado na primeira linha vale um vinte avos de um token acrescentado na segunda. A rodada custa 14% a mais.
Nada disso é defeito no código de ninguém. Uma ferramenta cuja função é mudar o que o modelo vê é, por construção, uma ferramenta que força regravações. Ela economiza na linha de 0,1× e gasta na linha de 2×.
Dois dias do lado com proxy é uma amostra curta, e os dois lados rodaram em modelos irmãos, por isso o gráfico diz “mesma tabela de preços” e não “mesmo modelo”. Vamos continuar medindo. Mas a direção se repetiu em todo corte que fizemos, e é a mesma direção que um estudo independente encontrou em julho: em execuções pagas e controladas do mesmo agente de código, a configuração que cortou 38% dos tokens entregues aumentou a conta em 6,8%, e a correlação entre tokens cortados e dinheiro economizado foi de 0,15. A estimativa deles para o máximo que comprimir texto visível pode economizar, dado o peso do cache na conta: cerca de 5%.
O que o painel chama de economia
Se a conta sobe, por que todo usuário dessas ferramentas relata economia? Porque o painel da própria ferramenta é o comprovante que a maioria lê, e o painel conta de outro jeito.
O painel do nosso proxy, depois de 3.200 pedidos, informou US$ 14 economizados por compressão e US$ 1.667 economizados por cache. O segundo número é o desconto do próprio provedor: a linha de 0,1×, que todo usuário recebe com ou sem proxy. Apresentados lado a lado, o desconto é a manchete e a compressão é arredondamento, e um leitor que não conhece a fatura vê uma ferramenta que economizou mil e seiscentos dólares.
O número mais honesto está três telas abaixo, nos contadores da própria ferramenta: ela removeu 1,79 milhão de tokens por compressão e perdeu 2,84 milhões em regravações de cache que ela mesma causou. O contador se chama saldo de tokens: negativo. A ferramenta sabe. Só não abre com isso.
Não fomos os primeiros a notar. Um desenvolvedor que rodou a mesma ferramenta por vários dias descobriu que US$ 47 dos seus US$ 57 “economizados” eram o desconto do provedor, e que só 2% do tráfego dele chegou a ser comprimido. O conselho dele foi ler o detalhamento em vez da capa. O estudo acima diz a mesma coisa no título.
Uma correção, no mesmo espírito
Medir isso nos custou uma lição que devemos ao leitor. Até esta semana, todo total desta série estava cerca de duas vezes alto demais. O registro do agente escreve uma linha por pedaço de resposta, e cada linha repete o custo da resposta inteira; estávamos contando linhas. Descobrimos ao construir uma tela que abre a conta linha por linha, onde respostas idênticas com dois segundos de diferença pareciam erradas. Confirmamos contra um registro independente de pedidos e recontamos tudo.
Os totais dos episódios 1 e 2 caem pela metade. As conclusões sobrevivem, porque já estavam enunciadas por rodada e os dois lados de cada comparação estavam inflados pelo mesmo fator. Dizemos isso aqui porque o ponto deste episódio é que contar tokens é traiçoeiro, e nós não somos exceção.
O que pedir no lugar
Para um gestor, um executivo ou um pequeno empresário que paga por isso, o resultado prático é uma troca de pergunta.
Não pergunte quantos tokens foram economizados. É a quantidade que as ferramentas otimizam, e a quantidade com que a fatura menos se importa.
Peça três coisas:
- Custo por rodada de trabalho, por modelo, por dia. É o único número que sobrevive a mudanças na quantidade de trabalho, e o único em que um antes e depois significa alguma coisa. O nosso está numa tela que abre de um total até cada pedido, com a conta mostrada em cada linha.
- A fatia da conta que é gravação em cache. É a linha que moveu a nossa conta, e a linha que nenhum gráfico de tokens mostra. Se ela sobe, algo está mudando o texto entre uma rodada e outra: uma ferramenta, uma pausa longa, uma instrução que carrega a hora do dia.
- Qual modelo respondeu que tipo de tarefa. Nos nossos dias, a escolha do modelo moveu a conta mais do que qualquer proxy, nas duas direções. É uma alavanca sua e não custa nada puxar.
A ferramenta dos episódios 1 e 2 continua instalada por enquanto, num só projeto, num teste limpo, porque dois dias não são veredito e prometemos publicar o número para o lado que ele for. Mas a série mudou de assunto. O token é a unidade errada, e o resto destes episódios será escrito na unidade certa.
Método, em resumo. Quatro projetos, 44 dias úteis, toda resposta do modelo lida dos registros do próprio agente e precificada pelas tarifas publicadas do provedor, incluindo as tarifas separadas de gravação em cache de cinco minutos e de uma hora. Respostas deduplicadas pelo id da resposta. O projeto com proxy é comparado só consigo mesmo, por rodada, numa família de modelo e numa tabela de preços. Dias em que o proxy rodou uma configuração depois descoberta errada ficam fora do antes e depois e não aparecem como evidência em lugar nenhum. Todos os valores são equivalentes a preço de lista: pagamos um plano mensal fixo, e esta série é o estudo que fazemos antes de migrar para o uso medido.
Fontes: S. Weinberger e A. Hozez, “Token Reduction Is Not Cost Reduction: An Empirical Study of End-to-End Efficiency in API-Based Coding Agents”, arXiv:2607.12161, julho de 2026. O relato de campo dos US$ 47 em US$ 57 está em russ.cloud, junho de 2026.