Prompt caching da OpenAI e do Claude: como funciona, TTL, preço, por que não funciona e como verificar

O prompt caching (cache de prompts) reaproveita o cálculo da parte de uma requisição que é idêntica ao início de uma requisição anterior (o prefixo), para que essa parte da entrada seja processada de forma mais barata e mais rápida. A API da OpenAI e a API do Claude oferecem o recurso, mas como ativá-lo, quanto tempo o cache dura, quanto custa gravar nele e como verificar se está funcionando mudam bastante entre as duas. Se você projetar para ambas com as mesmas suposições, pode acabar com um cache que funciona de um lado enquanto, do outro, você paga a escrita em toda requisição sem nunca obter um acerto.

Este artigo compara o prompt caching da OpenAI e da Anthropic com base no texto original das páginas "Prompt caching", "Prompt cache diagnostics" e "Pricing" da OpenAI e "Prompt caching", "Cache diagnostics", "Pricing" e "Rate limits" da Anthropic. Ele explica como as duas especificações diferem, como obter acertos de cache e como confirmar que você os está obtendo. Todos os números foram conferidos nas páginas originais em 3 de outubro de 2026. Para uma visão geral de como reduzir gastos com API (escolha de modelo, processamento em lote, controle da saída etc.), veja nosso artigo "Como economizar em gastos e tokens de IA".

1. O que é prompt caching: reaproveitar um prefixo idêntico

Toda vez que um modelo de linguagem lê a entrada, ele calcula valores intermediários para cada token (os tensores KV, de chave e valor). O prompt caching guarda esses valores do início do prompt até certo ponto e pula o cálculo quando a próxima requisição começa exatamente com os mesmos tokens. O guia da OpenAI explica que o que fica guardado são os valores KV, não os tokens em si.

O ponto central é que só pode ser reaproveitada a parte que coincide desde o início. Nas duas requisições abaixo, apenas as instruções e os documentos podem ser reaproveitados.

Requisição 1: [Instruções 5,000 tokens][Documentos 20,000 tokens][Pergunta A]
Requisição 2: [Instruções 5,000 tokens][Documentos 20,000 tokens][Pergunta B]
              └─────────────── idêntico até aqui ───────────────┘└ diferente ┘
→ Os 25,000 tokens de instruções + documentos podem ser reaproveitados

Requisição 3: [Data de hoje][Instruções 5,000 tokens][Documentos 20,000 tokens][Pergunta C]
              └─ diferente ┘
→ Mesmo que o resto coincida, nenhum token pode ser reaproveitado

A documentação das duas empresas afirma que o cache não altera o conteúdo da saída. Ele não guarda uma resposta anterior para repeti-la; só pula o trabalho de ler a entrada. Por isso continua útil em chats em que cada pergunta é diferente ou em agentes que leem documentos diferentes a cada vez, desde que haja um prefixo em comum (instruções, definições de ferramentas, histórico da conversa).

2. Prompt caching da OpenAI e da Anthropic, lado a lado

Em 22 de setembro de 2026, a OpenAI anunciou melhorias de cache para o GPT-6, e o mecanismo mudou para o GPT-5.6 e os modelos posteriores (retenção de 30 minutos, pontos de corte explícitos, escrita de cache paga, entre outros). A coluna da OpenAI na tabela abaixo descreve o GPT-5.6 e posteriores. As diferenças do GPT-5.5 e anteriores vêm depois da tabela.

Fontes: OpenAI "Prompt caching", "Prompt cache diagnostics"; Anthropic "Prompt caching", "Cache diagnostics", "Rate limits" (consultadas em 3 de outubro de 2026)

O GPT-5.5 e os modelos anteriores têm só cache implícito, com pontos de corte colocados automaticamente em intervalos fixos, e sem cobrança extra pela escrita no cache. A retenção é definida com prompt_cache_retention: segundo o guia, in_memory dura "cerca de 5 a 10 minutos de inatividade, até 1 hora", e 24h dura "normalmente cerca de 30 minutos, até 24 horas". Ao migrar para o GPT-5.6 ou posterior, troque essa configuração por prompt_cache_options.ttl.

Os preços por token de cada modelo estão no nosso comparativo "Claude vs ChatGPT: comparativo de preços". Para os modelos GPT-6 (Astra, Sol, Luna), veja "nosso artigo sobre o GPT-6 Sol e o Luna" e, para os modelos atuais de todas as empresas, "Datas de corte de conhecimento das IAs".

3. Quando o cache acerta: prefixo, tamanho mínimo, TTL e escopo

O prefixo em comum e a ordem da requisição

Nas duas plataformas, o cache acerta só quando o prefixo até o ponto de corte coincide exatamente. O Claude lê a requisição desde o início na ordem tools → system → messages, então mudar uma única definição de ferramenta invalida o cache do prompt de sistema e do histórico da conversa que vêm depois. A OpenAI também explica que as definições de ferramentas, o formato de saída (text.format), o esforço de raciocínio (reasoning.effort) e configurações parecidas fazem parte do prefixo.

Na prática, a organização é a mesma nas duas: primeiro o que não muda (definições de ferramentas, instruções, documentos) e por último o que muda a cada requisição (datas, dados de cada usuário, a pergunta). Acrescente à conversa adicionando ao final, sem reescrever o histórico.

Posicionar os pontos de corte: automático ou manual

O modo implícito da OpenAI (GPT-5.6 e posteriores) coloca um ponto de corte no fim da mensagem elegível mais recente (uma mensagem do usuário, o último de uma sequência de resultados de ferramentas etc.). No modo somente explícito, só as posições em que você adiciona prompt_cache_breakpoint viram pontos de corte, e se você não adicionar nenhum, o cache não é usado e você também não paga escrita.

O cache automático do Claude, ativado com um único "cache_control": {"type": "ephemeral"} no nível superior, coloca um ponto de corte no último bloco que pode ir para o cache e o move para frente conforme a conversa cresce. Adicionar cache_control a blocos específicos permite que você mesmo escolha os pontos de corte.

// Claude: ponto de corte no fim do prompt de sistema fixo (ponto de corte explícito)
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Instruções e documentos longos...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "A pergunta de hoje..." }]
}

// OpenAI (Responses API): ponto de corte após as instruções fixas, modo somente explícito
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Instruções e documentos longos...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "A pergunta de hoje..." }
  ]
}

Tamanho mínimo: prefixos curtos não vão para o cache

Para o GPT-5.6 e posteriores, o mínimo da OpenAI é 1,024 tokens de entrada visível (instruções ocultas que a OpenAI adiciona internamente não contam). No Claude, depende do modelo.

Fonte: Anthropic "Prompt caching", Cache limitations (consultada em 3 de outubro de 2026). No Bedrock, valem os valores da documentação da AWS.

Se um prompt do Claude ficar abaixo do mínimo, adicionar cache_control não gera erro: o prompt simplesmente não vai para o cache, sem aviso. Nesse caso, cache_creation_input_tokens e cache_read_input_tokens em usage ficam ambos em 0. O mínimo muda quando você troca de modelo, então um prefixo que ia para o cache no modelo anterior pode deixar de ir (o guia da OpenAI faz o mesmo alerta).

TTL: atenção a quando a contagem começa

Na OpenAI (GPT-5.6 e posteriores), o cache dura "pelo menos 30 minutos após a última escrita ou reutilização, e pode persistir por mais tempo". O Claude usa 5 minutos por padrão, e escolher 1 hora faz a escrita custar 2x o preço de entrada. Nas duas plataformas, o TTL é renovado sem custo extra a cada uso do cache.

O Claude tem uma armadilha: o TTL é contado a partir do início da requisição, não do fim da resposta. No exemplo da documentação, se uma resposta leva 4 minutos para ser gerada, a próxima requisição precisa começar cerca de 1 minuto depois do fim dessa resposta para acertar o cache de 5 minutos. Em agentes que geram saídas longas, 5 minutos é menos do que parece.

Escopo do cache e onde ele fica

O cache da OpenAI é por organização e não é compartilhado entre regiões de processamento (configurações de residência de dados). O guia também diz que o cache fica em máquinas individuais e que, acima de cerca de 15 requisições por minuto, as requisições podem ser roteadas para outra máquina. A partir do GPT-5.6, a OpenAI cuida do roteamento automaticamente, e prompt_cache_key virou uma configuração opcional para separar os relatórios de cache por cliente, e não uma forma de aumentar a taxa de acerto (no GPT-5.5 e anteriores, usar a mesma chave para direcionar as requisições à mesma máquina fazia diferença).

A API do Claude delimita o cache por workspace. Dentro da mesma organização, workspaces diferentes não compartilham cache, mesmo com prompts idênticos. No Bedrock e no Google Cloud, é por organização. Além disso, o cache só fica disponível quando a primeira resposta começa, então, se você enviar de uma vez muitas requisições em paralelo com o mesmo prefixo, as outras também viram escritas antes que a primeira tenha gravado o cache.

4. Preço e ponto de equilíbrio: quantas leituras até o cache compensar

Como gravar no cache custa mais do que a entrada normal, uma entrada de cache gravada e nunca lida sai mais cara do que não usar cache. Seja w o multiplicador de escrita, r o de leitura e n o número de leituras após a escrita. O número de leituras necessário para compensar sai destas fórmulas.

Com cache      = w + n × r
Sem cache      = 1 + n          (enviar o mesmo prefixo n + 1 vezes como está)
Compensa se    : n > (w − 1) ÷ (1 − r)

Multiplicadores em relação a um preço de entrada igual a 1. Calculado a partir de OpenAI "Prompt caching" e "Pricing" e Anthropic "Pricing" (consultadas em 3 de outubro de 2026). Compara só o prefixo; a saída e a pergunta de cada requisição ficam de fora.

O guia da OpenAI traz o mesmo cálculo para um modelo de 0.1x: gravar uma vez e ler uma vez custa 1.35x, contra 2x para processar duas vezes sem cache. A página de preços da Anthropic também diz que o cache de 5 minutos compensa após uma leitura e o de 1 hora após duas. Por mais barata que seja a leitura, um cache de 1 hora não compensa com uma única leitura, porque a escrita de 2x pesa demais.

Modelos com o mesmo preço de entrada: o intervalo entre requisições inverte o resultado

Pelos preços oficiais de 3 de outubro de 2026, o GPT-6.1 Sol e o Claude Sonnet 5.5 cobram ambos $2 por milhão de tokens de entrada, e o preço de escrita de 5 minutos é o mesmo, $2.50. O que muda é o preço de leitura (Sol $0.10, Sonnet 5.5 $0.20) e o TTL. Calculamos o custo do prefixo para enviar um prefixo de 100,000 tokens 10 vezes em intervalos diferentes.

Preços de OpenAI "Pricing" (Standard, até 272K) e Anthropic "Pricing" (ambas consultadas em 3 de outubro de 2026). 100,000 tokens = 0.1 (em unidades de 1 milhão de tokens). Com acertos, a primeira requisição é uma escrita e as outras 9 são leituras; com falhas, as 10 são escritas. A OpenAI também pode falhar por causa do roteamento entre máquinas e fatores parecidos, então as linhas com acerto são valores em condições favoráveis.

Por exemplo, o GPT-6.1 Sol a cada 3 minutos fica em "0.1 × $2.50 (uma escrita) + 0.1 × $0.10 × 9 leituras = $0.25 + $0.09 = $0.34". A tabela mostra três coisas.

• Com intervalos de até 5 minutos, a diferença entre os dois é pequena ($0.34 vs. $0.43). Tudo se resume ao preço de leitura.
• Com intervalos de 5 a 30 minutos, o TTL de 30 minutos da OpenAI vence. Com o TTL de 5 minutos do Claude, toda requisição vira escrita e custa $2.50, mais do que não usar cache. Mudar para 1 hora baixa para $0.58.
• Quando o intervalo passa do TTL, o cache dá prejuízo. A cada 2 horas, o mais barato é não usar cache, a $2.00. No Claude, não coloque cache_control; na OpenAI GPT-5.6 e posteriores, use o modo somente explícito sem pontos de corte e você evita a cobrança de escrita.

Em especial, como o cache vem ativado por padrão na OpenAI GPT-5.6 e posteriores, ficar no modo implícito pode significar pagar escrita até por entradas que você nunca vai reenviar. Se a sua carga envia muitas entradas longas e únicas, confira cache_write_tokens em usage e decida se vale mudar para o modo somente explícito.

Como o cache se combina com outros preços

• Batch: a tabela de preços da OpenAI também tem preços de entrada em cache e de escrita em cache para Batch e Flex (GPT-6.1 Sol no Batch: $1 de entrada, $0.05 por leitura de cache, $1.25 por escrita de cache). A Anthropic diz que os multiplicadores de cache se somam ao desconto de 50% do batch, mas, como as requisições em lote são processadas em paralelo e sem ordem definida, descreve os acertos de cache como "best effort" (sem garantia).
• Entradas longas: na OpenAI, quando a entrada passa de 272K tokens, os preços de entrada, de leitura e de escrita de cache dobram (os multiplicadores continuam iguais). Na Anthropic, o Claude 4.6 e os modelos posteriores cobram o mesmo preço até 1 milhão de tokens.
• Pré-aquecimento: nos dois, a escrita de pré-aquecimento é cobrada pelo preço normal de escrita. O max_tokens: 0 do Claude não gera cobrança de saída.

5. Por que o prompt caching não funciona: causas comuns

Juntando as observações das duas empresas sobre armadilhas comuns com as listas de motivos que os diagnósticos retornam, as causas de falhas de cache se dividem em três grupos.

Problemas comuns na OpenAI

• Nenhum ponto de corte logo após o prefixo em comum: o modo implícito coloca o ponto de corte no fim da última mensagem, então com "instruções fixas + uma mensagem de usuário diferente a cada vez" a parte variável também é gravada e a próxima requisição falha. Coloque um ponto de corte explícito logo após a parte fixa.
• Mudar para o modo somente explícito no meio do caminho: o modo somente explícito procura apenas os pontos de corte que você colocou, então não acerta entradas de cache gravadas no modo implícito.
• Acrescentar conteúdo à mesma mensagem: se uma mensagem que terminava em "conteúdo A" passa a ser "conteúdo A + conteúdo B", o ponto de corte anterior cai no meio de uma mensagem e falha. Adicione o conteúdo novo como uma nova mensagem.
• Mudar o esforço de raciocínio no meio do caminho: nos modelos GPT-6, dá para mudar o esforço sem quebrar o cache deixando o reasoning.effort da requisição como está e acrescentando um configuration_update depois da entrada.
• Executar a compactação (compressão do contexto): o prefixo muda, então a taxa de acerto cai. O guia observa, porém, que o custo total ainda pode cair porque a entrada encolhe, e recomenda comparar o custo total.

Problemas comuns no Claude

• Um ponto de corte em um bloco que muda toda vez: as escritas só acontecem nas posições dos pontos de corte, e as leituras só procuram para trás posições de escrita anteriores. Se um ponto de corte está em um bloco que muda toda vez, você paga a escrita toda vez e nunca acerta. O cache automático também coloca seu ponto de corte no último bloco, então cai na mesma armadilha. Coloque um ponto de corte explícito no último bloco que não muda.
• 20 blocos ou mais adicionados em um turno: a busca por escritas anteriores cobre até 20 posições para trás a partir de um ponto de corte. Se a conversa cresce muito de uma vez, a escrita anterior fica fora dessa janela. Mantenha um ponto de corte extra mais cedo no prompt.
• Reescrever o prompt de sistema no meio do caminho: nos modelos compatíveis, dá para acrescentar instruções sem quebrar o cache deixando o system do nível superior inalterado e adicionando uma mensagem com "role": "system" dentro de messages.
• Alternar entre o modo rápido (speed: "fast") e o padrão: isso invalida os caches do sistema e da conversa.

6. Como verificar acertos de cache: usage e diagnóstico

Comece pelo usage: input_tokens significa coisas diferentes

Nas duas plataformas, o usage da resposta informa quanto foi lido do cache e quanto foi gravado nele. O ponto de atenção é que input_tokens significa coisas opostas nas duas plataformas.

Fontes: OpenAI "Prompt caching", Monitor cache performance; Anthropic "Prompt caching", Tracking cache performance (consultadas em 3 de outubro de 2026)

Se você dividir pelo input_tokens do Claude como se fosse a entrada total, tanto a taxa de acerto quanto o custo vão sair muito errados. Ao colocar os números das duas empresas no mesmo painel, normalize os totais com as fórmulas acima antes de comparar. O guia da OpenAI recomenda calcular a "taxa de acerto de tokens" como o total de tokens lidos do cache dividido pelo total de tokens de entrada, agregado por usuário, por dia etc.

Para o custo, na OpenAI é "(entrada − leituras − escritas) × preço + leituras × preço × 0.1 + escritas × preço × 1.25", e no Claude "input_tokens × preço + leituras × preço × 0.1 + escritas × preço × 1.25 (2 na parte de 1 hora)" (troque o multiplicador de leitura por 0.05 ou outro valor conforme o modelo). A OpenAI tem um "Prompt Caching Dashboard" na página de uso, e a documentação de Rate limits da Anthropic indica a página Usage para ver a taxa de acerto do cache.

O que verificar, em ordem, quando as leituras são 0

1. As escritas também são 0? No Claude, se ambas são 0, o prompt está abaixo do tamanho mínimo ou falta cache_control. Na OpenAI em modo somente explícito, também não há escrita se você não colocou nenhum ponto de corte.
2. Aparecem escritas em toda requisição? O ponto de corte está em uma posição que muda toda vez, ou algo no prefixo muda toda vez. Use o diagnóstico descrito a seguir para descobrir o que mudou.
3. Quanto tempo passou desde a requisição anterior? Verifique se passou dos 5 minutos do Claude (incluindo o tempo de geração da resposta) ou dos 30 minutos da OpenAI.

Diagnóstico da OpenAI: prompt_cache_diagnostics

Na Responses API da OpenAI, nos modelos compatíveis do GPT-5.6 em diante, passar o ID de uma resposta anterior em prompt_cache_options.comparison_response_id faz o resultado da comparação entre aquela requisição e a atual aparecer em prompt_cache_diagnostics. A documentação diz que isso não tem custo extra e não conta separadamente nos limites de taxa.

// Adicionar um alvo de comparação à segunda requisição
{
  "model": "gpt-6.1-sol",
  "input": [ ...mesmo prefixo da primeira requisição..., { "role": "user", "content": "Próxima pergunta" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_(ID da primeira resposta)" }
}

// Exemplo retornado em uma falha (o exemplo da documentação: uma ferramenta foi renomeada)
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

Há quatro valores de type: cache_hit, cache_miss, comparison_response_not_found (sem registro para comparar, ou expirado) e unavailable (sem conclusão). Em uma falha, reason é um destes nove.

Fonte: OpenAI "Prompt cache diagnostics", Fix a cache miss (consultada em 3 de outubro de 2026)

Diagnóstico do Claude: diagnostics

Na API do Claude, é preciso incluir um campo diagnostics em todas as requisições, porque a API só guarda uma impressão digital para comparação (hashes e contagens estimadas de tokens) das requisições que o incluem. No primeiro turno, passe "previous_message_id": null; a partir daí, passe o id da resposta anterior.

// Do segundo turno em diante
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_(id da resposta anterior)" },
  "system": "...",
  "messages": [ ... ]
}

Se o diagnostics da resposta for null, nenhuma diferença foi encontrada (ou não houve comparação); {"cache_miss_reason": null} significa que a comparação ainda não terminou; e, se houver um motivo, ele marca o primeiro ponto em que as requisições divergiram. Há seis motivos: model_changed, system_changed, tools_changed, messages_changed, previous_message_not_found e unavailable. Os motivos *_changed vêm com cache_missed_input_tokens, uma estimativa de quanto se perdeu.

A documentação do Claude orienta a ler o diagnóstico junto com cache_read_input_tokens.

Fonte: Anthropic "Cache diagnostics", Reading diagnostics alongside usage (consultada em 3 de outubro de 2026)

Os dois recursos de diagnóstico têm muito em comum: ambos retornam só a primeira diferença encontrada, então, depois de corrigi-la, compare de novo. As diferenças são que o diagnóstico do Claude funciona só na API do Claude (não no Amazon Bedrock, no Google Cloud, no Claude Platform on AWS nem no Microsoft Foundry) e só compara com requisições do mesmo workspace. A documentação da OpenAI não descreve nenhuma etapa para marcar a requisição anterior que servirá de comparação. No Claude, se a requisição anterior também não incluía diagnostics, você recebe previous_message_not_found.

7. Números de taxa de acerto: exemplos dos fornecedores e dados de terceiros

Os números de taxa de acerto de cache que circulam por aí significam coisas muito diferentes dependendo de quem os publicou e em que condições. Aqui eles aparecem separados.

Números dos fornecedores

• Exemplos no guia da OpenAI: uma carga de avaliação pontual (usando um LLM como avaliador) com um ponto de corte explícito após uma rubrica fixa chegou a uma "taxa de acerto de tokens de cerca de 70%", e um agente que chama ferramentas repetidamente chegou a "mais de 90%". O guia alerta que são exemplos de resultados possíveis e que o teto depende da carga de trabalho.
• Comentários de clientes no anúncio da OpenAI (22 de setembro de 2026): a equipe do Manus diz que, depois de repensar onde colocar os pontos de corte, sua taxa de acerto nos modelos da OpenAI foi de "cerca de 85% para consistentemente acima de 90%" em menos de uma semana. Um comentário sobre o GitHub Copilot diz que, nos últimos meses, ele reduziu em mais de 50% a parcela da entrada que precisa ser reprocessada em relação à referência anterior. Ambos são citações de clientes que a OpenAI publicou na própria página, não medições independentes.
• Anthropic: a documentação não traz números reais de taxa de acerto. A página de Rate limits tem um exemplo, "com uma taxa de acerto de 80%, um limite de entrada de 2 milhões de tokens por minuto processa na prática 10 milhões de tokens por minuto", mas isso é conta sobre uma premissa, não uma medição.

Dados de terceiros: não servem como veredito direto sobre qual é melhor

A Requesty, um serviço que roteia requisições para várias APIs de IA, agregou as requisições que passaram pelo próprio gateway e publicou taxas de acerto de abril de 2026 de 77% para a Anthropic direta (77.50% na tabela) e 36% para a OpenAI (36.40%) ("Prompt-cache hit rate per provider, April 2026", atualizado em 9 de maio). À primeira vista, o Claude parece acertar mais que o dobro, mas há quatro motivos pelos quais esses números não servem para a comparação deste artigo.

1. Os dados são anteriores à mudança da OpenAI: a OpenAI introduziu a retenção de 30 minutos e os pontos de corte explícitos em 22 de setembro, e os dados de abril são de antes disso.
2. As cargas de trabalho são diferentes: são resultados de apps de usuários diferentes enviando prompts diferentes em intervalos diferentes pelo gateway, não o mesmo prompt enviado às duas empresas. No Claude, só contam as requisições em que os próprios usuários adicionaram cache_control.
3. O denominador: a página diz "cached_tokens ÷ input_tokens", mas, como explicado na seção 6, o input_tokens do Claude exclui os tokens em cache. A página não diz como fez a conversão.
4. A página se contradiz: em um trecho, coloca o Claude via Google Cloud (Vertex) em 24% e, em outro, em 14%.

Na nossa busca de 3 de outubro de 2026, não encontramos nenhuma medição de terceiros que comparasse os dois caches nas mesmas condições. No fim, a única forma de saber se o cache funciona no seu app é medir com os seus próprios dados de uso. Calcule a taxa de acerto e o custo com as fórmulas da seção 6 e, se houver falhas, use o diagnóstico para descobrir o motivo.

Resumo

O prompt caching da OpenAI e o do Claude partem da mesma ideia básica: reaproveitar o prefixo idêntico e cobrar as leituras por cerca de 0.1x o preço de entrada. A diferença é que a OpenAI (GPT-5.6 e posteriores) vem ativada por padrão, mantém o cache por pelo menos 30 minutos e cobra 1.25x pela escrita, enquanto o Claude só usa o cache se você adicionar cache_control, mantém o cache por 5 minutos (com opção de 1 hora) e cobra 1.25x pela escrita (2x para 1 hora).

No preço, como a escrita custa mais, um cache que nunca é lido dá prejuízo. Os caches de 5 e 30 minutos compensam após uma leitura, e o cache de 1 hora do Claude após duas. Com intervalos de 5 a 30 minutos entre requisições, o TTL de 30 minutos da OpenAI leva vantagem, e no Claude escolher 1 hora evita a inversão. Se as suas requisições ficam mais espaçadas que o TTL, não usar cache sai mais barato.

Verifique se o cache funciona olhando as quantidades de leitura e escrita em usage. O input_tokens do Claude cobre só o que vem depois do ponto de corte, então calcule primeiro o total e depois a taxa de acerto. Quando houver falha, o prompt_cache_diagnostics da OpenAI e o diagnostics do Claude mostram em que a requisição difere da anterior. Para outras formas de cortar custos, veja "Como economizar em gastos e tokens de IA".

FAQ

P. Qual é o TTL do prompt caching da OpenAI?

R. No GPT-5.6 e posteriores, pelo menos 30 minutos após a última escrita ou reutilização. A configuração prompt_cache_options.ttl aceita só "30m", e o guia diz que o cache pode durar mais. No GPT-5.5 e anteriores, a escolha é feita com prompt_cache_retention: in_memory dura cerca de 5 a 10 minutos de inatividade (até 1 hora) e 24h dura até 24 horas.

P. Dá para aumentar o TTL do prompt caching do Claude?

R. Sim, "cache_control": {"type": "ephemeral", "ttl": "1h"} dá 1 hora. A escrita custa 2x o preço de entrada, então não compensa a menos que o cache seja lido pelo menos duas vezes. Se você continuar usando em intervalos de menos de 5 minutos, o cache de 5 minutos é renovado de graça a cada leitura. Os dois são contados a partir do início da requisição, então o tempo para gerar uma resposta longa entra no TTL.

P. O cache muda as respostas?

R. Não. A documentação das duas empresas diz que o cache não afeta a geração da saída. O que fica guardado é o cálculo intermediário da leitura da entrada, não a resposta em si. Assim como sem cache, a mesma entrada nem sempre produz a mesma resposta.

P. Posso limpar o cache manualmente?

R. Nenhuma das duas plataformas permite. A OpenAI diz que as entradas expiram conforme o TTL e as configurações, e a Anthropic diz que elas são removidas automaticamente após pelo menos 5 minutos sem uso (1 hora, se você escolheu 1 hora). Se quiser substituir o conteúdo do prompt, mude o prefixo e a próxima requisição vai gravar uma entrada nova.

Fontes

• Documentação da API da OpenAI: Prompt caching
• Documentação da API da OpenAI: Prompt cache diagnostics
• Documentação da API da OpenAI: Pricing
• OpenAI: Better prompt caching for GPT-6 (22 de setembro de 2026)
• Documentação do Claude Platform: Prompt caching
• Documentação do Claude Platform: Cache diagnostics
• Documentação do Claude Platform: Pricing
• Documentação do Claude Platform: Rate limits
• Requesty: Prompt-cache hit rate per provider, April 2026

Todas as fontes foram conferidas no original em 3 de outubro de 2026. Preços, TTLs e tamanhos mínimos podem mudar à medida que novos modelos são lançados, então confirme na página de preços de cada empresa antes de se basear neles. Os cálculos de custo deste artigo são aritmética a partir dos preços oficiais, não medições feitas chamando as APIs nós mesmos.