Economia de tokens: onde o dinheiro vaza em produção

A sequência é quase sempre a mesma. A fatura triplica. O time corta o prompt pela metade. A fatura não muda.

Isso se repete porque quase todo mundo procura o dinheiro no lugar errado. O prompt é a parte visível do gasto, então é a primeira a ser cortada. E é quase sempre a de menor retorno.

O dinheiro vaza em três lugares que o dashboard não mostra: no desenho do sistema, em escolhas que ninguém registrou como escolha, e numa crença sobre o que o gasto compra.

Este post fecha a conta de cada um. Com os multiplicadores oficiais, a fórmula à mostra e a aritmética que você pode conferir. É o fecho econômico do cluster sobre engenharia de harness: cada técnica dos posts anteriores ganha aqui um valor em dólar.

Está no input, não no output. E no contexto reenviado, não no prompt.

Um estudo de abril de 2026 mediu isso com rigor. How Do AI Agents Spend Your Money?, de Longju Bai, Zhemin Huang, Xingyao Wang, Jiao Sun, Rada Mihalcea, Erik Brynjolfsson, Alex Pentland e Jiaxin Pei, analisou trajetórias de oito modelos de fronteira no SWE-bench Verified (arXiv 2604.22750, v2 de 29/04/2026).

O resultado central: tarefas agênticas consomem mil vezes mais tokens que code chat e code reasoning. E são os tokens de entrada que puxam o custo, não os de saída.

A razão é mecânica. O agente relê o prompt original mais tudo que já respondeu, antes de cada nova ação. No turno 50, ele reenvia o trabalho concluído dos 49 turnos anteriores para produzir mais uma resposta curta.

Isso muda a ordem das prioridades. Encurtar a saída rende pouco. Reduzir o número de passos rende muito.

Antes de otimizar qualquer coisa, porém, é preciso atribuir. Sem saber qual agente, qual fluxo e qual etapa consomem o quê, toda economia é palpite. Esse é o assunto de instrumentar o que não se reproduz.

O gasto excedente cai em três grupos. Eles pedem intervenções diferentes.

O primeiro grupo é estrutural: o desenho do sistema cobra de você a cada requisição. O segundo é de configuração: alguém marcou uma opção e ninguém anotou o preço. O terceiro é conceitual, e é o mais caro dos três.

Três itens desse grupo aparecem em quase toda base de código.

A definição de ferramenta é paga em toda requisição. Não é uma taxa de setup. Ela entra no input a cada chamada, para sempre.

Os números são públicos. No Claude Opus 5, o system prompt de uso de ferramentas custa 286 tokens com tool_choice em auto, e 406 com any ou tool. O conjunto de ferramentas de computador adiciona cerca de 4.500 tokens. O de navegador, cerca de 6.600 (documentação de preços da Anthropic, lida em 28/08/2026).

Vale fechar essa conta. A 500 requisições por dia no Sonnet 5, a US$ 2 por milhão de tokens de entrada:

500 × 6.600 × US$ 2 / 1.000.000 = US$ 6,60 por dia
US$ 6,60 × 30 = US$ 198 por mês

São US$ 198 mensais apenas para declarar as ferramentas. Nenhum trabalho útil foi feito ainda. É por isso que design de ferramentas para agentes é um assunto de custo, e não só de acerto.

O retry tardio arrasta tudo que veio antes. Um retry no passo 2 é barato. Um retry no passo 12 reprocessa o contexto acumulado dos onze passos anteriores.

O custo de uma tentativa não é constante. Ele cresce com a posição da falha. Falhar cedo é muito mais barato que falhar tarde, o que muda onde vale a pena colocar a verificação — o tema de por que o agente não revisa o próprio trabalho.

O contexto acumulado é o custo de base. Cada turno reenvia o histórico inteiro. É o item que o estudo do SWE-bench identificou como dominante.

O cache de prompt tem três preços, não um. E é a relação entre eles que decide se ele compensa.

Os multiplicadores da Anthropic, relativos ao preço de entrada base:

A leitura custa um décimo. Mas a escrita custa mais que o normal. Então existe um ponto de equilíbrio, e ele depende de quantas vezes você relê o mesmo prefixo.

Para um prefixo de P tokens usado em N requisições:

sem cache:  N × P
com cache:  (multiplicador de escrita × P) + ((N − 1) × 0,1 × P)

Resolvendo para os dois TTLs, o equilíbrio fica em N = 1,28 no cache de 5 minutos e em N = 2,11 no de 1 hora. A economia por número de requisições:

Duas leituras não óbvias saem daí.

Um cache de 1 hora usado duas vezes ainda dá prejuízo. Cinco por cento. A intuição corrente é que um TTL maior é sempre mais seguro. Não é: ele é mais caro de escrever, e precisa de uma terceira leitura só para empatar.

O teto de 90% nunca é alcançado. A escrita continua sendo paga. Mesmo com cem requisições, a economia real fica em 88,8%.

A própria documentação afirma o resultado em prosa, dizendo que o cache compensa após uma leitura no TTL de 5 minutos e após duas no de 1 hora. A tabela acima é essa frase resolvida em números.

Taxa de acerto zero quase nunca é bug do provedor. É breakpoint no lugar errado.

A invalidação segue uma cascata: tools → system → messages. O que estraga o quê:

O item de cima é o mais caro. Adicionar uma ferramenta ao seu agente invalida o cache inteiro, incluindo o system prompt gigante que não mudou em nada.

Três armadilhas frequentes:

1. Breakpoint em cima de conteúdo que muda. Um timestamp, um ID de sessão ou o nome do usuário no fim do system prompt garantem 0% de acerto. Não há erro nem aviso. A regra é pôr o cache_control no último bloco que permanece idêntico.
2. Prompt abaixo do mínimo. O mínimo cacheável é de 512 tokens no Opus 5, 1.024 no Sonnet 5, 2.048 no Opus 4.7 e 4.096 no Haiku 4.5. Abaixo disso, nada é cacheado — e a API não devolve erro. Só os campos de usage revelam.
3. Mais de quatro breakpoints. O limite é 4, com janela de lookback de 20 blocos. Breakpoints extras não custam nada, mas também não fazem nada.

A conferência é rápida: leia cache_read_input_tokens e cache_creation_input_tokens na resposta. Se o primeiro vive em zero e o segundo não, você está pagando 1,25× para escrever um cache que ninguém lê. Gerenciar bem o que entra no prefixo é o mesmo problema tratado em por que seu agente esquece, visto pelo lado da fatura.

Cinco configurações mexem no preço sem aparecer como decisão de custo.

A primeira linha merece atenção especial, porque é invisível.

Os modelos Claude 4.7 e posteriores usam um tokenizador novo, que produz cerca de 30% mais tokens para o mesmo texto. A documentação diz isso de forma explícita, e acrescenta que o aumento exato depende do conteúdo e do formato da carga.

Isso significa que uma migração pode custar mais caro mesmo com preço por token menor. O Sonnet 4.6 custa US$ 3 por milhão de tokens de entrada e usa o tokenizador antigo. O Sonnet 5 custa US$ 2 e usa o novo:

preço:    −33,3%
tokens:   +30% pelo mesmo texto
efetivo:  0,667 × 1,30 = −13,3%

Um corte anunciado como 33% vale perto de 13% na prática.

Essa conta é derivada, não medida. Ela vale se os 30% se aplicarem à sua carga, e a própria documentação avisa que isso varia. Meça a sua com o endpoint de contagem de tokens antes de planejar orçamento em cima do número anunciado. O ponto não é o valor exato: é que o preço por token deixou de ser comparável entre gerações de modelo.

Uma nota de calendário: o preço promocional de US$ 2/US$ 10 do Sonnet 5 virou padrão, e o aumento para US$ 3/US$ 15 previsto para 1º de setembro de 2026 foi cancelado.

Este é o grupo mais caro, porque o gasto aqui é deliberado.

O estudo do SWE-bench mediu a relação entre tokens gastos e acerto. Ela não é crescente. A acurácia pica em custo intermediário e satura depois. Passado esse ponto, tokens adicionais compram variância, não resultado.

Dois achados do mesmo trabalho reforçam isso:

• Execuções idênticas da mesma tarefa diferem em até 30× no total de tokens.
• Kimi-K2 e Claude Sonnet 4.5 consomem, em média, 1,5 milhão de tokens a mais que o GPT-5 nas mesmas tarefas.

Há ainda uma consequência operacional séria. Os modelos não sabem prever o próprio custo: a correlação entre previsão e gasto real chega a apenas 0,39, e a subestimação é sistemática.

Isso encerra a ideia de teto de gasto por bom senso do agente. Ele não tem como saber quanto vai gastar antes de começar, porque não consegue prever o acúmulo de contexto nem a trajetória que vai tomar.

Um catálogo de junho de 2026 documenta o resultado disso em produção. Token Budgets, de Sajjad Khan, reúne 63 incidentes confirmados de estouro de orçamento em 21 frameworks de orquestração, entre 2023 e 2026. Cada um vem com a issue do GitHub citada e, quando reportada, a perda em dólar. A taxonomia tem oito clusters, com kappa de Cohen de 0,837 sobre 113 itens (arXiv 2606.04056).

Teto de gasto é engenharia, com corte no código. Não é alerta em planilha.

O caminho para gastar menos, então, não é comprar mais tokens melhores. É reduzir passos. Foi o que a medição sobre contexto longo e recuperação mostrou por outro ângulo, e é o que memória de agente resolve na prática: menos passos significam menos contexto reenviado, e o custo cai de forma não linear.

Os três grandes cobram cache com estruturas distintas. Cada um, por isso, falha de um jeito próprio.

Dados lidos em 28/08/2026 na documentação da Anthropic e na documentação da OpenAI, mais as tabelas de preço publicadas do Gemini.

O modo de errar segue a estrutura:

• Anthropic pune quem escreve um cache que não reusa. Escreveu e não releu, pagou 25% a mais.
• Google pune quem aluga um cache que ninguém lê. O armazenamento é cobrado por hora, com ou sem acerto.
• OpenAI não pune. E é justamente por isso que o vazamento dela é o mais difícil de achar: sem prêmio de escrita e sem breakpoint sob seu controle, um prefixo mutável não gera erro, não gera linha na fatura, apenas não economiza.

O batch é mais uniforme. Anthropic e OpenAI dão 50% de desconto sobre entrada e saída. A Anthropic aceita até 100.000 requisições ou 256 MB, expira em 24 horas e guarda resultados por 29 dias. A OpenAI trabalha com até 50.000 requisições e arquivos de 200 MB, em janela fixa de 24 horas.

Um detalhe que quase ninguém documenta: o desconto de batch empilha com o cache. E, dentro de um batch, use TTL de 1 hora. O de 5 minutos tende a expirar antes que os itens sejam processados, e o pré-aquecimento com max_tokens: 0 não funciona ali.

Premissa comum: prefixo de 20.000 tokens entre system prompt e definições de ferramenta, 500 requisições por dia, Sonnet 5 a US$ 2 por milhão de tokens de entrada.

500 req × 20.000 tok × US$ 2 / 1.000.000 = US$ 20,00 por dia
US$ 20,00 × 30 = US$ 600 por mês

escritas: 50 × 20.000 × US$ 2,50 / 1.000.000 = US$ 2,50
leituras: 450 × 20.000 × US$ 0,20 / 1.000.000 = US$ 1,80
total:    US$ 4,30 por dia = US$ 129 por mês

US$ 129 ÷ 2 = US$ 64,50 por mês

sem cache: 500 × 6.600 × US$ 2 / 1.000.000    = US$ 6,60/dia = US$ 198/mês
em cache:  500 × 6.600 × US$ 0,20 / 1.000.000 = US$ 0,66/dia = US$ 19,80/mês

Em ordem de retorno por hora de trabalho:

1. Procure o breakpoint móvel. Busque por timestamp, UUID, nome de usuário ou data dentro do system prompt. É o conserto mais barato e o de maior efeito.
2. Meça a taxa de acerto. Some cache_read_input_tokens e cache_creation_input_tokens por rota. A razão entre eles diz tudo.
3. Conte a sobrecarga de ferramenta. Multiplique os tokens de definição pelo volume mensal. Ferramenta que o agente nunca chama sai.
4. Mova o assíncrono para batch. Relatório, backfill, classificação em lote e avaliação: nada disso precisa de resposta imediata.
5. Ponha teto por sessão, no código. Não em alerta. Os 63 incidentes do catálogo existem porque alerta não interrompe execução.

Se o seu caso é o Claude Code por assinatura, e não a API por token, a conta é outra e está em quanto custa cada padrão de uso do Claude Code. Este post trata de API em escala, onde você paga por token e controla o prefixo.

E existe a saída que zera o custo por token: rodar o modelo na sua máquina. Ela troca custo variável por custo de hardware e de operação, com um teto de qualidade mais baixo — o que cabe no seu laptop em 2026 faz essa conta.

<!-- [PERSONAL EXPERIENCE] -->

Produzir este cluster de dezesseis posts me deu um exemplo desconfortável do vazamento número um.

A pesquisa de cada post envolve ler artigos primários. Vários deles são PDFs do arXiv. E a documentação da Anthropic é direta sobre o que isso custa: um artigo científico em PDF de 500 kB equivale a cerca de 125 mil tokens de entrada.

Cada busca de fato verificado que terminava num PDF acadêmico entrava no contexto com esse peso. E, como a leitura era única, cachear não ajudaria: pela tabela deste post, escrever cache para uma leitura só custa 25% a mais, não menos.

A correção não foi técnica. Foi de método: passei a ler o abstract pela página HTML antes de decidir se o PDF inteiro valia o gasto. Na maior parte das vezes, o abstract já continha o número que eu precisava verificar — como aconteceu com os dois artigos citados aqui.

O julgamento que sobra é este: cache não é a resposta para tudo. Para conteúdo lido uma vez, ele aumenta a conta. A pergunta certa nunca é "dá para cachear?", e sim "quantas vezes vou reler isto?".

Cache de prompt vale a pena para poucas requisições?

Depende do TTL. No cache de 5 minutos, o equilíbrio fica em 1,28 requisição, então a segunda leitura já economiza 32,5%. No de 1 hora, o equilíbrio é 2,11: com apenas duas requisições você ainda perde 5%. Para uso único, cache sempre sai mais caro.

Cache de 1 hora é sempre melhor que o de 5 minutos?

Não. Ele custa 2× para escrever, contra 1,25× do TTL curto. Compensa quando o intervalo entre requisições passa de cinco minutos, ou dentro de batch, onde o processamento demora mais que a janela curta. Com poucas leituras, o TTL longo é a opção mais cara.

Batch e cache podem ser usados juntos?

Sim, e os descontos se acumulam. Um fluxo com cache que cai de US$ 600 para US$ 129 por mês vai a US$ 64,50 com batch. Dentro de um batch, use TTL de 1 hora: o de 5 minutos costuma expirar antes do processamento, e o pré-aquecimento com max_tokens: 0 não é aceito ali.

Por que minha taxa de acerto de cache é zero?

As três causas mais comuns são breakpoint em cima de conteúdo variável, como timestamp ou ID de sessão; prompt abaixo do mínimo cacheável do modelo, que vai de 512 a 4.096 tokens; e alteração em definições de ferramenta, que invalida todos os níveis em cascata. Nenhuma das três gera mensagem de erro.

Trocar para um modelo mais barato sempre reduz a conta?

Não, porque o preço por token deixou de ser comparável entre gerações. O tokenizador do Claude 4.7 e posteriores gera cerca de 30% mais tokens pelo mesmo texto. Um corte de preço de 33% pode valer perto de 13% na prática. Meça sua carga real no endpoint de contagem antes de projetar economia.

Dá para estimar o custo de uma tarefa antes de rodar?

Com precisão baixa. O estudo do SWE-bench mediu correlação de até 0,39 entre a previsão dos modelos e o gasto real, com subestimação sistemática. A mesma tarefa varia até 30× entre execuções idênticas. Por isso o controle tem que ser teto imposto em código, e não estimativa.

• O custo mora no input reenviado, não no prompt nem na saída. Cortar passos rende mais que cortar palavras.
• O cache de 5 minutos paga na segunda requisição. O de 1 hora, só na terceira.
• Definição de ferramenta é cobrada em toda requisição. Some antes de adicionar mais uma.
• A cascata de invalidação começa em tools. Mudou ferramenta, perdeu o cache inteiro.
• Preço por token não é mais comparável entre gerações de modelo, por causa do tokenizador.
• Gastar mais não compra acerto. Depois do pico intermediário, tokens extras compram variância.
• Teto de gasto é código, não alerta. Sessenta e três incidentes documentados dizem por quê.

Todos os preços e multiplicadores citados foram lidos na documentação oficial em 28 de agosto de 2026. Preço de LLM muda rápido: confira na fonte antes de planejar orçamento em cima deles.