DR
A precificação de entrada em cache pode reduzir materialmente o custo de workloads que reenviam um grande prefixo de prompt inalterado, mas as economias dependem de regras específicas do modelo para leitura de cache, gravação de cache, armazenamento, roteamento e retenção. Um rótulo geral “caching supported” não é suficiente para estimar o custo; use o preço atual publicado para o modelo e a rota exatos.
TL;DR
- GPT-5.6 Terra tem preços explícitos de leitura e gravação de cache da OpenAI, da CometAPI e da OpenRouter, embora rotas de gateway e camadas de contexto longo possam alterar o valor.
- O Google publica uma taxa Standard de armazenamento em cache de contexto de $0.15 por 1M tokens para Gemini 3.6 Flash mais uma cobrança de armazenamento; a CometAPI no momento publica os preços padrão de entrada e saída do modelo sem uma linha separada para entrada em cache.
- A comparação relevante não é apenas entrada padrão versus leitura em cache. Ela também inclui a primeira gravação em cache, qualquer cobrança de armazenamento, vida útil do cache, consistência de rota e o número de acertos de cache posteriores.
Mensagens-chave
- Verifique os preços no nível do modelo e da camada de serviço, em vez de aplicar um multiplicador amplo do gateway.
- Mantenha leitura de cache, gravação de cache, armazenamento e cache de resposta separados nos cálculos de custo.
- Verifique o uso real de cache nos metadados da resposta da API antes de prever economias a partir da taxa publicada.
Uma solicitação que repete um grande prefixo inalterado — um prompt de sistema, um conjunto de esquemas de ferramentas, um documento de referência longo — não precisa ser cobrada pela taxa de entrada completa em cada chamada. A maioria dos modelos de geração atual suporta alguma forma de precificação de entrada em cache: uma taxa reduzida para a parte do prompt que um provedor reconhece como já processada. O mecanismo, o tamanho do desconto e o quão claramente isso é publicado variam por provedor e por gateway, e essa variação merece ser especificada, em vez de tratar “caching is supported” como um recurso uniforme.
O que é precificação de entrada em cache e o que não é
A precificação de entrada em cache desconta os tokens de entrada em uma solicitação que correspondem a um prefixo previamente enviado. Ela não desconta tokens de saída e não é a mesma coisa que um gateway desduplicar duas solicitações totalmente idênticas e retornar uma resposta gratuitamente — esse é um mecanismo diferente que alguns gateways oferecem separadamente. A precificação de entrada em cache trata especificamente de pagar menos pela parte de um prompt que um provedor de modelo já viu recentemente, não de pular a geração completamente.
Também não é gratuito criar. As notas de preços do GPT-5.6 da OpenAI indicam que gravações de cache são cobradas a 1,25 vezes a taxa de entrada sem cache, enquanto leituras de cache recebem um desconto de 90%. Esse prêmio pela primeira gravação afeta o ponto de equilíbrio e é fácil de perder se uma comparação mostrar apenas a taxa de leitura com desconto. Outros provedores podem usar cobranças baseadas em armazenamento em vez do mesmo modelo de gravação, portanto os custos de gravação e armazenamento devem ser verificados separadamente.
Na prática, a unidade de cache faturável geralmente é um prefixo de prompt reutilizável, em vez de uma coleção arbitrária de frases repetidas. Os provedores tokenizam e fazem a correspondência do conteúdo em ordem, então o material reutilizável precisa aparecer antes da cauda específica da solicitação. Instruções estáveis do sistema, definições de ferramentas, políticas e material de referência compartilhado pertencem ao início; uma mensagem de usuário que muda, timestamp, ID de solicitação ou trecho recuperado pertence mais tarde. Mesmo uma mudança semanticamente inofensiva perto do início pode deslocar a tokenização ou quebrar a correspondência para tudo que se segue.
As regras de elegibilidade também são específicas do modelo. Um provedor pode exigir um comprimento mínimo de prompt, reconhecer apenas pontos de quebra documentados ou expor um campo explícito de controle de cache. Uma entrada de cache pode expirar entre chamadas, e um gateway pode precisar manter solicitações relacionadas em uma rota upstream compatível. Isso significa que uma implementação deve tratar um acerto de cache como um resultado observado, não como uma suposição feita a partir da similaridade do prompt. Um prompt bem estruturado melhora a probabilidade de reutilização, mas os metadados da resposta e a fatura determinam se a taxa com desconto foi realmente aplicada.
O que está realmente publicado, por modelo e por gateway
A tabela abaixo é um instantâneo de preços verificado em 29 de julho de 2026. Os preços estão em dólares americanos por 1 milhão de tokens, a menos que outra unidade seja informada. As linhas comparam informações públicas atuais para GPT-5.6 Terra e Gemini 3.6 Flash entre o provedor do modelo, a CometAPI e a OpenRouter; não devem ser tratadas como uma tarifa permanente.
| Modelo | Gateway | Entrada padrão | Entrada em cache (leitura) | Gravação de cache | Desconto divulgado? |
|---|---|---|---|---|---|
| GPT-5.6 Terra | Tarifa oficial da OpenAI | $2.50 / 1M | $0.25 / 1M | $3.13 / 1M | Sim — 90% de desconto, declarado diretamente |
| GPT-5.6 Terra | CometAPI | $2.00 / 1M | $0.20 / 1M | $2.50 / 1M | Sim — listado na página de preços própria da CometAPI |
| GPT-5.6 Terra | OpenRouter | $2.50 / 1M | Não listado como uma tarifa específica | Não listado | Não — descrito apenas como “60–80% mais barato” em agregado, sem cifra por modelo |
| Gemini 3.6 Flash | Tarifa oficial do Google | $1.50 / 1M | $0.15 / 1M (conforme o próprio anúncio do Google) | Não divulgado | Sim, no lançamento — via documentação do modelo do Google |
| Gemini 3.6 Flash | CometAPI | $1.20 / 1M | Não listado como uma tarifa específica | Não divulgado | Não — a página da CometAPI marca “Caching” como um recurso suportado, mas não publica um valor descontado de entrada em cache para este modelo específico até o momento desta redação |
| Gemini 3.6 Flash | OpenRouter | $1.50 / 1M | Não listado como uma tarifa específica | Não divulgado | Não — a documentação própria da OpenRouter descreve genericamente o multiplicador de cache do Google (0.25x sobre a entrada de lista) em vez de confirmar a taxa específica deste modelo |
Leia a tabela como um instantâneo específico de modelo e rota. A Página do modelo GPT-5.6 da CometAPI detalha o GPT-5.6 Terra em $2.00 de entrada padrão, $0.20 de entrada em cache e $2.50 de gravação de cache por 1 milhão de tokens. Sua Página do modelo Gemini 3.6 Flash atualmente publica $1.20 de entrada e $6.00 de saída, mas não mostra um preço separado de entrada em cache ou de armazenamento de cache. Os Preços da Gemini Developer API do Google listam o nível Standard em $1.50 de entrada, $0.15 de cache de contexto e $1.00 por 1 milhão de tokens por hora para armazenamento. A OpenRouter agora expõe campos de cache específicos do modelo por meio de sua Models API: a rota padrão do GPT-5.6 Terra inclui preços promocionais mais baixos e uma camada separada e mais alta de contexto longo, enquanto sua entrada do Gemini 3.6 Flash expõe diferentes valores Standard, Flex e Priority. Isso é mais preciso do que aplicar um multiplicador de cache genérico a todos os modelos.
Por que os preços do gateway e do provedor podem divergir
O preço de um gateway não é necessariamente um markup sobre um preço de lista upstream imutável. Ele pode refletir capacidade negociada, uma promoção temporária, uma camada de serviço diferente ou um acordo comercial específico da rota. Um nome de modelo também pode mapear para múltiplas variantes upstream cujos preços mudam com o comprimento de contexto ou garantias de latência. A entrada do GPT-5.6 Terra na OpenRouter, por exemplo, publica uma rota padrão e uma substituição de preço mais alta quando a entrada atinge seu limite de contexto longo. O Google separa preços Standard, Batch, Flex e Priority para o Gemini 3.6 Flash. Uma única linha de comparação, portanto, precisa de data, rota, camada e suposição de contexto para permanecer significativa.
O inverso também é importante: se uma página de gateway não publica uma linha separada de leitura de cache, essa ausência não deve ser convertida em “cache indisponível” nem em “o desconto direto do provedor aplica-se automaticamente”. O gateway pode repassar um recurso upstream sem detalhá-lo, expô-lo apenas em certas rotas ou faturar a solicitação sob sua taxa normal de entrada. A abordagem defensável é usar a página de modelo atual do próprio gateway para planejamento e, em seguida, confirmar a taxa real a partir dos registros de uso ou dos dados de faturamento. A documentação do provedor continua útil para entender o mecanismo, mas por si só não estabelece os termos comerciais de um intermediário.
Onde o desconto realmente importa
O cenário em que isso muda o custo real de forma significativa é um grande prefixo estático emparelhado com uma solicitação pequena e variável — um prompt de sistema ou conjunto de esquemas de ferramentas reenviado em cada chamada em um loop de agente, um documento de referência longo consultado repetidamente com diferentes perguntas ou um histórico de conversação reenviado a cada turno do chatbot. Para um workload desse tipo, a diferença entre pagar o preço de entrada completo em todo o prefixo todas as vezes versus pagar a sobretaxa de gravação uma vez e a taxa de leitura com desconto depois se acumula com o volume de chamadas. Não faz nada por workloads que não repetem um prefixo — uma solicitação pontual não tem conteúdo em cache a ser descontado.
Um cálculo prático de ponto de equilíbrio compara o custo sem cache do prefixo repetido em todas as chamadas com o custo de gravação de cache ou de armazenamento mais as leituras de cache com desconto nas chamadas posteriores. O resultado depende do tamanho do prefixo, do número de acertos de cache bem-sucedidos, da expiração do cache e de se o gateway mantém as solicitações em uma rota de provedor compatível. Se essas condições forem instáveis, o desconto de manchete pode superestimar as economias realizadas em produção.
Um modelo de custo simples para um prefixo repetido
Seja P o número de tokens no prefixo estável e N o número de chamadas que o reutilizam. Se U é o preço de entrada sem cache por token, o prefixo custa N × P × U sem cache. Uma estimativa simplificada com cache é P × W + (N − 1) × P × R + S, em que W é o preço de gravação de cache, R é o preço de leitura de cache e S é qualquer cobrança de armazenamento ao longo do período. A fórmula assume que a primeira chamada cria o cache e que cada chamada posterior é um acerto bem-sucedido. Ela exclui a cauda variável de cada solicitação, tokens de saída, novas tentativas e qualquer mudança de rota que cause um miss.
Considere um prefixo ilustrativo de 100.000 tokens reutilizado em 20 chamadas na tarifa oficial do GPT-5.6 Terra. A $2.50 por 1 milhão de tokens de entrada sem cache, processar repetidamente esse prefixo custaria $5.00. Usando a taxa de gravação publicada de 1,25 vezes e a taxa de leitura com desconto de 90%, uma gravação de 100.000 tokens custaria cerca de $0.3125 e dezenove leituras custariam cerca de $0.475, para um custo combinado de prefixo de aproximadamente $0.7875. A diferença é de cerca de $4.21 antes dos custos variáveis de entrada e saída. Isto é uma ilustração, não uma cotação: só vale se todas as dezenove chamadas posteriores atingirem o mesmo cache válido e nenhuma cobrança adicional de armazenamento ou roteamento se aplicar.
O ponto de equilíbrio decorre diretamente do mesmo modelo. Uma sobretaxa de gravação se justifica apenas quando ocorrem leituras com desconto suficientes antes da expiração. Para um workload com sessões curtas, edições frequentes de prompt ou fraca afinidade de rota, o cache pode ser recriado mais frequentemente do que o esperado. Para um loop de agente de longa duração ou análise repetida de documento com um prefixo estável, o número de acertos pode ser muito maior. As previsões devem, portanto, usar uma faixa de taxa de acerto observada, em vez de assumir uma sequência perfeita após a primeira chamada.
Padrões de implementação que melhoram a reutilização de cache
A construção do prompt tem um efeito maior sobre a taxa de acerto do que muitas planilhas de preços sugerem. Coloque o material mais estável primeiro e mantenha sua serialização determinística: instruções de sistema, esquemas de ferramentas, texto de políticas e contexto de referência compartilhado devem manter a mesma ordem, espaços em branco e representação de campos entre chamadas relacionadas. Anexe conteúdo volátil depois. Evite injetar timestamps, identificadores aleatórios, contadores continuamente cambiantes ou resultados de recuperação específicos da solicitação no prefixo reutilizável, a menos que sejam genuinamente necessários ali.
Versione deliberadamente o material estável. Se um esquema de ferramenta ou política mudar, atribua a nova versão de forma consistente em vez de permitir que múltiplas variantes quase idênticas circulem. Para workloads conversacionais ou agênticos, reutilize um identificador de sessão estável ou uma chave de cache quando a API suportar uma, e evite alternar de provedor dentro da mesma sequência dependente de cache. A OpenRouter documenta roteamento fixo ao provedor para cache de prompt e expõe controles como session_id e prompt_cache_key; esses controles podem melhorar a continuidade, mas não garantem um acerto quando o cache upstream está frio ou expirado.
As aplicações também devem degradar de forma limpa em caso de falha de cache. O cache é uma otimização de custo e latência, não uma dependência de correção. A solicitação ainda deve produzir o mesmo resultado válido quando o cache estiver indisponível, e a lógica de repetição não deve criar cegamente gravações repetidas. Essa separação torna mais seguro comparar rotas: as equipes podem mudar a política de cache ou a configuração do gateway sem alterar o comportamento semântico da aplicação.
Como verificar a economia do cache em produção
Comece com telemetria por solicitação, em vez da fatura mensal. Registre o identificador exato do modelo, a rota do gateway ou provedor quando exposta, a camada de serviço, o total de tokens de entrada, tokens de leitura de cache, tokens de gravação de cache, tokens de saída, latência e custo faturado. O objeto de uso da OpenRouter inclui cached_tokens e cache_write_tokens; outros provedores expõem detalhes equivalentes sob nomes de campo diferentes. Preserve os campos brutos de uso para que uma alteração posterior de preços não apague as evidências necessárias para reconstruir o custo.
Agregue os dados por versão de prompt e workload, não apenas por modelo. Medidas úteis incluem a parcela de solicitações elegíveis que acertam um cache, a parcela de tokens de entrada faturados à taxa de leitura, gravações por leitura bem-sucedida, tempo entre a gravação e o último acerto, e custo realizado por solicitação. Uma alta taxa de acerto no nível da solicitação ainda pode entregar pouco valor se o prefixo em cache for pequeno, enquanto uma taxa de acerto menor em um prefixo muito grande pode economizar mais. Emparelhe essas medidas com percentis de latência, porque uma rota mais barata que repetidamente erra ou redireciona pode ser operacionalmente pior.
Por fim, examine anomalias em vez de suavizá-las. Uma queda súbita em tokens em cache pode indicar uma implantação de versão de prompt, serialização instável, entradas expiradas, limite de camada de contexto longo ou mudança de rota do gateway. Compare as solicitações afetadas com a página de modelo atual e a documentação do provedor, depois verifique a taxa faturada. Isso fecha a lacuna entre um desconto publicado e as economias que a aplicação realmente realiza.
O que verificar antes de presumir que uma tarifa se aplica
Confirme cinco itens antes de usar uma tarifa publicada em um orçamento: o modelo e a camada de serviço exatos, o prefixo reutilizável mínimo ou pontos de quebra explícitos de cache, a cobrança de primeira gravação ou de armazenamento, a vida útil do cache e evidências de que as solicitações estão realmente acertando o cache. A OpenAI atualmente declara uma vida útil mínima de cache de 30 minutos para o GPT-5.6, mas essa não é uma regra universal de retenção. O Google publica tarifas diferentes para os níveis de serviço Standard, Batch, Flex e Priority. Gateways também podem rotear entre provedores ou camadas, então a rota selecionada importa. A documentação de prompt-caching da OpenRouter recomenda verificar campos de uso da resposta como cached_tokens e cache_write_tokens. Para qualquer estimativa de produção, compare a página atual do modelo com o faturamento real e metadados de uso, em vez de se basear apenas em um rótulo geral “caching supported”.