Os cinco mil dólares que não vês na factura: porque o cache é o teu balanço escondido

Artigo 4 de 10 da série The Token Economy. A tua factura mostra o que gastaste. Nunca mostra o que evitaste gastar. Na minha operação, o que evitei foi quatro vezes e meia o que paguei, e não aparece em lado nenhum.

Depois de três artigos sobre custos que sobem em silêncio, este vira a moeda. O cache é a maior alavanca que tens para baixar a factura de IA. Na minha operação evitou cinco mil dólares sobre mil e cem de gasto real. E quase ninguém o mede, porque a poupança nunca aparece na conta.

A pergunta que o teu balanço não mostra

A tua factura de IA é uma demonstração de resultados: diz o que gastaste no mês. O que ela nunca te diz é o outro lado da história, o que poderias ter gasto e não gastaste porque o sistema reaproveitou contexto em vez de o voltar a comprar a preço inteiro. Esse valor existe, é grande, e é invisível.

Chama-se poupança de cache. É dinheiro que não saiu da tua conta porque o fornecedor “lembrou-se” de um pedaço de contexto que já tinha lido, em vez de o cobrar outra vez do zero. Numa operação com IA agêntica, onde o mesmo contexto (instruções, documentos, histórico) é reenviado dezenas de vezes por tarefa, essa poupança pode ser várias vezes maior do que a própria factura. Mas como não aparece como uma linha no painel, a maioria das equipas nunca a calcula, e portanto nunca sabe se a está a capturar ou a deitar fora.

A pergunta certa não é “quanto gastei em tokens?”. É esta: “de tudo o que reenvio ao modelo, que parte estou a pagar a preço cheio e que parte estou a pagar com desconto?” A resposta a essa pergunta é o teu balanço escondido. E como qualquer balanço, ou o lês, ou não fazes ideia de quão saudável está a tua operação.

No artigo 1 mostrei que um token tem cinco preços. No 2, que o número de tokens é instável entre versões. No 3, que um sistema agêntico gera dez tokens internos por cada um que lês. Hoje mostro a única destas forças que joga a teu favor: o cache, a alavanca que transforma o custo do contexto repetido numa fracção do que custaria sem ela.

O conceito: o cache é tesouraria, não tecnologia

Esquece a palavra “cache” por um minuto. Pensa em gestão de tesouraria.

Quando dás uma tarefa a um sistema de IA, grande parte do que lhe envias repete-se a cada chamada: as instruções de sistema, o documento que está a analisar, o histórico da conversa, os exemplos. O modelo precisa de “ler” tudo isto antes de produzir qualquer coisa. Sem cache, ele lê tudo de novo a cada chamada, e tu pagas a leitura inteira de cada vez, como se fosse a primeira.

O cache muda a economia. Na primeira vez, o fornecedor lê o contexto e guarda-o numa memória de curto prazo. A isso chama-se escrita em cache, e custa um pouco mais do que uma leitura normal, é o prémio que pagas para registar. Em todas as chamadas seguintes que reutilizam esse mesmo contexto, o fornecedor já não o relê: vai buscá-lo à memória. A isso chama-se leitura de cache, e custa um décimo do preço de uma leitura normal. Noventa por cento de desconto, em cada reutilização.

Para que vejas a mecânica em números, com o modelo que domina a minha operação:

Operação sobre o contexto	Preço por milhão de tokens	Relativo ao input
Leitura normal (input)	$5,00	1×
Escrita em cache (5 min)	$6,25	1,25×
Escrita em cache (1 hora)	$10,00	2×
Leitura de cache	$0,50	0,1×

Input e leitura de cache: preços oficiais Opus 4.7, snapshot de 1 de Junho de 2026. Escritas de cache (1,25× e 2× do input): a estrutura de 5 componentes do artigo 1. O cache só se aplica ao input, ao contexto; o output (a resposta gerada) nunca é cacheável e custa sempre o preço cheio. Os preços e o rácio de dez para um são deste modelo: noutros fornecedores a mecânica é a mesma (leitura de cache muito mais barata que leitura nova) mas os múltiplos mudam. O que viaja é o método, não os números.

É exactamente gestão de tesouraria. Pagas um pequeno prémio uma vez para registar o contexto (a escrita), e a partir daí cada reutilização rende um desconto de noventa por cento (a leitura). Contexto reenviado a preço inteiro, chamada após chamada, é o equivalente a deixar capital parado numa conta sem juros: o dinheiro está a trabalhar contra ti em vez de a teu favor. Cada token que poderias ter servido do cache e serviste a preço cheio é margem que deixaste em cima da mesa.

Porque é que esta poupança fica invisível

Vale a pena perceber porque é que uma alavanca desta dimensão não está em cima da mesa de toda a gente. Outra vez, não é conspiração. É a forma como a conta é apresentada.

O painel do fornecedor mostra-te o que pagaste. Não te mostra o contrafactual, o que terias pago sem cache, porque esse número não é um facto contabilístico, é um cálculo que depende de saber quanto do teu input foi servido de cache e quanto seria leitura nova. O fornecedor tem os dados para o fazer, mas não tem incentivo nenhum para te apresentar uma estimativa do dinheiro que te poupou. Mostra a factura, e a factura é, por definição, só o que saiu.

Há um segundo motivo, mais técnico. A poupança de cache não é um único número, é o resultado de uma proporção: quanto do teu contexto chega como leitura de cache (barato), quanto chega como leitura nova (caro), e quanto gastas a escrever em cache (o prémio). Para saberes se estás a ganhar, tens de juntar estas três peças e pô-las em rácio. A maioria das ferramentas de monitorização dá-te os números soltos, mas não fecha o rácio por ti. Vês input, vês cache, mas não vês a saúde da operação.

E há um terceiro, o mesmo que percorre toda esta série. Enquanto corres em cima de uma subscrição de preço fixo, a poupança de cache não te muda a conta ao fim do mês: pagas o mesmo flat com cache ou sem ele. Então não tens incentivo para a medir. O cache está a trabalhar (ou a não trabalhar), mas o sinal de preço que te diria está abafado pela mensalidade. Voltamos a este ponto mais à frente, porque é precisamente no dia em que sais da subscrição que esta alavanca decide se a tua operação é viável.

Os dados: $5.104 evitados sobre $1.140 gastos

No Prism, a engine proprietária que construí para medir o custo real de cada token que consumo, a poupança de cache não é uma promessa de vendedor. É uma leitura.

Pega no snapshot real, congelado a 1 de Junho de 2026: 490 tarefas, 42 sessões, 18 dias de trabalho (14 de Maio a 1 de Junho). Neste período:

• A minha factura-API real foi $1.140, calculada a preço oficial como se faturada via API.
• A poupança de cache, o custo que evitei por servir contexto do cache em vez de o reler a preço inteiro, foi $5.104.
• Por outras palavras: sem cache, a minha factura total teria sido cerca de $6.244 em vez dos $1.140 que paguei. O cache cortou perto de 82% do que a conta teria sido.

Uma ressalva honesta antes de leres este número como uma factura de que fugiste: estes $6.244 não são uma conta que alguém me mandou. São o que o mesmo trabalho custaria se eu tivesse relido todo o contexto a preço cheio, coisa que ninguém desenha de propósito. O valor real do cache não é “escapei a uma factura de seis mil”, é “o cache torna desnecessário um custo que de outra forma terias de orçamentar”. É esse custo que não tens de orçamentar que chamo o teu balanço escondido.

Lê outra vez, é a mesma poupança vista do outro lado: por cada dólar que efectivamente gastei, o cache tornou desnecessários outros quatro e meio. A alavanca não é marginal. É a diferença entre uma operação com IA agêntica que fecha as contas e uma que sangra margem sem ninguém reparar.

O número que resume a saúde desta alavanca chama-se E_cache, a eficiência de cache. É a fracção do meu input que foi servida do cache em vez de lida de novo:

E_cache = leituras de cache / (input novo + leituras de cache + escritas de cache)

No snapshot, o meu E_cache foi 96,2%. Quer dizer que mais de noventa e seis por cento de todo o contexto que o sistema processou veio da memória barata, e não da leitura cara. É um valor alto, e é alto por desenho: o meu sistema reutiliza contexto de forma agressiva e estável, que é exactamente onde o cache rende mais.

Frescura tem um preço

Há uma armadilha dentro desta alavanca, e é o reverso da medalha. A escrita em cache não é grátis: custa um prémio sobre a leitura normal (1,25× para a memória de cinco minutos, 2× para a de uma hora, na tabela acima). Se reescreves contexto em cache com demasiada frequência, por exemplo porque mudas uma vírgula nas instruções a cada chamada e invalidas tudo o que estava guardado, pagas o prémio de escrita uma e outra vez sem nunca colher leituras suficientes para o compensar. Frescura excessiva come a poupança.

Mas há um reverso mais perigoso do que o prémio de escrita. O cache poupa servindo contexto que já leu, e contexto que já leu é contexto que pode ter envelhecido. Um E_cache alto obtido a nunca reescrever não é saúde: é o risco de o sistema responder com base num preço, num documento ou numa regra que entretanto mudou. A frescura tem dois custos: o prémio que pagas a mais quando reescreves, e a resposta errada que pagas quando serves contexto fora de data. O alvo não é cache máximo. É cache máximo sobre o contexto que ainda é verdade.

A regra prática: a escrita só compensa se for seguida de leituras que cheguem para pagar o prémio. A memória de uma hora custa mais a registar (2× em vez de 1,25×), mas se vais reutilizar o mesmo contexto ao longo de uma sessão longa, paga-se de sobra, porque evita reescritas. A de cinco minutos chega para rajadas curtas. O sinal de alarme é simples: se a tua fatia de escrita em cache começa a aproximar-se da tua fatia de leitura, não estás a fazer caching, estás a pagar o prémio sem o desconto. Mantém o contexto estável o suficiente para o reutilizares antes de o substituíres.

O que este número não é

O 96,2% é o meu, da minha operação, do meu padrão de uso. O teu E_cache vai ser diferente, e provavelmente mais baixo, porque eu corro um sistema com contexto muito reutilizado e muito estável. Uma aplicação com pedidos sempre diferentes, sem contexto partilhado entre chamadas, tem menos para cachear e um E_cache naturalmente menor. O ponto não é que o teu seja 96%. É que tu não sabes qual é, e isso significa que não sabes quanta margem estás a deixar na mesa. Um E_cache baixo não é necessariamente mau (depende do teu padrão), mas um E_cache que ninguém mede é sempre uma decisão tomada às cegas.

O framework: E_cache por workflow

A boa notícia é que isto se mede, e a régua é a mesma seja qual for a ferramenta. Aqui está a sequência mínima.

Passo 1: separa as três fatias do input

Para cada workflow, soma três coisas em vez de uma: os tokens de leitura nova (input a preço cheio), os tokens de leitura de cache (a 10%), e os tokens de escrita em cache (o prémio). A maioria dos painéis junta tudo num só “input”. Tens de os separar, porque é a relação entre eles que conta a história. Os gateways de IA que já contam tokens (LiteLLM, Helicone, Portkey) expõem estas categorias por chamada; o que falta, quase sempre, é alguém somá-las por workflow e fechar o rácio.

Passo 2: calcula o E_cache e a poupança evitada

E_cache = leituras de cache / (input novo + leituras de cache + escritas de cache)
poupança = leituras de cache vezes (preço de input menos preço de leitura de cache)

O E_cache diz-te a saúde (que fracção do contexto vem do barato). A poupança diz-te o valor em euros que essa saúde representa. Apresenta sempre os dois: o rácio convence o engenheiro, o número em euros convence o CFO. São o mesmo facto em duas línguas.

Passo 3: compara com a régua

Um E_cache isolado não diz nada. Comparado com uma expectativa, diz tudo. A régua que uso, e que te proponho como ponto de partida e não como lei:

• E_cache acima de 85% num workflow com contexto repetido (agentes, RAG, assistentes com instruções fixas). Abaixo disto, há contexto a ser relido que devia estar em cache.
• Fatia de escrita bem abaixo da fatia de leitura. Se a escrita se aproxima da leitura, estás a invalidar cache de mais. Investiga o que muda o contexto a cada chamada.
• Poupança reportada todos os meses, em euros. Se o teu relatório de custo de IA não tem uma linha “custo de cache evitado”, falta-te metade do balanço.
• E_cache alto só conta sobre contexto vivo. Não subas o rácio à custa de servir documentos, preços ou regras desactualizados. Cache de contexto que já mudou é uma resposta errada servida barato, que é a forma mais cara de poupar.

A régua é tua para ajustares. O que não é negociável é teres uma. Sem expectativa, qualquer E_cache parece aceitável, e é assim que operações deixam milhares de euros de margem na mesa durante meses sem ninguém dar por isso.

Onde isto encaixa no quadro maior

No modelo de custo desta série, o Token Resilience Architecture (TRA), o custo-API é o produto de várias forças: o preço por token (artigo 1), quantos tokens cada texto consome (artigo 2), o multiplicador agêntico que inflaciona o volume (artigo 3). O E_cache é a única destas forças que joga a teu favor: é o divisor, a alavanca que baixa o custo efectivo do contexto. Um alfa alto (muito tráfego interno) com um E_cache alto é gerível, porque a maior parte desse tráfego repetido é servido barato. Um alfa alto com um E_cache baixo é uma sangria. As duas leituras vivem lado a lado, e só fazem sentido juntas.

A poupança que viaja contigo para a API

Há uma razão pela qual esta alavanca importa muito mais do que parece, e tem que ver com o tema que percorre toda a série: o dia em que sais da subscrição.

Enquanto corres em preço fixo, o cache trabalha em silêncio e tu não sentes a diferença, pagas o flat de qualquer maneira. Mas no dia em que a tua aplicação passa a ser faturada via API, cada token de contexto reenviado deixa de ser indolor e passa a ser uma linha na conta. É exactamente nesse momento que o E_cache decide se as tuas contas fecham. Uma operação com E_cache de 96% paga, no lado do contexto, uma fracção do que uma operação idêntica com E_cache de 40% paga pelo mesmo trabalho. Mesmo produto, mesma resposta ao utilizador, factura várias vezes diferente.

E ao contrário de quase tudo o resto nesta série, esta é a notícia boa. As outras forças (o tokenizer, o alfa, a cauda do worst-case) trabalham contra ti e tens de as conter. O cache trabalha a teu favor, e a única coisa que precisas de fazer é medi-lo e protegê-lo. É a alavanca que já está montada na tua operação à espera que alguém a leia. Quem chega ao dia da migração com um E_cache alto e estável tem uma defesa que o concorrente que nunca o mediu não tem. Mede agora, enquanto a subscrição ainda esconde o sinal, e chegas à API com a margem já garantida.

A decisão para esta semana

Três acções concretas para quem reconhece o problema.

1. Pede a tua poupança de cache do mês, em euros.

Não o gasto total, não os tokens totais. O valor que o cache te evitou pagar, e o E_cache que o produziu. Se o relatório vier sem essa linha, ou pior, se vier “zero” ou “n/d”, tens duas hipóteses: ou não estás a usar cache de todo (estás a pagar contexto repetido a preço cheio), ou estás a usá-lo e ninguém o mede. As duas custam dinheiro. A pergunta sozinha já te diz em que pé estás. E uma ressalva, se ainda corres em subscrição de preço fixo: a tua poupança em euros hoje é zero, pagas o mesmo flat com ou sem cache, e está certo que assim seja. O número que pedes agora não é a factura deste mês, é o custo evitado calculado a preço de API, o que esta operação custaria se fosse faturada ao token. Pede-o à mesma: é o ensaio do número que passa a ser real no dia em que migras, e é melhor descobrir que o teu E_cache é baixo agora, em ensaio, do que na primeira factura da API.

2. Verifica o equilíbrio entre escrita e leitura.

Pede a decomposição do input em três fatias: leitura nova, leitura de cache, escrita de cache. Se a escrita está perto da leitura, estás a invalidar cache de mais, a pagar o prémio sem colher o desconto. A causa quase sempre é contexto que muda quando não precisava (um timestamp, uma instrução reescrita, uma ordem trocada). Estabiliza o que é estável e a poupança aparece.

3. Põe o E_cache no relatório recorrente, ao lado do custo.

A poupança de cache não pode ser um cálculo que alguém faz uma vez por curiosidade. Tem de ser uma linha fixa no relatório de custo de IA, todos os meses, por workflow. É a única forma de a degradação aparecer enquanto ainda é barata de corrigir, em vez de aparecer na factura da API seis meses depois.

E uma não-acção, tão importante como as outras:

Não persigas um E_cache de 100% por princípio. Cache é uma ferramenta para contexto repetido, não um fim em si. Há workflows onde cada pedido é genuinamente diferente e quase não há nada para cachear, e forçar caching aí só te faz pagar prémios de escrita inúteis. O erro não é ter um E_cache baixo num workflow que não repete contexto. É não saber qual dos dois casos é o teu.

O número a seguir

E_cache = leituras de cache / (input novo + leituras de cache + escritas de cache), por workflow. Acima de 85% onde há contexto repetido. E reporta a poupança em euros ao lado, todos os meses. Se a tua factura de IA não tem uma linha para o dinheiro que o cache te poupou, estás a ler meia conta.

Próximo artigo

O artigo 5 vai ao número que separa o CFO experiente do optimista: o pior caso. Até aqui falámos de médias e totais, mas a média mente, esconde a cauda. Vais ver porque é que o percentil 95 do custo por tarefa, e não a média, é o número que devias orçamentar, e como uma única tarefa fora de controlo (um chatbot sem limite, um agente em loop) pode custar mais num dia do que o resto do mês inteiro. Quem orça pela média acorda com a factura da cauda.