Cache de prompts da OpenAI por 12 horas: quando 2.5× compensa

Use o cache de prompts da OpenAI por 12 horas para um prefixo estável que seu agente reutiliza após pausas longas; mantenha o conteúdo variável da sessão em 30m ou fora das gravações em cache. Se a alternativa exigir uma nova gravação de 30m a cada requisição, uma única gravação de 12h sai mais barata na terceira requisição total — a segunda reutilização — desde que o prefixo continue idêntico. Se 30m já gera acertos de cache em todas as chamadas, ampliar o tempo de vida acrescenta custo sem baratear a leitura.

Quanto custam 30m e 12h?

A opção 12h prolonga o período em que os tokens podem receber o preço de entrada em cache, cobrando o dobro da gravação padrão. O changelog da API da OpenAI de 20 de outubro de 2026 anunciou a opção para Responses; o guia de cache de prompts documenta as regras abaixo para GPT-5.6 e modelos posteriores, verificadas em 2026-10-24.

Tipo de cobrança de entrada	Multiplicador sobre a entrada comum	GPT-6.1 Sol, USD por 1M tokens
Entrada comum	1×	$2.00
Gravação de `30m`, padrão	1.25×	$2.50
Gravação de `12h`	2.5×	$5.00
Leitura do cache, com qualquer duração	0.1× na maioria dos modelos; 0.05× no GPT-6.1 Sol	$0.10

Esses são os preços totais de gravação. Um token cobrado como gravação de 12h custa 2.5× o preço da entrada comum, e não o preço comum acrescido de outros 2.5×.

A coluna em dólares usa os preços Standard da OpenAI para gpt-6.1-sol, com prompts de até 272K tokens de entrada e sem adicional por processamento regional. A saída custa $10.00 por 1M tokens. Prompts maiores, outros níveis de serviço e processamento regional podem alterar os preços; consulte as condições de preço do modelo aplicáveis antes de usar os cálculos a seguir.

O prefixo reutilizável precisa conter pelo menos 1,024 tokens visíveis de entrada. Uma requisição grande com apenas um pequeno trecho inicial inalterado não torna esse trecho automaticamente elegível para cache.

Quando a gravação mais cara compensa?

Conte quantas gravações o período mais longo permite evitar. Considere B como o custo de entrada comum do prefixo inalterado, n como o número total de requisições, r como o multiplicador de leitura e k como o número de gravações de 30m, incluindo a primeira.

Supondo que cada gravação ou acerto cubra todo o prefixo, com uma gravação de 12h seguida de leituras bem-sucedidas:

12h cost = B × [2.5 + (n - 1) × r]
30m cost = B × [1.25 × k + (n - k) × r]
No-cache cost = B × n

Tanto para r = 0.1 quanto para r = 0.05, o cache de longa duração fica mais barato que a entrada sem cache em n = 3. Na comparação com o cache padrão, ele passa a custar menos quando k >= 3, desde que a política de 12h ainda exija apenas uma gravação. Isso significa evitar duas novas gravações de curta duração após a primeira, e não apenas acumular muitos acertos.

Se as duas políticas gravarem uma vez e acertarem o cache em todas as requisições seguintes, 12h continuará 1.25 × B mais caro. Portanto, conversas interativas frequentes têm pouco motivo para pagar a gravação mais longa, a menos que também sejam retomadas após pausas que provoquem novas gravações.

Uma pausa superior a 30 minutos abre uma possibilidade de economia, mas não prova que o prefixo estará ausente do cache. A OpenAI pode manter entradas além da duração mínima, e uma leitura de 30m renova a cobertura por pelo menos mais 30 minutos. Ao projetar os custos de uma carga de trabalho existente, use a quantidade de gravações observada.

Como estimativa concreta, considere um prefixo de 10,000 tokens no GPT-6.1 Sol com preços Standard: B = $0.02 e r = 0.05. Envie 12 requisições, uma por hora, das horas 0 a 11, mantendo o prefixo inalterado.

Comportamento de cache presumido	Custo de entrada do prefixo nas 12 requisições
Sem cache: 12 entradas pelo preço comum	$0.240
`30m`: todas as 12 requisições exigem gravação	$0.300
`12h`: uma gravação e 11 leituras	$0.061
`30m`: uma gravação e 11 leituras	$0.036

As duas linhas de 30m mostram por que o intervalo entre requisições, sozinho, não determina a economia. A linha com gravação em todas as chamadas representa uma hipótese, não um resultado inevitável para chamadas a cada hora. Essas estimativas excluem sufixos variáveis, tokens de saída e eventuais cobranças de ferramentas; não são valores medidos em faturas.

Por que aplicar 12h à requisição inteira pode custar mais

Definir prompt_cache_options.ttl: "12h" no nível da requisição também afeta o ponto de corte implícito do cache, ou breakpoint. Com o padrão mode: "implicit", novos trechos elegíveis adicionados à conversa podem gerar gravações de 2.5× a cada rodada, mesmo enquanto o prefixo anterior é lido por um preço menor.

Em um agente que acumula resultados de ferramentas e mensagens do usuário, esse sufixo crescente pode consumir toda a economia obtida com o início estável. Uma porcentagem alta de acertos de cache, isoladamente, não mostra se a política reduz custos.

Escolha uma destas configurações:

Material compartilhado estável e contexto de sessão reutilizável: defina 30m como padrão da requisição e aplique uma substituição para 12h no fim do material compartilhado.
Material estável e perguntas usadas uma única vez: use mode: "explicit" e deixe a pergunta variável depois do último ponto de corte explícito.
Conversa cujo contexto mais recente será reutilizado em breve: mantenha mode: "implicit" com o padrão 30m na requisição, junto ao ponto de corte de 12h do prefixo compartilhado.

Um ponto de corte abrange todo o prefixo anterior a ele. Em uma requisição sem cache prévio, com um ponto de corte de 12h em 2,000 tokens e outro de 30m em 5,000, a cobrança atribui 2,000 tokens a gravações longas e 3,000 a gravações curtas. Se o ponto de corte de 12h estiver no limite posterior de 5,000 tokens, todos os 5,000 tokens receberão o preço de gravação mais longa. Cada token é cobrado uma vez, pela maior duração de gravação selecionada que o abrange.

Duas mudanças de duração também merecem atenção. Ampliar uma cobertura ainda válida de 30m para 12h gera uma nova gravação longa, sem crédito pela gravação anterior. Quando uma requisição de 30m lê um prefixo ainda coberto por 12h, esses tokens recebem o preço de leitura, sem reiniciar a contagem de 12 horas nem gerar outra cobrança de gravação. Por essas regras de sobreposição e duração, escolha a política antes de carregar um prefixo grande no cache.

Como combinar 12h e 30m em uma requisição à Responses API

Use 30m como padrão da requisição e pontos de corte explícitos para separar o material de referência compartilhado, o contexto da sessão e a pergunta atual. Este exemplo envia a requisição diretamente à Responses API da OpenAI e exibe tanto o texto gerado quanto os dados de uso necessários para conferir a cobrança.

Você precisa de Bash, curl, jq e uma chave da API da OpenAI com acesso a gpt-6.1-sol. No diretório atual, prepare:

shared-context.md: instruções de engenharia e material de referência úteis que serão reutilizados ao longo do dia, com pelo menos 1,024 tokens visíveis de entrada.
session-context.md: o contexto atual do deploy ou pull request que você pretende reutilizar durante a sessão.

Mantenha os dois arquivos inalterados entre as duas chamadas do exemplo. Quando read aguardar a entrada, cole sua chave de API e pressione Enter; o terminal não a exibirá. A autenticação segue o guia de início rápido da API da OpenAI.

set -o pipefail
read -rs OPENAI_API_KEY && export OPENAI_API_KEY

cache_request() {
  jq -n \
    --rawfile shared ./shared-context.md \
    --rawfile session ./session-context.md \
    --arg question "$1" \
    '{
  model: "gpt-6.1-sol",
  service_tier: "default",
  reasoning: {effort: "low"},
  prompt_cache_options: {mode: "explicit", ttl: "30m"},
  input: [
    {
      role: "developer",
      content: [{
        type: "input_text",
        text: $shared,
        prompt_cache_breakpoint: {mode: "explicit", ttl: "12h"}
      }]
    },
    {
      role: "user",
      content: [
        {
          type: "input_text",
          text: $session,
          prompt_cache_breakpoint: {mode: "explicit"}
        },
        {type: "input_text", text: $question}
      ]
    }
  ]
}' |
  curl --silent --show-error --fail-with-body \
    https://api.openai.com/v1/responses \
    -H "Authorization: Bearer $OPENAI_API_KEY" \
    -H "Content-Type: application/json" \
    --data-binary @- |
  jq '{id, status, service_tier,
  text: ([.output[]? | .content[]? |
    select(.type == "output_text") | .text] | join("\n")),
  usage, error}'
}

cache_request "Which deployment risks need review? Answer briefly." &&
cache_request "Which test should run first? Answer briefly."

O primeiro bloco de conteúdo substitui o padrão da requisição por "ttl": "12h". O bloco da sessão não define um TTL próprio e herda "30m". Como a requisição usa somente pontos de corte explícitos, a pergunta final não gera cobrança de gravação em cache; ela continua gerando custo de entrada comum.

Para um prefixo elegível ainda sem cache, a primeira resposta concluída deve registrar gravações longas em usage.input_tokens_details.cache_write_tokens_details.ttl_12h_tokens. A segunda deve mostrar cached_tokens > 0 e nenhuma nova gravação longa, desde que o prefixo e sua cobertura continuem válidos. O campo text retornado contém a resposta utilizável. Repetir imediatamente a chamada permite verificar a correspondência do prefixo e a contabilização; para avaliar a economia após pausas longas, faça chamadas nos intervalos reais de produção.

Se receber 400 invalid_request_error, confira os valores exatos de TTL, o modelo selecionado e o endpoint de Responses. Se ambas as chamadas retornarem zero tokens em cache, confira primeiro o tamanho do prefixo; depois compare os arquivos, o modelo, as configurações e as posições dos pontos de corte. Mudanças antes do ponto de corte compartilhado — inclusive alterações nas definições de ferramentas quando você as adiciona — podem impedir a reutilização.

Para testar uma referência sem cache, mantenha mode: "explicit" e remova todos os prompt_cache_breakpoint. O esquema oficial da requisição documenta que o modo explícito sem marcadores não usa cache de prompts.

Como calcular a cobrança de entrada a partir de usage

Trate a entrada comum, as leituras do cache e as duas classes de gravação como categorias separadas, sem sobreposição. O total cache_write_tokens já inclui os componentes ttl_30m_tokens e ttl_12h_tokens; cobrar os três separadamente duplicaria o custo das gravações. Os tokens cobrados pela ampliação para 12h entram nas gravações e ficam fora de cached_tokens.

O exemplo de contabilização de uso da OpenAI tem este formato:

{
  "usage": {
    "input_tokens": 12000,
    "input_tokens_details": {
      "cached_tokens": 4000,
      "cache_write_tokens": 7000,
      "cache_write_tokens_details": {
        "ttl_30m_tokens": 3000,
        "ttl_12h_tokens": 4000
      }
    }
  }
}

Considere I como input_tokens, R como cached_tokens e W30 e W12 como as duas contagens de gravação por TTL. Calcule a entrada comum com U = I - R - W30 - W12; neste exemplo, o resultado é 1,000 tokens.

Para o preço de entrada comum P, em USD por 1M tokens, e o multiplicador de leitura do cache r:

Input cost = P × (U + r × R + 1.25 × W30 + 2.5 × W12) / 1,000,000

O exemplo hipotético da documentação, com P = $1 e r = 0.1, resulta em:

(1000 + 4000 × 0.1 + 3000 × 1.25 + 4000 × 2.5) / 1000000 = $0.01515

Para o mesmo uso com os preços Standard do GPT-6.1 Sol, substitua por P = $2 e r = 0.05: a cobrança de entrada será $0.02990. Some a saída e quaisquer outras cobranças aplicáveis separadamente. Esse cálculo isola a cobrança de entrada; ele não estima o custo total de concluir uma tarefa de programação.

Registre o ID da resposta, o horário, o modelo, o service_tier efetivamente usado e essas contagens de tokens. Se um cliente omitir a divisão por TTL, examine o JSON bruto antes de calcular os custos com durações diferentes; a ausência de contadores não comprova que não houve gravações. Some os custos em dólares ao longo de um dia representativo, em vez de escolher a política com base em uma única porcentagem de acertos.

Por fim, 12h define uma duração mínima de elegibilidade para o preço de leitura do cache. Não estabelece uma data-limite para exclusão, não altera a política de retenção máxima de dados nem garante menor latência em todas as requisições.

Como isso se compara a Codex, Work e Anthropic?

Separe a cobrança da API das franquias de uso dos produtos com login. Em sua publicação de 21 de outubro de 2026, Tibo Sottiaux descreveu o cache de usuários autenticados no Codex e no Work como “para sempre” e afirmou que retomar conversas antigas geraria acertos de cache. A declaração se refere às sessões desses produtos; não define um TTL para a API nem torna uma assinatura ilimitada.

A documentação oficial de preços do Codex informa separadamente que a cobrança por créditos do Codex não tem uma tarifa específica de gravação em cache, enquanto o uso com chave de API segue os preços da API. Se você usa o Codex com uma chave de API, planeje os custos pelas regras da API, sem aplicar a promessa feita para sessões autenticadas do produto.

Para o Claude, as opções documentadas em 2026-10-24 são o cache padrão de 5 minutos, com gravações de 1.25×, e o cache opcional de 1 hora, com gravações de 2×. Os descontos de leitura variam por modelo: Claude Opus 5.5 e Sonnet 5.5 usam 0.05×; os demais preços aparecem na tabela de preços da Anthropic. Leituras bem-sucedidas renovam a duração sem um novo adicional de gravação, e requisições com TTLs mistos exigem que os blocos de maior duração venham antes dos de menor duração.

Se seu aplicativo já usa um modelo compatível e faz pausas recorrentes de várias horas, teste primeiro a política de 12h da OpenAI para o prefixo estável. Para uma sessão continuamente ativa, comece pelo cache mais curto. Comparar provedores exige os preços-base reais, o uso de tokens de saída e o comportamento observado do cache; duração e multiplicadores de gravação, sozinhos, não determinam qual opção conclui a tarefa por menos.