Erros de Cache de Prompt Podem Custar à Sua Organização Quase 6x Mais a Cada Gira de IA

Desde então venho entendendo parte da razão. Uma pessoa pode voltar a uma conversa no dia seguinte, e qualquer hora que a conversa recebeu no início ficou obsoleta. Algo tem que fornecê-la novamente. Um harness, o programa ao redor de um modelo que monta cada solicitação e executa o loop, pode fazer isso escrevendo a hora atual nas instruções do modelo antes de cada solicitação. O runner de agente que usamos em produção fez exatamente isso.

Eu conheço o cache de prompt há muito tempo. Os provedores armazenam o início de uma solicitação e cobram a uma fração do preço quando a próxima solicitação começa da mesma forma. Eu não conhecia bem sua mecânica para ver o que uma linha como a hora faz a ele. Descobrimos a resposta em nossos próprios custos de produção, e direcionei um conjunto de experimentos para medir isso corretamente, em um modelo atual de cada um dos 4 labs e contra as figuras públicas da OpenRouter sobre o que todo mundo está pagando.

A resposta é cara. No GPT-6 Luna, a hora escrita no lugar errado fez cada turno de uma conversa custar 5.7× o que precisava, e nada gerou erro. Em todas as organizações de tráfego enviam esses modelos, a entrada é 96–99% dos tokens e 66–87% dos dólares realmente pagos, então o cache decide a maior parte da fatura. Para uma organização que constrói seu próprio harness, executa uma plataforma interna de IA ou envia produtos de IA, um erro como este multiplica o custo de cada turno, silenciosamente, enquanto durar o funcionamento.

Cada número por turno aqui foi medido em 23 de setembro de 2026, através de OpenRouter. As cifras de mercado são próprias de OpenRouter, lidas no mesmo dia.

Cada chamada a um modelo envia a conversa inteira novamente: as definições de ferramenta, o prompt do sistema (as instruções permanentes que o harness escreve), cada turno anterior, e a nova mensagem.

Os provedores mantêm o início processado das solicitações recentes. Quando a próxima solicitação começa com o mesmo texto, o provedor lê esse prefixo armazenado em vez de processá-lo novamente. No GPT-6 Luna, OpenRouter cobrou uma leitura em 0.10× o preço de entrada listado e a primeira escrita em 1.25×. Um prompt que é escrito novamente em cada turno, portanto, custa mais do que um prompt sem cache nenhum.

Apenas o início de uma solicitação pode ser reutilizado. Uma mudança em qualquer ponto invalida tudo depois dela:

graph LR
    A[Definições de ferramenta] --> B[Prompt do sistema]
    B --> C[Turnos anteriores]
    C --> D[Nova mensagem do usuário]
    B -. a changed line here voids B, C and D .-> D

Qualquer coisa que o harness escreve perto do início e muda em cada turno coloca toda a conversa atrás dela em risco. O horário atual é o exemplo mais simples.

A descoberta começou em um agente que executamos em produção. O livro de custos dele precificava cada chamada ao preço de lista e não mostrava nenhuma cache em absoluto. Eu alertei e comecei a ponderar uma mudança para um modelo diferente.

O agente com o qual eu estava trabalhando descobriu primeiro que o próprio livro estava errado. Em 33 chamadas estimou $0.064; o provedor faturou $0.023, 2.7× menos. Precificar cada chamada a partir das contagens de token apagou todos os descontos que o provedor aplicava. Ler o custo relatado pelo provedor mostrou que a cache funcionava dentro de cada turno e falhava no início de cada novo.

Sua primeira explicação foi uma chave de sessão ausente que manteria as solicitações no mesmo servidor. Sua própria sondagem refutou isso: prompts idênticos já eram lidos da cache entre turnos no GPT-6 Luna, e adicionar uma chave de sessão, uma chave de cache ou um marcador de cache explícito não mudou nada. A causa estava no próprio prompt do sistema. Cerca de 95% do caminho, o runner escreveu duas linhas que mudavam a cada turno: um diretório de trabalho por turno e um relógio ao minuto. Cada primeira chamada de um turno escrevia o prompt inteiro novamente em 1.25×.

Mover ambas as linhas para o fim da mensagem do usuário corrigiu em produção. Turnos 2 e 3 agora abrem em 0.47–0.51× em vez de 1.25×. O restante é um bloco de contexto por turno que o runner ainda envia na mensagem do usuário.

Minha suposição, antes que qualquer coisa disso fosse medida, era que uma verificação determinística poderia fornecer o tempo apenas quando ele se tornasse obsoleto, como uma mensagem separada, e deixar o resto do prompt em cache. Ele funciona, com uma condição, e essa condição é a regra que o resto do artigo segue.

Para testá-lo diretamente, construímos um probe que executa a mesma conversa com o relógio em lugares diferentes, alternando 65 segundos para que o minuto mude entre cada par. GPT-6 Luna, um prompt de sistema de 8.5K tokens, 3 replica:

Minha mensagem separada manteve o cache em ambas as formas, a cada turno e apenas quando obsoleto. A condição é onde a mensagem fica. Após as instruções estáveis, o provedor lê tudo antes dela. Como uma segunda mensagem do sistema, ela fica entre as instruções, e o GPT-6 Luna reescreveu todo o prompt novamente em 12 de 12 turnos.

A regra que segue é curta. Tudo que muda entre turnos vai depois de tudo que não muda.

O cache compara texto, então um relógio é inofensivo enquanto seu texto permanecer o mesmo. No mesmo probe com alternâncias de 4 segundos, um relógio de minuto no prompt do sistema lida do cache a cada vez. Com alternâncias de 65 segundos, forçou uma reescrita completa a cada turno.

A resolução define com que frequência isso acontece. Um relógio de hora e uma linha de data no prompt do sistema ambos leem do cache em todas as aberturas de turno de 12 segundos das execuções de 65-segundos, porque nenhum rolou. Eles também quebram, uma vez por hora e uma vez por dia. Um relógio de minuto quebra em cada turno que começa em um minuto posterior ao anterior.

O próprio cache também expira. Em execuções pontuais, GPT-6 Luna ainda lida seu prefixo armazenado após 30 minutos de inatividade e reescreve todo o prompt em 1.25× depois de 60. DeepSeek V4.1 Flash lida após 10 minutos e falha depois de 60. Claude Opus 5.5 já havia falhado depois de 10, já que o cache padrão da Anthropic dura 5 minutos e seu cache de 1 horas custa 2× para escrever. A pessoa que volta a uma conversa no dia seguinte, o caso que este artigo começou, encontra tanto um tempo obsoleto quanto um cache frio em todos os três. Esse primeiro retorno paga pelo prompt inteiro, independentemente do que o harness fizer. O posicionamento decide se os turnos depois dele também fazem isso.

GPT-6 Luna é a resposta de um provedor. Para ver quão geral é a lição, executamos os mesmos posicionamentos em um modelo atual de cada um dos labs 4, com um prompt de token 2.5K idêntico, cada um ancorado a um único provedor:

GPT-6 Luna armazena em cache mensagens inteiras. Uma linha alterada invalida a mensagem que a contém e tudo que vem depois.

Claude Opus 5.5 armazena onde o chamador marca. Os modelos da Anthropic armazenam em cache apenas até um marcador cache_control que o harness coloca. Sem marcador, o mesmo prompt foi faturado ao preço total em cada chamada. Com o marcador no prompt do sistema, um relógio dentro desse bloco custou 1.24×, enquanto um relógio em uma segunda mensagem do sistema depois dele leu em 0.08×. O posicionamento que GPT-6 Luna pune é seguro no Opus. Nos preços do Opus, a diferença por abertura de turno foi $0.0214 contra $0.0023. O Opus também contou o prompt idêntico como 4,056 tokens onde o GPT-6 Luna contou 2,395, então o mesmo texto custa 1.69× mais tokens antes de qualquer preço ser aplicado.

DeepSeek V4.1 Flash armazena em cache em blocos de 256 tokens e não cobra nada extra para escrever. As leituras retornaram em múltiplos exatos de 256: 2.560 tokens para o prompt inalterado, 2.304 com o relógio no final do prompt do sistema. Uma linha alterada custa apenas o bloco que a contém. As primeiras chamadas foram faturadas ao preço de entrada simples, e as leituras em 0.03–0.04×. Em 8 execuções por posicionamento, 2 chamadas únicas perderam o cache em um turno que a mesma execução então leu, o que aparece como a requisição aterrissando em um servidor diferente em vez de um efeito de posicionamento. O próprio endpoint do DeepSeek é o único que OpenRouter marca como cache automático, e a configuração de privacidade da minha conta o exclui porque esse endpoint treina em tráfego pago. As execuções passaram por DeepInfra, que armazenou em cache, assim como Fireworks e Morph em uma verificação de 2 chamadas.

Muse Spark 1.3 lê seu cache dentro de um loop de ferramenta e falha no início de cada novo turno. Nossos primeiros testes, que fazem uma nova pergunta contra o mesmo prompt do sistema, serviram no máximo 113 tokens do cache em 10 chamadas, em 2.9K, 8.9K e 19.4K tokens. Quando uma chamada de acompanhamento estendeu o pedido anterior, como o loop de ferramentas de um agente faz, Muse leu 2,801 de 2,966 tokens e faturou 0.17×. A próxima vez do usuário, com todo o histórico em frente a ele, não leu nada. OpenRouter relata uma taxa de acerto de cache 86.1% para Muse em tráfego ao vivo, que se encaixa em uma carga de trabalho dominada por loops de ferramentas. No início de uma rodada o relógio não faz diferença no Muse, já que essa chamada falha de qualquer forma.

A mesma decisão de harness custa uma quantia diferente em cada modelo. Saber qual mecanismo seu provedor usa vem antes de ajustar qualquer coisa.

Esperávamos que as trocas em cache respondessem mais rápido. Em 10 pares sequenciais de chamadas GPT-6 Luna em 8.5K tokens, a primeira chamada mediana levou 437 ms do cache e 490 ms sem ele. Essa lacuna está dentro da dispersão das amostras. Nesse tamanho, o cache altera o custo de uma troca e deixa o tempo que leva praticamente o mesmo.

Então a pausa que lembro quando pergunto a hora tem outra causa. O que um relógio no lugar errado custa é dinheiro.

Um relógio no prompt do sistema fica à frente de toda a conversa, então cada reescrita cobre o histórico crescente atrás dele, bem como as instruções. Aqui está o custo medido de uma conversa GPT-6 Luna de 12 trocas, com a fatura completa reportada pelo provedor, incluindo saída e as chamadas dentro de cada troca:

As duas linhas compartilham sua primeira troca, quando ambos escrevem o cache. A partir daí, cada troca com o relógio no prompt do sistema custa 5.7× o que a mesma troca custa com o relógio no final da mensagem do usuário. Por volta da troca 12 a conversa já tinha custado 4.1× tanto, e a lacuna aumenta a cada troca.

Frações de centavo tornam-se um item de linha em escala. Esta projeção precifica a primeira chamada de cada troca para um produto que atende 10,000 conversas por dia, cada uma com um prompt do sistema de 8.5K tokens, 20 trocas, e histórico crescendo 1,500 tokens por troca. Cada modelo usa seu preço listado e o comportamento de cache que mostrou acima:

Os blocos do DeepSeek mantêm o prompt do sistema quando o relógio muda, e o modelo ainda sai 13× mais caro, porque o histórico atrás do relógio ultrapassa as instruções em poucos turnos. Muse Spark mostra o outro lado: ele perdeu no início de cada turno em nossas execuções, então a colocação não economizou nada lá e cada abertura de turno pagou o preço total, $2.1M por ano pelo mesmo tráfego.

Nossas medições usam um prompt controlado. OpenRouter publica o que os mesmos modelos custam no tráfego de todos, e o mesmo mecanismo aparece lá em escala. Quase tudo enviado a esses modelos é entrada: 96,3% dos tokens do GPT-6 Luna em seu primeiro dia, 98,5% dos do Claude Opus 5.5 e DeepSeek V4.1 Flash, e 98,9% do Muse Spark 1.3. A entrada é onde a cache aplica, então a taxa de acerto define a maior parte do que uma empresa paga.

Clientes pagaram $0.87 por milhão de tokens de entrada para o Claude Opus 5.5 contra um listado $4.00, $0.30 contra $1.25 para o Muse Spark 1.3, e $0.036 contra $0.10 para o GPT-6 Luna. Em endpoints que servem o mesmo modelo no mesmo dia, o preço pago segue a taxa de acerto:

Preço de cada falha como escrita de cache e cada acerto como leitura prevê os preços publicados de cada um dos 5 principais endpoints dentro de 2–13%. A taxa de acerto sozinho explica a variação. No GPT-6 Luna o mesmo padrão corre de $0.025 a uma taxa de acerto de 88.1% até $0.075 a 49.4%, um fator de 3.

A mesma decisão de posicionamento afeta de maneira diferente cada tipo de organização que constrói sobre essas APIs.

Os construtores de harness definem a taxa de acerto para todos os usuários de uma vez. Os 5 apps que enviaram mais tráfego do Claude Opus 5.5 no seu primeiro dia foram todos agentes, entre 2.9B e 16.3B tokens cada. Para um harness em 10B tokens de entrada por dia nesse modelo, cada ponto de taxa de acerto de cache vale $175K por ano. A diferença entre os endpoints 92.2% e 77.4% acima chega a $2.07M por ano nesse volume. Um relógio no prompt do sistema que reescreve cada abertura de turno custa entre $1.75M e $8.76M por ano, dependendo se as aberturas de turno são 1 chamada em 10 ou 1 em 2. A decisão também viaja: todo produto construído sobre um harness herda seu posicionamento. Enquanto escrevi isso, encontramos o mesmo relógio de prompt do sistema em um segundo harness nosso, que executa uma versão mais antiga do mesmo runner.

Empresas que operam uma plataforma interna de IA a definem para cada equipe por trás delas. Um gateway que carimba o prompt do sistema de cada solicitação com um carimbo de data/hora ou ID de solicitação para auditoria transforma as aberturas de turno de cada aplicação em gravações, independentemente do que as equipes constroem por cima. Contabilidade é a segunda exposição. Cobrado de volta ao preço de lista, os custos de entrada parecem 2.8× maiores que a fatura no GPT-6 Luna, 4.1× no Muse Spark 1.3 e 4.6× no Claude Opus 5.5. Nosso próprio livro contábil superestimou as chamadas 33 em 2.7×, e eu quase mudei de modelo com base nisso.

Empresas que lançam produtos de IA pagam isso em cada conversa. Dentro de uma conversa, o relógio mal colocado custou 5.7× por turno. Em um mercado, as apostas são maiores. Em 21 de setembro, o Muse Spark 1.3 processou 88,5B tokens de entrada através de OpenRouter. Ao preço de lista isso é $110.6K; os clientes pagaram $26.9K, e cada ponto de taxa de acerto nesse tráfego vale $355K por ano. O DeepSeek V4.1 Flash processou 2,68T tokens de entrada no mesmo dia, e aos preços de DeepInfra cada ponto vale $1,33M por ano. Esses números cobrem um roteador. Tráfego enviado diretamente aos provedores não aparece neles.

Cada um desses custos remonta ao mesmo mecanismo, e o mesmo vale para a solução. As convenções de harnesses de agente bem construídos leem como suas consequências:

A correção acima é uma única edição. As condições ao redor dela continuam se movendo. Um harness ganha uma nova âncora, um gateway começa a carimbar solicitações com um ID, uma equipe muda para um modelo com um mecanismo de cache diferente, um provedor muda quanto tempo um prefixo ocioso permanece quente. Os quatro modelos aqui fazem cache de quatro maneiras diferentes, e Claude Opus 5.5 deixa um cache esfriar dentro de 10 minutos de tempo ocioso. O segundo harness onde encontramos o mesmo relógio simplesmente permaneceu em uma versão mais antiga. Nada disso gera um erro.

Cada chamada já retorna o que é necessário para vê-la: tokens de prompt, tokens em cache, tokens de gravação em cache e o custo faturado. Registrado por chamada, junto com se a chamada abriu uma rodada ou continuou uma, esses campos dão três números que vale a pena observar para cada rota e modelo:

Um limite nesses números captura uma queda súbita. Nomear a causa ao longo de semanas de dados é um problema de classificação, e uma nova classe de modelo se adequa a isso. Jev, de TypeSafe, é o que seu criador chama de modelo System One. Não gera texto. Recebe um estado e perguntas tipadas e devolve respostas tipadas com uma distribuição de probabilidade e confiança: uma escolha entre opções, uma probabilidade de sim, ou uma posição em uma escala ordenada. Dado o perfil diário de cache de uma rota, pode nomear o padrão que o dia corresponde (saudável, reescrita de aberturas de turno, expiração de cache entre turnos, tráfego alcançando um endpoint que não faz cache) e dizer o quão certo está, de modo que uma mudança de categoria se torne o alerta. Usamos em produção para classificar documentos e, na observação, para pontuar episódios de agentes concluídos. OpenRouter lista em $0.042 por milhão de tokens de entrada sem cobrança por saída. A esse preço, classificar um perfil diário de 2K tokens para cada uma das 1,000 rotas custa cerca de $31 por ano, contra $175K por ano para um único ponto de taxa de acerto na escala de harness acima.

Um sistema que continua reescrevendo seu cache paga o prêmio em cada turno de cada conversa, enquanto funciona, e a conta raramente explica o motivo. A correção pode ser tão pequena quanto onde o tempo é escrito. Manter fixo requer um número que alguém observa.

Cada número medido acima vem dos próprios campos por chamada de OpenRouter (tokens em cache, tokens de escrita em cache e custo faturado) em 23 de setembro de 2026. Os números de mercado vêm das páginas públicas do modelo de OpenRouter lidas naquele dia: o preço de entrada ponderado realmente pago, o preço efetivo de cada endpoint e a taxa de acerto de cache, e um dia de atividade de tokens por modelo. Claude Opus 5.5 e GPT-6 Luna foram lançados em 22 de setembro, então suas figuras de atividade cobrem um primeiro dia parcial, e o artigo as usa apenas como participações. Os experimentos custaram $0.63 no total, e a sonda recusou iniciar quando o uso da conta se aproximou de um limite de $1. Os preços são os preços listados de OpenRouter lidos no mesmo dia. O guia de cache do OpenRouter lista OpenAI leituras de cache a 0.25–0.50×; GPT-6 Luna faturou suas leituras a 0.10×, e este artigo relata o que foi faturado.

Ainda aberto: o ponto exato em que o cache ocioso de cada modelo expira, que única execução temporizada apenas delimita; com que frequência um relógio de hora ou data quebra sobre lacunas reais de conversa; por que Muse Spark falhou no início de cada turno quando seu histórico não mudou; e o comportamento de DeepSeek em seu próprio endpoint. A correção por turno está ativa em nosso agente de produção, e a mesma descoberta foi enfileirada para um segundo harness que executa uma versão mais antiga do mesmo runner.

Por mim. A pergunta por trás do artigo: por que a IA nunca pareceu saber a data e hora bem, e demorou segundos para dizer quando deveria ser instantâneo. A ideia de que o tempo fica obsoleto ao longo de uma sessão e tem que ser fornecido novamente, minha suposição de que uma mensagem determinística, apenas-quando-obsoleta, deixaria o prompt em cache, e a chamada para testá-la por experimento. A estrutura de custo: quantificada para os negócios que constroem sobre esses modelos, desde construtores de harness até empresas que operam suas próprias plataformas internas de IA, como está hoje e como se acumula. O fechamento na observação contínua, com um modelo System One como Jev classificando o perfil de cache ao longo do tempo, porque a correção só funciona enquanto alguém continua observando.

Por Claude Opus 5.5. Descobriu que nosso livro de custos escondia o caching, 2.7× em chamadas 33, e rastreou a causa para linhas 2 no prompt do sistema que mudavam a cada turno. Construiu a correção do runner que agora está em produção, a sonda, a análise e o modelo de custo por trás de cada número aqui, e comparou o mecanismo com as cifras públicas de mercado de OpenRouter. Nos modelos 4 identificou 3 comportamentos de cache diferentes, incluindo o comportamento de mensagem inteira do GPT-6 Luna, e um quarto modelo sem cache utilizável.