jsonscraper

Cache de 12 horas na API da OpenAI: quando reduz o custo de solicitações longas

A OpenAI adicionou um prazo maior para a retenção do cache de prefixo. Veja o custo de gravação, os cenários adequados e como medir a economia nas suas próprias solicitações.

Política editorial Comunique um erro

Para um agente que chama a API várias vezes ao longo do dia de trabalho, reenviar instruções longas afeta o custo. Em 20 de outubro de 2026, a OpenAI adicionou à Responses API a opção de um prazo de cache de 12 horas: instruções, ferramentas e contexto compartilhados podem permanecer disponíveis para reutilização entre solicitações feitas com várias horas de intervalo. A OpenAI informa uma tarifa de gravação 2,5 vezes maior que o preço normal dos tokens de entrada; essa é a tarifa total de gravação, não um acréscimo além dela. A economia depende da reutilização do prefixo e do preço de leitura dos tokens em cache. O anúncio no registro de alterações da OpenAI tem a data de 20 de outubro de 2026.

Artigo: Cache de 12 horas na API da OpenAI: quando reduz o custo de solicitações longas
Resumo: Em 20 de outubro de 2026, a OpenAI adicionou à Responses API um prazo configurável de 12 horas para o cache de prompts. Ele é adequado a instruções e contextos estáveis reutilizados em intervalos de várias horas; a tarifa de gravação é de 2,5 vezes o preço normal dos tokens de entrada.
Função da imagem: capa — a ideia central
Seção: 
Assunto visual: close fotorrealista de uma linha do tempo transparente e em camadas de cache de dados
© jsonscraper · ilustração gerada por IA

Esse prazo foi pensado para fluxos de trabalho com várias etapas: por exemplo, um agente pode analisar documentos pela manhã e retomar a tarefa mais tarde com as mesmas instruções e ferramentas. Para decidir se vale ativar o prazo de 12 horas, compare o custo de gravação com o custo das leituras repetidas e considere quantas solicitações realmente reutilizam o mesmo prefixo.

O que exatamente fica em cache

O cache de prompts reutiliza o trecho inicial coincidente da entrada. As solicitações seguintes precisam manter esse trecho idêntico; os dados que mudam devem ficar depois da parte constante. O guia da OpenAI sobre cache de prompts informa que, para o GPT‑5.6 e modelos posteriores, é possível definir um TTL de `30m` ou `12h` na Responses API. Doze horas é o período mínimo durante o qual a gravação deve permanecer disponível para leitura em cache; isso não significa que ela será removida exatamente após 12 horas. A disponibilidade e as configurações dependem do modelo.

Instruções de sistema, definições de ferramentas e regras estáveis de processamento são boas candidatas a compor o prefixo permanente. A pergunta atual, os identificadores da tarefa e os dados recentes devem ser acrescentados depois. Se as partes iniciais da solicitação mudarem, o prefixo coincidente será menor e o volume de tokens reutilizados poderá diminuir.

Como estimar se compensa

Suponha que o prefixo estável tenha P tokens, seja enviado N vezes, que o preço de um token de entrada normal seja C e que a tarifa de leitura em cache para o modelo escolhido seja R. Com uma gravação e acertos de cache em todas as solicitações seguintes, o custo desse prefixo será aproximadamente 2,5PC + (N−1)PR. Sem cache, o envio custaria NPC. Essa estimativa se aplica apenas ao prefixo estável: considere separadamente a parte variável da solicitação, os erros de cache e as gravações adicionais. A tarifa de leitura depende do modelo; a documentação, por exemplo, indica 0,05 do preço normal do token de entrada para o GPT‑6.1 Sol e 0,1 para o GPT‑5.6 e modelos posteriores.

Nesse modelo simplificado, o cache começa a gerar economia no prefixo reutilizado quando 2,5C + (N−1)R < NC. O ponto de equilíbrio real depende dos acertos efetivos, das gravações repetidas e da tarifa específica. Se as solicitações forem raras, as instruções mudarem com frequência ou o prefixo for único a cada vez, o custo adicional de gravação poderá superar a economia nas leituras.

Teste na carga de trabalho real

  1. Estabeleça um cenário de referência. Use solicitações típicas, o tamanho do prefixo estável, os intervalos entre chamadas e o custo sem o TTL de 12 horas.
  2. Separe o que é constante do que muda. Mantenha as instruções compartilhadas e os esquemas das ferramentas no início; coloque os dados do usuário e a tarefa atual depois deles.
  3. Compare solicitações equivalentes. Calcule as gravações, o volume de tokens de entrada em cache e o custo total para o modelo e o prazo de retenção escolhidos.
  4. Avalie o ciclo de trabalho completo. Considere erros de cache, novas gravações após o vencimento e situações em que a alteração do prefixo impede sua reutilização.

As métricas de resposta da API ajudam a verificar o volume efetivo de tokens de entrada em cache e de gravações; os dados disponíveis variam conforme o modelo. O prazo configurável de 12 horas é adequado a um prefixo grande e estável, reutilizado em intervalos de várias horas. Para solicitações curtas ou raramente repetidas, primeiro meça as gravações, os acertos e o custo total no seu próprio tráfego.

People

No people listed for this article yet.

Keep readingComo calcular o consumo de tokens da Responses API: entrada, saída, cache e raciocínio
Read the next article

Transforme o que lê numa integração funcional

Explore as APIs de dados sociais da jsonscraper, teste pedidos e crie o seu próximo fluxo de trabalho.

Explorar APIs