Cache de prompts da OpenAI (outubro de 2026): como funciona, preços e ROI
O cache de prompts da OpenAI vem ativado por padrão: quando uma requisição começa com o mesmo prefixo (pelo menos 1.024 tokens no GPT-5.6 e posteriores) de uma requisição recente, a OpenAI reutiliza o cálculo salvo e cobra esses tokens pela tarifa de entrada em cache, cerca de 90–95% mais barata que a entrada normal. No GPT-5.6 e posteriores você também paga uma gravação única em cache: 1,25x a tarifa de entrada para a duração padrão de 30 minutos ou 2,5x para 12 horas, em 25 de outubro de 2026. Se um prefixo for reutilizado ao menos uma vez dentro da validade, o cache já sai mais barato do que enviá-lo duas vezes.
Este guia explica como o cache da OpenAI funciona, quanto custa nos modelos atuais, como controlá-lo com breakpoints e TTLs, como medir a economia e como ele se compara ao cache da Anthropic e do Gemini. Todas as tarifas vêm do guia de cache de prompts da OpenAI e da página de preços da API da OpenAI, verificados em 25 de outubro de 2026.
Preços do cache de prompts da OpenAI
Preços do nível padrão por 1 milhão de tokens:
| Modelo | Entrada | Entrada em cache (leitura) | Gravação 30 min | Gravação 12 h | Saída |
|---|---|---|---|---|---|
| gpt-6-astra | US$ 10,00 | US$ 1,00 | US$ 12,50 | US$ 25,00 | US$ 50,00 |
| gpt-6.1-sol | US$ 2,00 | US$ 0,10 | US$ 2,50 | US$ 5,00 | US$ 10,00 |
| gpt-6-luna | US$ 0,10 | US$ 0,01 | US$ 0,125 | US$ 0,25 | US$ 0,50 |
| gpt-5.6-sol | US$ 4,00 | US$ 0,40 | US$ 5,00 | US$ 10,00 | US$ 20,00 |
Uma leitura em cache custa 0,1x a tarifa de entrada sem cache na maioria dos modelos e 0,05x no GPT-6.1 Sol. O nível Batch reduz pela metade todos os valores desta tabela, e o modo Fast os dobra. Endpoints regionais de residência de dados têm acréscimo de 10% para modelos lançados a partir de 5 de março de 2026.
Um ponto que costuma gerar confusão: o preço de gravação em cache não é uma taxa extra sobre a entrada. Cada token de entrada é cobrado uma única vez, pela tarifa sem cache, de leitura em cache ou de gravação em cache. Uma gravação de 30 minutos custa 25% a mais que a entrada comum para esses tokens, e cada acerto posterior custa 10% (ou 5%) dela.
Como funciona o cache de prompts da OpenAI
Quando um modelo lê o seu prompt, ele calcula estados de chave-valor (KV) para cada token. O cache de prompts salva esses estados para um prefixo reutilizável, isto é, o início do prompt que não muda. Se uma requisição posterior começar exatamente com o mesmo prefixo e encontrar uma entrada de cache correspondente, o modelo pula o recálculo, o que reduz o custo e o tempo até o primeiro token.
O prefixo em cache abrange tudo o que a OpenAI renderiza antes de o seu conteúdo mudar: o conteúdo de sistema oculto, mensagens de developer, definições de ferramentas e histórico da conversa, incluindo texto, imagens, documentos e áudio compatível. A correspondência precisa ser exata. Se algo mudar antes de um breakpoint, como um timestamp no prompt de sistema, uma lista de ferramentas reordenada ou uma imagem diferente, tudo depois dessa mudança é um cache miss.
Regras principais no GPT-5.6 e posteriores:
- Tamanho mínimo: um prefixo precisa ter pelo menos 1.024 tokens para entrar no cache. Os tokens de sistema ocultos da OpenAI não contam.
- Breakpoints: um breakpoint marca o fim de um prefixo que pode ser gravado no cache. No modo implícito (padrão), a OpenAI coloca um no fim da última mensagem elegível. No modo explícito, você escolhe onde ficam com
prompt_cache_breakpoint. - Até quatro gravações por requisição: cada requisição pode criar até quatro gravações em cache, então você pode armazenar camadas que mudam em ritmos diferentes.
- Validade: defina
prompt_cache_options.ttlcomo"30m"(padrão) ou"12h"na Responses API. As leituras custam o mesmo nos dois casos.
Nos modelos anteriores ao GPT-5.6, só existe cache implícito. A retenção é controlada com prompt_cache_retention: in_memory mantém as entradas por cerca de 5–10 minutos de inatividade (até uma hora), e 24h estende isso para até 24 horas. Organizações sem Zero Data Retention usam 24h por padrão; organizações com ZDR usam in_memory. Nesses modelos antigos, um prompt_cache_key estável ajuda a direcionar requisições relacionadas ao mesmo cache. A OpenAI sugere manter cada chave em cerca de 15 requisições por minuto e dividir tráfego maior entre várias chaves.
Quando o cache compensa
O guia da OpenAI traz a conta básica. Com leitura a 0,1x e gravação a 1,25x, gravar um prefixo uma vez e reutilizá-lo uma vez custa 1,35x o preço de entrada normal, contra 2x para enviá-lo duas vezes. Dez requisições com uma gravação e nove leituras custam 2,15x, contra 10x sem cache.
| Requisições que compartilham o prefixo | Sem cache | Cache de 30 minutos | Cache de 12 horas | Economia com cache de 30 minutos |
|---|---|---|---|---|
| 1 | 1,00× | 1,25× | 2,50× | −25% |
| 2 | 2,00× | 1,35× | 2,60× | 33% |
| 10 | 10,00× | 2,15× | 3,40× | 79% |
| 100 | 100,00× | 11,15× | 12,40× | 89% |
A validade de 12 horas só faz sentido quando o intervalo entre requisições passa de 30 minutos, mas o prefixo ainda é reutilizado várias vezes — por exemplo, um manual de produto extenso consultado ao longo do expediente por uma ferramenta interna de baixo tráfego.
A OpenAI também explica quando vale preencher um prefixo curto até o mínimo. Com mínimo de 1.024 tokens, leitura a 0,1x e gravação a 1,25x, preencher sai mais barato quando o prefixo original tem mais de 102,4 + 1.177,6 / N tokens, em que N é o número de requisições. Em 10 requisições, expandir para 1.024 tokens um prefixo de 221 tokens ou mais já compensa.
Um exemplo prático
Suponha que um assistente de suporte com gpt-6.1-sol atenda 50.000 requisições por dia. Cada requisição envia um prefixo estável de 8.000 tokens (instruções, definições de ferramentas e documentos de políticas) e uma mensagem de usuário de 500 tokens, e recebe uma resposta de 400 tokens. O tráfego é constante, então o cache de 30 minutos é regravado cerca de 48 vezes por dia.
| Item de custo diário | Sem cache | Com cache explícito |
|---|---|---|
| Prefixo estável | 400 mi × US$ 2,00 = US$ 800,00 | gravações: 0,38 mi × US$ 2,50 = US$ 0,96; leituras: 399,6 mi × US$ 0,10 = US$ 39,96 |
| Mensagem do usuário | 25 mi × US$ 2,00 = US$ 50,00 | 25 mi × US$ 2,00 = US$ 50,00 |
| Saída | 20 mi × US$ 10,00 = US$ 200,00 | 20 mi × US$ 10,00 = US$ 200,00 |
| Total | US$ 1.050,00 | ≈ US$ 290,92 |
Isso representa uma redução de cerca de 72% na conta diária. A linha de saída é igual nas duas colunas, então, com o cache funcionando, respostas mais curtas são a próxima alavanca.
Por que o modo explícito aqui? No modo implícito, o breakpoint fica no fim da última mensagem, então os 500 tokens variáveis do usuário também seriam gravados no cache a 1,25x toda vez. Neste exemplo, isso soma cerca de US$ 12,50 por dia. O modo explícito permite encerrar a gravação logo depois do prefixo estável, e a mensagem do usuário é cobrada pela tarifa de entrada normal.
Como configurar
Você não precisa de código para aproveitar o cache implícito. Para controlá-lo, use a Responses API. Esta requisição armazena as instruções compartilhadas por 12 horas e o contexto da sessão por 30 minutos, e deixa a pergunta atual fora do cache:
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6.1-sol",
"prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
"input": [
{ "role": "developer", "content": [
{ "type": "input_text", "text": "<shared instructions and policy docs>",
"prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" } } ] },
{ "role": "user", "content": [
{ "type": "input_text", "text": "<session context>",
"prompt_cache_breakpoint": { "mode": "explicit" } },
{ "type": "input_text", "text": "What is the refund window for annual plans?" } ] }
]
}'
Leia os campos de cache de cada resposta e registre-os:
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(model="gpt-6.1-sol", input=[...]) # same input as above
d = resp.usage.input_tokens_details
print("input:", resp.usage.input_tokens)
print("cache reads:", d.cached_tokens)
print("cache writes:", d.cache_write_tokens)
hit_rate = d.cached_tokens / max(resp.usage.input_tokens, 1)
print(f"token cache-hit rate: {hit_rate:.0%}")
Nos modelos compatíveis com prompt_cache_options, cache_write_tokens_details divide as gravações em ttl_30m_tokens e ttl_12h_tokens. O valor de cached_tokens é arredondado para baixo a um múltiplo de 128. A OpenAI também oferece um Prompt Caching Dashboard para acompanhar as taxas de acerto e a ferramenta Prompt Cache Diagnostics, que explica os misses.
Regras de design de prompt que aumentam os acertos
- Estático primeiro, dinâmico por último. Coloque no topo as instruções, os schemas de ferramentas, os exemplos few-shot e os documentos de referência. Coloque no final a mensagem do usuário, os trechos recuperados e tudo o que tiver data ou ID.
- Congele a lista de ferramentas. Alterar definições de ferramentas quebra o prefixo. Se requisições diferentes precisarem de ferramentas diferentes, mantenha as definições estáveis e mude quais podem ser chamadas.
- Acrescente, não reescreva. Em chats com vários turnos, adicione os novos turnos ao final. Resumir ou editar turnos anteriores invalida o cache.
- Mantenha as configurações estáveis. O modelo, as configurações de raciocínio e outras opções da requisição podem alterar o prefixo renderizado. Fixe-as para o tráfego em cache.
- Atenção aos fallbacks. Se você mudar para outro modelo ou provedor, começa com o cache frio. Nosso manual de estratégias de fallback de modelos mostra como fazer failover sem perder toda a localidade do cache.
Cache de prompts: OpenAI vs Anthropic vs Gemini
O cache não é portável entre provedores. A mecânica e os preços mudam:
| OpenAI (GPT-5.6+) | Anthropic Claude | Google Gemini | |
|---|---|---|---|
| Padrão | Automático | Opcional com cache_control (automático ou por bloco) |
Cache implícito automático no Gemini 2.5 e posteriores |
| Prefixo mínimo | 1.024 tokens | 512 tokens nos modelos atuais | 4.096 tokens no Gemini 4 Argon e 3.8 Flash |
| Custo de gravação | 1,25× (30 min) ou 2,5× (12 h) | 1,25× (5 min) ou 2× (1 h) | Sem taxa de gravação no implícito; o explícito adiciona armazenamento por hora |
| Custo de leitura | 0,1× (0,05× no GPT-6.1 Sol) | 0,1× (0,05× no Opus 5.5 e Sonnet 5.5) | ex.: US$ 0,10 vs US$ 2,00 de entrada no Gemini 4 Argon |
| Campo de uso | cached_tokens, cache_write_tokens |
cache_read_input_tokens, cache_creation_input_tokens |
total_cached_tokens |
Fontes: a documentação de cache de prompts da Anthropic, os preços da API do Claude, o cache de contexto do Gemini e os preços da API do Gemini, todos verificados em 25 de outubro de 2026. O Gemini 4 Argon só oferece cache implícito. Objetos de cache explícito funcionam nos modelos Gemini 3 e 2.5 compatíveis via generateContent, com armazenamento cobrado por milhão de tokens por hora (por exemplo, US$ 0,50 no Gemini 3.8 Flash até 31 de dezembro de 2026). O DeepSeek também faz cache automático; veja o guia de cache do DeepSeek.
Checagem de ROI do cache em sete dias
Antes de declarar o cache um sucesso, meça-o com tráfego real:
- Dia 1: escolha um fluxo de alto volume com um prefixo compartilhado longo. Registre por requisição os tokens de entrada,
cached_tokens,cache_write_tokens, os tokens de saída e a latência. - Dias 2–3: mova todo o conteúdo estático para o topo e remova dele os valores dinâmicos. Compare a taxa de acerto por token (tokens em cache ÷ tokens de entrada) antes e depois.
- Dias 4–5: se houver muitas gravações e poucas leituras, seu tráfego está esparso demais para entradas de 30 minutos. Teste
"12h"na camada estável ou consolide o prefixo para que mais requisições o compartilhem. - Dias 6–7: calcule o custo real por resposta aceita, não só por token. Uma requisição mais barata que os usuários rejeitam não é economia.
Para uma carga estável de chat ou agentes, boas metas são uma taxa de acerto por token acima de 60% e pelo menos 10 leituras para cada gravação. Nosso guia de observabilidade de APIs de LLM e o guia de dashboards de uso de tokens mostram como montar essas visões.
Onde o Flatkey entra
O Flatkey é um roteador compatível com a OpenAI, com uma chave e um saldo para OpenAI, Claude, Gemini, DeepSeek, Qwen e outros modelos. O cache de cada provedor continua seguindo as regras dele, então mantenha os prompts estáveis por modelo e evite trocar de modelo a cada requisição se quiser acertos de cache. Comece pelo guia rápido do roteador, confira as tarifas atuais em preços do Flatkey e veja nosso guia de otimização de custos de APIs de IA para outras formas de reduzir gastos.
Perguntas frequentes
O cache de prompts da OpenAI é automático?
Sim. O cache de prompts vem ativado por padrão nos modelos compatíveis da OpenAI, e você não precisa mudar o código para ter acertos. No GPT-5.6 e posteriores, é possível mudar para o modo explícito e escolher os breakpoints com prompt_cache_breakpoint.
Quanto o cache de prompts da OpenAI economiza?
A entrada em cache custa 0,1x a tarifa normal na maioria dos modelos atuais e 0,05x no GPT-6.1 Sol, um desconto de 90–95% sobre a parte em cache. A economia total depende de quanto de cada prompt é prefixo compartilhado e de com que frequência ele é reutilizado.
Qual é o tamanho mínimo de prompt para o cache?
1.024 tokens no GPT-5.6 e posteriores. Em modelos anteriores, varia conforme as configurações da requisição. Prefixos menores são processados normalmente, sem erro.
Quanto tempo dura o cache de prompts da OpenAI?
No GPT-5.6 e posteriores, as entradas duram pelo menos 30 minutos por padrão, ou pelo menos 12 horas se você definir ttl como "12h". Em modelos anteriores, in_memory as mantém por cerca de 5–10 minutos de inatividade, até uma hora, e 24h pode retê-las por até 24 horas.
O cache de prompts reduz a latência?
Sim. Reutilizar um prefixo em cache evita recalculá-lo, o que reduz o tempo até o primeiro token, principalmente em prompts longos.
Eu pago para gravar no cache?
No GPT-5.6 e posteriores, sim: 1,25x a tarifa de entrada para uma gravação de 30 minutos ou 2,5x para 12 horas. Isso substitui a cobrança normal de entrada desses tokens; não é somado a ela.
O que é prompt_cache_key?
Um parâmetro opcional que agrupa requisições relacionadas para que sejam direcionadas ao mesmo cache. Em modelos anteriores ao GPT-5.6, ele melhora a taxa de acerto; a OpenAI sugere cerca de 15 requisições por minuto por chave.
Fontes
- Guia de cache de prompts da OpenAI (verificado em 25 de outubro de 2026)
- Preços da API da OpenAI (verificado em 25 de outubro de 2026)
- Cache de prompts da Anthropic (outubro de 2026)
- Preços da API do Claude (outubro de 2026)
- Cache de contexto do Gemini (outubro de 2026)
- Preços da API do Gemini (outubro de 2026)
- Cache de contexto do DeepSeek (outubro de 2026)


