Guia de custos do GPT-5.6: prompt caching com 90% de desconto e reasoning effort

O GPT-5.6 mexe nas duas alavancas de custo ao mesmo tempo: o input em cache cai para 10% da taxa de input (o 5.x dava 50% de desconto) e, com o reasoning ligado por padrão, não enviar reasoning_effort custou 1,5x mais do que fixá-lo em none na nossa matriz de 50 chamadas, com respostas idênticas. Do lado do input, você agora pode fixar até quatro cache breakpoints de forma explícita; do lado do output, o botão de effort decide quanto raciocínio você paga. Medimos as duas alavancas pelo gateway nos modelos do dia do lançamento: Sol (US$5/US$30 por 1M de tokens in/out), Terra (US$2,50/US$15) e Luna (US$1/US$6), com cada taxa confirmada contra o medidor usage.cost ao vivo.

TL;DR

• O input em cache é cobrado a 10% da taxa de input, medido em US$0,10/US$0,25/US$0,50 por 1M nos três tiers; o 5.x dava 50% de desconto.
• Os breakpoints permitem reuso parcial: alterar o bloco depois de um marcador recobrou só 1.210 de 2.431 tokens.
• Prefixos abaixo de 1.024 tokens nunca entram em cache e repetições podem falhar em silêncio; conte com hit rates abaixo de 100%.
• As gravações em cache são cobradas a 1,25x sobre os tokens gravados; uma gravação que nunca é lida sai mais cara do que não usar cache.
• Omitir reasoning_effort custou 1,5x mais do que none numa matriz de 4 tarefas, com respostas idênticas; fixe-o de forma explícita.

Medido em 2026-07-10 pelo gateway da Synthorai (chat completions compatível com OpenAI), um dia depois de a OpenAI anunciar a família. Os três modelos estão no ar; os novos parâmetros de caching passam sem alteração.

Três tiers, uma geração

O esquema de nomes é novo: o número é a geração, e Sol, Terra e Luna são tiers de capacidade que substituem os sufixos pro/mini/nano. Os três compartilham uma janela de contexto de 1M de tokens e 128K de output máximo. Cada taxa abaixo bate exatamente com o usage.cost medido sobre contagens de tokens conhecidas, incluindo a coluna de cache:

O Sol é o carro-chefe e o sucessor do gpt-5.5 com preço equivalente: a tabela é idêntica, em US$5/US$30. Terra e Luna são os tiers reduzidos da mesma geração, a metade e a um quinto do preço do Sol, ocupando as vagas que antes eram dos sufixos mini e nano. Para contagem de tokens, os três são um só modelo: todos retornaram contagens idênticas em cada amostra que enviamos.

Como funciona o cache no 5.6, segundo a documentação

O cache do GPT costumava ser um único comportamento: a própria API detectava prefixos repetidos de 1.024+ tokens e cobrava a parte em cache pela metade do preço. Foi exatamente por isso que nossa comparação de provedores colocou o GPT na coluna “totalmente automático”. O guia de cache do 5.6 substitui isso por um design de dois modos:

{
  "model": "gpt-5.6-luna",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "...stable system prompt, 1024+ tokens...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "the varying part" }
  ]
}

As regras que importam, resumidas do guia:

• Um breakpoint marca o fim de um prefixo em cache, cobrindo aquele bloco e tudo que vem antes dele. O modo implicit (o padrão) ainda coloca automaticamente um breakpoint na última mensagem; o modo explicit só coloca em cache o que você marcar.
• Quatro escritas de cache por requisição, e o breakpoint automático do modo implícito consome uma delas. Ou seja, os marcadores explícitos ficam com três slots no modo padrão e quatro no modo explicit. Breakpoints de turnos anteriores da conversa são somente leitura nas requisições seguintes.
• O piso de 1.024 tokens continua valendo: um prefixo marcado abaixo disso não vai para o cache.
• ttl: "30m" é um tempo de vida mínimo garantido, não um teto (“pelo menos 30 minutos… pode reter por mais tempo”). Substitui o prompt_cache_retention, que está deprecated no 5.6, e com isso a antiga opção de retenção estendida de 24h também desaparece.
• prompt_cache_key é como você garante correspondência confiável: o guia recomenda uma chave estável por tenant ou sessão para rotear as repetições para o mesmo cache, com um limite flexível em torno de 15 requisições por minuto por chave. Os caches ficam restritos à sua organização.
• As escritas de cache são cobradas a 1,25x da taxa de input no 5.6+, reportadas no novo campo usage.prompt_tokens_details.cache_write_tokens. No 5.x e anteriores, as escritas eram gratuitas.

O GPT-5.5 e versões anteriores rejeitam os novos parâmetros com um 400 limpo (prompt_cache_options is not supported on this model), então faça version-gate em qualquer rollout.

Se o design parece familiar, é porque é mesmo: marcadores em blocos de conteúdo, quatro breakpoints, um prêmio de escrita e um histórico deslizante somente leitura são o formato que o cache_control do Claude sempre teve. A diferença está no TTL: o piso garantido de 30 minutos da OpenAI é 6x maior que os 5 minutos padrão do Claude.

O que o medidor diz

Documentação é promessa; aqui está o que o medidor do gateway retornou, teste a teste. Os registros brutos completos estão no log da execução; todos os custos abaixo batem, dígito a dígito, com as tarifas de cada tier.

Três dessas linhas merecem detalhamento.

O reúso parcial é real, e é o motivo para adotar breakpoints. Com um bloco A estável e uma cauda B trocada, o medidor recobrou só a cauda: 1.212 tokens lidos de volta à tarifa cacheada, 1.210 escritos para o novo B ao prêmio de escrita, de um prompt de 2.431 tokens, e o total bate com a tabela de preços dígito a dígito. É o comportamento de prefixo em camadas (system prompt, depois tools, depois documents, cada um marcado) que usuários do Claude usam para estruturar seus prompts, e que o modo automático do GPT nunca conseguiu garantir. Uma ressalva: em repetições completas o comprimento casado às vezes cai abaixo da marca (1.897 de uma escrita de 2.422 tokens em um teste), então faça o orçamento pela tarifa de desconto, não pela contagem exata de casamentos.

O piso e as falhas silenciosas são as armadilhas operacionais. Um bloco marcado de 621 tokens não armazenou nada em cache, duas vezes, sem erro e sem indício de uso além dos zeros; se o seu “prefixo estável” for um prompt de sistema curto, você está pagando o preço integral e nada te avisa. E uma falha pode chegar sem uma escrita, a preço integral, igualmente em silêncio. A taxa de acerto é uma distribuição, não uma promessa, seja qual for o caminho que suas requisições tomem: leia cached_tokens em produção e crie alertas para isso, do jeito que nossa auditoria de cache de cinco minutos faz.

O prêmio de escrita é real, e muda o ponto de equilíbrio. Tokens escritos são cobrados exatamente a 1,25x a tarifa de input nos três tiers (a Luna mede escrita a $1,25 por milhão, a Terra a $3,125, a Sol a $6,25), batendo dígito a dígito em todos os testes da execução final. Esse prêmio só se paga quando o prefixo é lido de novo: uma escrita que nunca recebe um hit custa 25% a mais do que não cachear nada, a mesma armadilha que medimos no prêmio de escrita do Claude no post do LangChain. Marque prefixos que você sabe que vão se repetir, não tudo que parece estável.

O piso de 30 minutos se manteve até onde sondamos. Uma releitura com chave 15 minutos após a escrita retornou totalmente em cache (1.313 de 1.313 tokens, reconciliando à taxa de 10%), bem além do antigo horizonte em memória de 5 a 10 minutos, e uma segunda sondagem com chave no mesmo intervalo repetiu o resultado. Não sondamos os 30 minutos completos.

O mesmo workload no GPT-5.5, para contraste

A comparação justa é a de mesmo preço: o Sol tem exatamente a mesma tabela do gpt-5.5 ($5/$30), então é o sucessor direto, com Terra e Luna como os tiers reduzidos abaixo dele. Mesmo preço de tabela, mas condições de cache bem diferentes:

Pelo mesmo preço de tabela, os termos de cache são o upgrade. Um prefixo de 3.000 tokens custa $0.0075 por chamada no 5.5 quando seu cache automático decide acertar, e $0.0015 no Sol aquecido, 5x menos na parcela em cache. A mudança mais profunda é controle e visibilidade: os acertos do 5.5 dependem de uma detecção opaca de prefixo que você não pode acionar nem depurar, enquanto o 5.6 permite marcar exatamente o que deve ser armazenado em cache, rotear repetições com uma prompt_cache_key e observar cada escrita chegar em usage. Uma falha agora aparece como um zero num campo que você criou, não como silêncio. O caminho de rebaixamento se acumula por cima: se o 5.5 estava sobre-servindo a carga de trabalho, o Terra reduz pela metade toda a tabela de preços e o Luna a divide por cinco, e o mesmo prefixo aquecido cai para $0.00075 e $0.0003. A única coisa que o 5.5 mantém é a retenção opcional de 24 horas; se o seu tráfego é um lote diário contra um prefixo gigante, esse trade-off corre no sentido oposto. E note que a segunda alavanca corta no sentido contrário na migração: o 5.6 raciocina por padrão, então uma carga de trabalho do 5.5 movida sem fixar reasoning_effort incorpora novo gasto de saída na mesma tabela de preços.

A segunda alavanca: reasoning effort

O cache controla o que você paga na entrada; o reasoning_effort controla o lado da saída, porque os tokens de reasoning são cobrados à tarifa de saída e, ao contrário do seu prefixo, nunca podem ser cacheados. O GPT-5.6 aceita de none até xhigh em todos os tiers. O post de lançamento também apresenta um esforço max para o Sol; via chat completions ele não existe (400: 'reasoning_effort' does not support 'max' with this model, tanto no Sol quanto no Terra), então xhigh é o teto prático no caminho de API que gateways e SDKs usam.

Rodamos uma matriz de 50 chamadas: quatro formatos de tarefa (classificar uma review, extrair um campo de uma linha de log, um problema aritmético de múltiplas etapas e uma pequena tarefa de geração de código) em todas as seis configurações, de none a xhigh mais o parâmetro omitido, no Terra e no Luna com uma verificação pontual no Sol. Todas as 50 respostas estavam corretas em todas as configurações. O que variou foi a conta. São chamadas de saída curta (dezenas de tokens visíveis), então algumas dezenas de tokens de reasoning à tarifa de saída dominam o total; a coluna de razão compara o custo da chamada inteira:

Três constatações. Primeiro, o 5.6 é adaptativo por conta própria: nos dois formatos triviais, nenhuma configuração gastou um único token de reasoning, então o botão é grátis ali. Segundo, nos formatos que parecem merecer raciocínio (math, code), o default raciocina mesmo quando isso não traz nada: omitir o parâmetro custou de 2.5x a 3.5x o preço do none no math e no code do Luna e no math do Terra (o code do Terra por acaso não gastou nada no default) para as mesmas respostas corretas, e 1.5x mais somado por toda a grade do Terra e do Luna. Terceiro, as configurações intermediárias (não mostradas na tabela) são ruído, não um controle gradual: o math do Terra gastou 19 tokens de reasoning em low, zero em medium, 21 em high e zero de novo em xhigh, e o code do Luna gastou 101 em xhigh contra 41 em high. Os nomes são intenções, não orçamentos, o mesmo comportamento que medimos no GLM 5.2.

Envie reasoning_effort explicitamente em cada chamada, e use none como default para classificação, extração, roteamento e transformações curtas. Só aumente o esforço em um ponto de chamada específico quando seus evals mostrarem a configuração mais alta mudando resultados, não porque a tarefa parece difícil. Nossos quatro formatos são cargas de API com saída curta; um trabalho realmente difícil de múltiplas etapas pode justificar o gasto com reasoning, mas deixe as medições dizerem isso.

As duas alavancas se somam. Uma vez que um prefixo está quente, o lado de entrada de uma chamada Luna custa um décimo do preço de tabela, e o default de reasoning passa a ser o maior item restante em tarefas curtas: a chamada math do Luna custou $0.00007 no total em none e $0.00025 com o parâmetro omitido: só o default de reasoning adicionou $0.00018, mais que o dobro de toda a chamada gerenciada. Faça cache sem fixar o esforço e a economia vaza de volta pelo outro lado.

O que recomendar por tipo de carga

A decisão agora tem uma estrutura clara, então é isto que dizemos aos clientes do gateway:

Independente do formato: envie uma prompt_cache_key estável por tenant ou sessão (a documentação torna a chave a base para uma correspondência confiável), mantenha cada camada marcada acima do piso de 1.024 tokens e monitore cached_tokens porque existem falhas silenciosas. Lembre-se de que os caches são por modelo: um teste A/B entre tiers reaquece do zero em cada lado. E ajuste a outra alavanca no mesmo commit: fixe reasoning_effort conforme a matriz acima, none a menos que uma avaliação diga o contrário.

Na escolha de tier, o desconto de 90% mexe mais na conta do que o tier em si. Uma carga que reprocessa um prefixo de 3.000 tokens paga cerca de $0,30 por mil chamadas desse prefixo em tráfego Luna quente, e $1,50 em Sol quente; a diferença entre tiers na parte cacheada é menor que a diferença nos tokens de saída, então escolha o tier pela qualidade da saída e pelo preço, e deixe o cache achatar o lado da entrada. Vindo do gpt-5.5, o Sol é o upgrade direto na mesma tabela de preços, com leituras de cache 5x mais baratas e controle sobre quando elas acontecem; desça para Terra ou Luna onde suas evals mostrarem que o tier menor aguenta, e a tabela de preços cai pela metade ou por cinco em cima disso.

O tokenizer não mudou

Nossas 24 amostras (um trecho narrativo em nove idiomas, versões técnica e jornalística em seis deles, uma função Python e um tool-call JSON) contam de forma idêntica em GPT-5.5, Sol, Terra e Luna em toda comparação que concluiu. Os orçamentos de token e as estimativas de piso de cache calibrados no 5.5 valem sem alteração; o comportamento entre idiomas está no nosso post de tokenizer por idioma e se aplica ao 5.6 do jeito que está.

Conclusão

• O desconto de cache subindo de 50% para 90%, com TTL garantido de 30 minutos, é o verdadeiro corte de preço deste release; os preços de tier são a manchete, mas os termos de cache mexem mais nas contas reais.
• Adote breakpoints explícitos para prompts em camadas: o reuso parcial é medido, não teórico, e o modelo mental do Claude transfere um para um.
• Respeite o piso de 1.024 tokens, envie um prompt_cache_key e monitore cached_tokens; existem tanto misses silenciosos quanto casos silenciosos de não-cacheado-nenhum.
• Envie reasoning_effort de forma explícita, com default none: o default não gerenciado cobrou 1,5x mais em toda a nossa matriz, chegando a 3,5x em tarefas isoladas, para respostas idênticas.
• xhigh é o teto alcançável (max de 400s via chat completions); sem re-baseline de tokenizer a partir do 5.5.

FAQ

O GPT-5.6 suporta prompt caching explícito como o Claude? Sim. prompt_cache_options: {"mode": "explicit"} mais marcadores prompt_cache_breakpoint nos blocos de conteúdo, até quatro writes por requisição (três no modo implícito, onde o breakpoint automático ocupa um slot). Medindo através de um gateway compatível com OpenAI, um prefixo marcado de 3.012 tokens foi escrito na primeira chamada e lido de volta por completo na taxa cached na segunda.

Quanto custa o input cached no GPT-5.6? 10% da taxa de input, medido nos três tiers: $0,10 por milhão no Luna, $0,25 no Terra, $0,50 no Sol. O GPT-5.x cobrava tokens cached a 50% do input, então a taxa por token cached é 5x menor no 5.6.

O caching do GPT-5.6 é melhor que o do GPT-5.5? Em profundidade de desconto e controle, sim: taxa cached de 10% contra 50%, quatro breakpoints explícitos contra apenas detecção automática que você não consegue disparar nem depurar, e um piso garantido de 30 minutos por chave contra 5-10 minutos best effort. A única vantagem que resta ao 5.5 é o tier opcional de retenção de 24 horas, que o 5.6 abandona.

Quanto tempo dura o cache do GPT-5.6? A documentação garante pelo menos 30 minutos (ttl: "30m" é o único valor aceito), possivelmente mais; a opção substitui o prompt_cache_retention obsoleto, incluindo o antigo nível estendido de 24 horas. Em nossos testes, releituras com chave 15 minutos após a escrita acertaram por completo; não testamos os 30 completos.

Preciso de prompt_cache_key? Envie-o: a documentação faz de uma chave estável por locatário ou sessão a base para correspondência confiável no 5.6, com um limite flexível de cerca de 15 requisições por minuto por chave. Não custa nada incluí-lo, e combiná-lo com o monitoramento de cached_tokens é como você verifica se o desconto está realmente sendo aplicado.

Quanto o reasoning_effort altera o custo do GPT-5.6? Na nossa matriz de 50 chamadas (quatro formatos de tarefa, seis configurações, Terra e Luna), toda configuração produziu respostas corretas, e omitir o parâmetro cobrou 1,5x mais que none no geral, chegando a 3,5x na tarefa de aritmética. Em formatos triviais (classificação, extração) nenhuma configuração gastou reasoning tokens. Fixe none e escale apenas com base em evals.

O reasoning effort máximo está disponível no GPT-5.6 Sol? Não via chat completions. Requisições com reasoning_effort: "max" retornam um 400 listando de none a xhigh, tanto no Sol quanto no Terra.

Qual tier do GPT-5.6 uma carga de API deve usar? O Sol é o sucessor com paridade de preço do gpt-5.5 (mesma tabela de $5/$30, leituras cached 5x mais baratas); Terra e Luna são os tiers reduzidos, a metade e a um quinto disso. Uma vez que seu prefixo esteja estável e com chave, o desconto de 90% no cache achata o lado do input, então desça o quanto seus evals de qualidade de output permitirem e deixe o tier definir o preço do output.

← Voltar ao blog