Custo de gravação do prompt cache: quando 1.25x compensa?

Uma gravação no prompt cache se paga após uma única releitura dentro do TTL: a gravação é cobrada a 1.25x a tarifa de input, e a leitura, a 0.1x. Assim, um único hit já transforma o adicional de 25% no total de duas chamadas em uma economia de 32.5%. Mesmo assim, em um dos cinco cenários da nossa suíte de agentes, esse adicional gerou uma perda medida de 6%. A diferença está em um único número: a proporção entre leituras e gravações do seu tráfego. Este post mostra como medi-la antes que ela apareça na fatura. Todas as medições abaixo foram feitas pelo gateway da Synthorai, usando medidores de cobrança em produção. Os números dos agentes vêm de uma suíte com 150 episódios; os resultados de TTL e agrupamento vêm de probes dedicados com salt.

TL;DR

• Gravações explícitas no cache são cobradas a 1.25x (TTL de 5 minutos) ou 2x (1 hora); os breakpoints do GPT-5.6 convergiram para a mesma estrutura de 1.25x/0.1x; uma releitura já atinge o break-even.
• Na nossa suíte de agentes, o efeito líquido do adicional variou de +6% (RAG, proporção leitura:gravação de 0.2) a -83% (batch, 15.7).
• Hits no cache renovam gratuitamente o TTL do Claude: com tráfego contínuo, a gravação é paga uma vez por intervalo de inatividade, não uma vez por janela.
• O caching implícito varia bastante: o GPT-5.5 manteve 7/8 hits após uma chamada de aquecimento; o Gemini teve de 1 a 3 hits a cada 12 chamadas, mesmo agrupadas. Nenhum deles cobra adicional.

Quanto custa de fato uma gravação no cache?

Há três modelos de preço entre os providers que comparamos, e dois cobram pela gravação. No caching explícito do Claude, a criação do cache custa 1.25x a tarifa de input com o TTL padrão de 5 minutos e 2x na opção de 1 hora; as leituras custam 0.1x. O GPT-5.6 adotou breakpoints explícitos com os mesmos multiplicadores de 1.25x para gravação e 0.1x para leitura. Com isso, as duas maiores implementações explícitas do mercado passaram a ter preços idênticos. O terceiro modelo é o caching implícito, usado por Gemini, Kimi e pelos modelos da OpenAI anteriores ao 5.6: não há adicional de gravação, apenas leituras com desconto quando o provider consegue atender pelo cache.

A conta de break-even para gravações explícitas é simples. Sem cache, um prefixo de P tokens custa P à tarifa normal. Com cache, a primeira chamada custa 1.25P; cada releitura dentro do TTL custa 0.1P em vez de P. Com uma releitura, o total das duas chamadas fica em 1.35P, contra 2P sem cache, uma economia de 32.5%. Cada hit adicional reduz em 90% o custo do prefixo. O adicional não é o risco. O risco está em gravar blocos que nunca serão relidos, e isso depende do formato da carga de trabalho.

Quando o adicional de gravação gera prejuízo?

Quando o prefixo muda mais rápido do que se repete. Medimos a proporção de tokens lidos e gravados em cinco cenários de agentes, usando os mesmos modelos e a mesma estratégia de marcação. Depois, calculamos o efeito líquido do caching com tarifas de 1.25x/0.1x:

O resultado de RAG merece atenção. Os documentos recuperados mudam a cada consulta, então cada chamada regravou um prefixo que a chamada seguinte não podia reutilizar: cinco tokens gravados para cada token relido. Com isso, o adicional de 1.25x se acumulou até gerar prejuízo líquido. Não havia erro de configuração; esse formato de carga simplesmente não consegue amortizar uma gravação. A solução é trabalhar em camadas, não abandonar o cache: marque o system prompt e as definições de tools, que permanecem estáveis entre consultas, e deixe os documentos recuperados sem marcação depois do último breakpoint. A mesma regra vale para qualquer conteúdo volátil, como timestamps, nomes de usuários e contexto específico da requisição, além de configurações que invalidam o prefixo sem aviso. Alterar output_config.effort entre turnos renderiza o prompt novamente e invalida o cache. Por isso, o effort deve permanecer constante dentro de uma sessão com cache. Nosso estudo sobre LangChain encontrou o mesmo problema no framework: builders que tornam tão fácil marcar tudo quanto marcar apenas o que deve ser marcado.

Com que frequência a gravação volta a ser cobrada?

Uma vez por intervalo de inatividade, não uma vez por janela de TTL, porque os hits renovam o relógio gratuitamente. Confirmamos isso com um prefixo de 4,981 tokens e salt no Claude Opus 4.8:

A chamada 4 ocorre bem depois do TTL original de 5 minutos e ainda lê o cache normalmente, porque as chamadas 2 e 3 renovaram a janela sem custo. Somente os 7 minutos sem tráfego forçaram uma nova gravação. Na prática, qualquer rota cujo intervalo entre chegadas permaneça abaixo do TTL paga o adicional de gravação uma única vez, e a opção de 5 minutos se comporta como um cache sem prazo. A opção de 1 hora, com gravação a 2x e cobrança confirmada pelo gateway no bucket específico ephemeral_1h_input_tokens, atende ao outro perfil de tráfego: pagar 2x uma vez em vez de 1.25x repetidamente. Ela compensa assim que evita uma única regravação e, portanto, serve para rotas com períodos de inatividade entre cinco minutos e uma hora. Após uma hora sem tráfego, nenhuma das opções preserva o cache entre execuções. O orçamento de um job agendado deve considerar o que ocorre dentro de uma execução: um cron que faz uma única requisição não ganha nada ao gravar no cache; um cron que dispara várias requisições com o mesmo prefixo é apenas um batch e usa o cache da mesma forma.

Dá para melhorar o caching implícito ajustando o tráfego?

Depende inteiramente do cache implícito de cada provider, porque o comportamento best-effort varia muito. No extremo mais confiável, o caching automático do GPT-5.5 funcionou como um mecanismo previsível: após uma chamada de aquecimento, a entrada já podia ser lida dois segundos depois. O primeiro probe teve hit com os dois salts testados. Em seguida, um burst leu do cache 4,864 tokens de um prompt de 5,170 tokens em sete de oito probes, sem pagar adicional em nenhum deles. É economia sem custo adicional e exige apenas o envio do mesmo prefixo duas vezes. No outro extremo está o Gemini 3.6 Flash: na mesma suíte de agentes em que o caching explícito atendeu 77-78% dos tokens de input do Claude, o cache implícito do Gemini atendeu 4%, mesmo em cargas com prefixos realmente repetidos.

Tentamos melhorar o pior caso ajustando o tráfego: agrupamos chamadas com o mesmo prefixo para manter o cache do provider aquecido. Doze chamadas consecutivas no Gemini 3.6 Flash produziram exatamente um hit, na chamada 10; a chamada 11 voltou a ser miss. Oito chamadas espaçadas em intervalos de 3 minutos não produziram nenhum hit. Para descartar um resultado ocasional, repetimos o teste agrupado por um segundo caminho de requisição independente e no Gemini 3.5 Flash. Os resultados foram, respectivamente, três hits e um hit em doze chamadas, sem sequências longas. O único bloco armazenado voltou com os mesmos 4,073 tokens nos dois caminhos. A mecânica é consistente; a probabilidade, não.

Parte dos misses vem da latência de ingestão, que varia por provider. A entrada do GPT-5.5 podia ser lida dois segundos após o aquecimento, enquanto o Gemini leva dezenas de segundos para criar o cache. Por isso, bursts disparados imediatamente após a primeira chamada chegam antes que o cache esteja pronto; em todos os nossos testes com Gemini, nenhum hit ocorreu antes da quarta chamada. Fazer uma chamada de aquecimento e esperar 45 segundos antes do burst elevou o resultado para 3 hits em 8, o melhor obtido com qualquer ajuste de tráfego. Após 90 segundos, porém, o resultado caiu para zero em 8: quando voltamos, a entrada já havia expirado. Alguns dias antes, uma varredura de aquecimento mais longa no mesmo modelo havia mantido os hits, então a taxa também varia com o tempo e a carga. Entre a demora de criação, a vida curta e essa variação, agrupar chamadas no pior caso ajuda apenas porque três hits ainda são melhores que um. (Uma observação sobre testes: avalie caches implícitos com chamadas espaçadas e um cenário de aquecimento seguido de espera. Meça também a latência de criação com uma sequência de probes após o aquecimento. Probes consecutivos medem sua taxa de requisições, não o cache.)

A regra correta é específica por provider, não por mecanismo: meça se o cache implícito do seu provider se comporta como o do GPT-5.5, que pode ser aquecido e depois tratado como confiável, ou como o do Gemini, em que cada hit deve ser visto como um abatimento ocasional. O Kimi K3 fica entre os dois: sem adicional, com um piso pequeno e 57-62% do input atendido pelo cache sem configuração. Um dado indica qual modelo tende a prevalecer: a OpenAI tinha o melhor cache implícito que medimos e, ainda assim, migrou o GPT-5.6 para breakpoints explícitos, substituindo um desconto sujeito à própria sorte por marcações controladas pelo cliente.

Quais cargas amortizam o adicional?

Baseie a decisão na proporção entre leituras e gravações e no intervalo de inatividade. Ambos podem ser obtidos nos seus próprios registros de uso antes da adoção:

Duas regras finais extraídas dos medidores. Primeiro, avalie o caching comparando cache_read e cache_creation nos detalhes do seu próprio uso, não pela impressão de que os hits são frequentes; o cenário de RAG parecia adequado ao cache, mas mediu 0.2. Segundo, quando a proporção é saudável, o adicional se torna irrelevante: com uma proporção leitura:gravação de 3.5, o resultado geral da suíte, o custo do prefixo cai 64%, incluindo todas as gravações pagas.

FAQ

O prompt caching compensa em RAG?

Não para os documentos recuperados. Na nossa medição, o RAG gravou cinco tokens para cada token relido, transformando o adicional de 1.25x em uma perda líquida de 6%. Armazene em cache as camadas estáveis, como o system prompt e as definições de tools, e mantenha o conteúdo recuperado após o último breakpoint. O guia completo de caching detalha como organizar o prompt em camadas.

Devo usar o TTL de cache de 5 minutos ou o de 1 hora?

Decida pelo intervalo de inatividade, não pela duração da sessão. Os hits renovam gratuitamente o TTL de 5 minutos. Portanto, qualquer rota com intervalo entre chegadas inferior a 5 minutos nunca precisa regravar, e a opção mais barata funciona por tempo indeterminado. Pague a gravação a 2x da opção de 1 hora apenas quando os intervalos ficarem entre cinco minutos e uma hora; ela compensa assim que evita uma regravação a 1.25x. Para intervalos superiores a uma hora, calcule o orçamento como se não houvesse cache.

O caching implícito cobra pela gravação?

Não, e isso não faria sentido estruturalmente: um adicional de gravação só funciona quando o caller opta pelo cache. Por isso, os adicionais existem apenas no modelo explícito, como os multiplicadores de 1.25x/2x da Anthropic, os breakpoints do GPT-5.6 e a cobrança por armazenamento das APIs explícitas de cached content, como a tarifa por token-hora do Gemini. Todas as implementações implícitas que medimos, Gemini, Kimi e OpenAI anterior ao 5.6, e todas as principais tabelas públicas de preços, DeepSeek, Qwen e Grok, cobram o caching implícito apenas como leituras com desconto. O que muda é a confiabilidade: o cache implícito do GPT-5.5 manteve 7 hits em 8 probes após o aquecimento, enquanto o Gemini atendeu 4% do input na nossa suíte de agentes, e o agrupamento quase não alterou o resultado. Um desconto confiável sem adicional supera qualquer alternativa; um desconto aleatório sem adicional vale menos que um pequeno adicional por um cache sob seu controle.

Medido entre 2026-07-25 e 2026-07-29 pelo gateway da Synthorai: proporções leitura:gravação dos cenários obtidas em 150 episódios de agentes com Claude e detalhamento do cache por chamada; percentuais de Gemini e Kimi obtidos em suas próprias execuções da suíte; probes de renovação de TTL e do bucket de 1 hora no claude-opus-4-8, com prefixos de 4,981 e 3,742 tokens e salt; probes de cache implícito no gemini-3.6-flash e gemini-3.5-flash, com prefixos de ~6,800 tokens e cenários agrupados, espaçados e de aquecimento seguido de espera, e no gpt-5.5, com prompt de 5,170 tokens e burst após o aquecimento. Percentuais de efeito líquido calculados a partir das proporções medidas, com multiplicadores de 1.25x para gravação e 0.1x para leitura. As tarifas e o comportamento do cache podem mudar; confirme nos seus próprios registros de uso.

← Voltar ao blog