Prompt caching: quando reduz (e quando não reduz) sua conta

Por LW Forge — mantenedora do LLM Scout · Atualizado em 27 de julho de 2026

Prompt caching é um desconto raro por ser quase invisível a menos que você desenhe o prompt de propósito para aproveitá-lo: dois produtos com a mesma contagem de tokens podem ter faturas 5-10× diferentes, dependendo só de a estrutura do prompt permitir que o provedor reconheça um prefixo repetido. Este texto explica como OpenAI e Anthropic cobram o cache na prática, mostra uma conta aberta com números reais e lista as três situações em que o cache silenciosamente não economiza nada.

Como cada provedor cobra isso na prática

O cache da OpenAI é automático e não exige nada para ativar: qualquer prompt com 1.024 tokens ou mais é checado contra o prefixo de uma requisição recente, e os tokens que baterem são cobrados a cerca de um décimo da tarifa normal de entrada — sem mudança de código, sem marcador explícito. As entradas do cache vivem pela duração de uma pausa para café, algo em torno de 30 minutos de inatividade antes de expirar, mais tempo sob tráfego constante.

A versão da Anthropic é explícita: você marca os breakpoints de cache no seu prompt, escolhendo exatamente onde termina o prefixo reaproveitável. Escrever um prompt no cache custa um adicional sobre a tarifa normal de entrada (cerca de 1,25×); ler de volta numa requisição posterior custa por volta de um décimo da tarifa de entrada — a mesma ordem de grandeza do desconto da OpenAI. A duração é uma escolha: uma janela padrão de 5 minutos, ou uma opção mais longa de 1 hora com um adicional de escrita maior, para você casar o cache com o quão intermitente é o seu tráfego real.

Os dois desenhos convergem para uma economia parecida — escreve uma vez, lê muitas vezes, por cerca de 10% do preço de entrada nas leituras repetidas — mas o esforço de engenharia é diferente. O desconto da OpenAI é fácil de capturar sem querer; o da Anthropic exige que você decida, explicitamente, o que é estável o suficiente para virar cache.

Uma conta aberta

Pegue um assistente com um prompt de sistema de 8.000 tokens (instruções, esquemas de ferramentas, alguns exemplos) atendendo 500 requisições por dia, com tráfego denso o bastante para cair dentro da janela do cache.

Sem cache, na tarifa de entrada de tabela do GPT-5.6 Terra, repetir esse prompt de sistema em toda chamada soma cerca de 8.000 × 500 × 30 tokens por mês — algumas centenas de dólares mensais, só por texto que nunca muda. Confira a tarifa por token atual na calculadora de custos OpenAI para ver a versão de hoje desse número.

Com o cache ativo, só a primeira requisição de cada janela paga o custo de escrita (irrisório nesse tamanho); o resto lê o prefixo a cerca de um décimo da tarifa de entrada — cortando essa fatia da fatura em torno de 90%, sem nenhuma mudança na qualidade da resposta, porque nada na resposta do modelo mudou. Só a forma como a entrada foi precificada.

Rode a calculadora de custos Claude com seus próprios números de tokens para ver a base a preço cheio, e aplique esse desconto na mão para estimar a versão com cache.

A regra de bolso que se sustenta

Se seu prompt tem um prefixo estável com mais de uns 2.000 tokens e seu tráfego chega mais rápido do que o cache expira, o cache é quase uma vitória de graça — implemente e siga em frente. Abaixo desse tamanho, o adicional de escrita (na Anthropic) ou a economia simplesmente pequena (nos dois provedores) geralmente não compensa a complexidade extra de gerenciar breakpoints.

Quando o cache silenciosamente não faz nada

Três situações neutralizam o desconto:

1. Tráfego esparso. Uma requisição a cada dez ou quinze minutos na OpenAI, ou além do TTL na Anthropic, significa que toda requisição é uma escrita fria. Você paga o adicional de escrita (ou preço cheio) em praticamente toda chamada e nunca coleta o desconto de leitura.
2. Um prefixo que não é de fato estável. Qualquer mudança na parte cacheada — um carimbo de data diferente, uma saudação personalizada, um documento recuperado que varia — invalida a correspondência. O ajuste é de ordem: coloque instruções e exemplos estáticos primeiro, e empurre as variáveis por requisição (mensagem do usuário, contexto recuperado, hora atual) para o final do prompt, depois do breakpoint de cache.
3. Prefixos curtos. Um prompt de sistema de 300 tokens vira cache sem problema, mas economiza centavos; o ganho escala com o comprimento do prefixo, e um prefixo curto não justifica a atenção de engenharia.

O que o cache não alcança

O cache só desconta tokens de entrada que batem no cache — não faz nada pela saída, cobrada a preço cheio de qualquer jeito, e não faz nada pelas partes da sua entrada que mudam a cada requisição. Num chatbot, isso significa que o ganho vale para o prompt de sistema e, se você cachear deliberadamente, para o contexto recuperado — mas não para a mensagem do usuário nem para a resposta do modelo. Veja quanto custa a API do ChatGPT para a conta completa em que esse desconto se encaixa, e Claude Sonnet 5 vs GPT-5.6 para comparar frente a frente a mecânica de cache dos dois provedores.

Confira seus próprios números

A conta acima é um modelo, não uma resposta universal — sua economia real depende do tamanho do seu prefixo, das suas requisições por minuto e de qual duração de cache combina com o seu padrão de tráfego. Meça o tamanho real do seu prompt de sistema na calculadora de tokens, depois compare as estimativas a preço cheio e com cache lado a lado na comparação GPT vs Claude.