Custos GPT-5.6: 90% de desconto com prompt caching e reasoning effort
Conteúdo
O GPT-5.6 altera os dois principais controles de custo ao mesmo tempo: o input em cache cai para 10% da tarifa de input, enquanto a geração 5.x dava 50% de desconto. Como o reasoning vem ativado por padrão, não enviar reasoning_effort custou 1.5x mais do que fixá-lo em none na nossa matriz de 50 chamadas, sem nenhuma diferença nas respostas. No input, agora é possível definir explicitamente até quatro breakpoints de cache. No output, o nível de effort determina quanto você paga pelo raciocínio. Medimos os dois controles pelo gateway nos modelos disponíveis desde o lançamento: Sol ($5/$30 por 1M de tokens de entrada/saída), Terra ($2.50/$15) e Luna ($1/$6). Todas as tarifas foram confirmadas pelo medidor usage.cost em produção.
TL;DR
- O input em cache custa 10% da tarifa de input: medimos $0.10/$0.25/$0.50 por 1M entre os tiers. Na geração 5.x, o desconto era de 50%.
- Breakpoints permitem reaproveitamento parcial: ao alterar o bloco depois de um marcador, somente 1,210 dos 2,431 tokens foram cobrados novamente.
- Prefixos com menos de 1,024 tokens nunca entram no cache, e repetições podem falhar silenciosamente. Planeje considerando uma taxa de acerto inferior a 100%.
- Escritas no cache custam 1.25x nos tokens gravados. Uma escrita que nunca é lida sai mais cara do que não usar cache.
- Na matriz com quatro tarefas, omitir
reasoning_effortcustou 1.5x mais do que usarnone, com respostas idênticas. Defina-o explicitamente.
Medições feitas em 2026-07-10 pelo gateway da Synthorai, usando chat completions compatíveis com OpenAI, um dia após o anúncio da família pela OpenAI. Os três modelos estão disponíveis, e os novos parâmetros de caching passam pelo gateway sem alterações.
Três tiers, uma geração
O padrão de nomes mudou: o número indica a geração, enquanto Sol, Terra e Luna representam tiers de capacidade e substituem os sufixos pro/mini/nano. Os três oferecem context window de 1M de tokens e output máximo de 128K. Todas as tarifas abaixo batem exatamente com o usage.cost medido em contagens de tokens conhecidas, inclusive na coluna de cache:
| tier | input /1M | output /1M | input em cache /1M (medido) |
|---|---|---|---|
| gpt-5.6-sol | $5.00 | $30.00 | $0.50 |
| gpt-5.6-terra | $2.50 | $15.00 | $0.25 |
| gpt-5.6-luna | $1.00 | $6.00 | $0.10 |
Sol é o modelo principal e sucede o gpt-5.5 com o mesmo preço: a tabela continua em $5/$30. Terra e Luna são os tiers menores da mesma geração. Custam, respectivamente, metade e um quinto do preço do Sol, ocupando o espaço antes reservado aos sufixos mini e nano. Para contagem de tokens, os três funcionam como um único modelo: todos retornaram contagens idênticas em todas as amostras enviadas.
Como funciona o caching no 5.6, segundo a documentação
Antes, o caching do GPT seguia um único comportamento: a API detectava automaticamente prefixos repetidos com pelo menos 1,024 tokens e cobrava metade do preço pela parte em cache. Foi por isso que classificamos a coluna do GPT como “totalmente automática” na nossa comparação entre provedores. O guia de caching do 5.6 substitui esse mecanismo por 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 relevantes, resumidas a partir do guia:
- Um breakpoint marca o fim de um prefixo em cache e inclui aquele bloco e tudo o que vier antes. O modo
implicit, usado por padrão, ainda adiciona automaticamente um breakpoint à mensagem mais recente. O modoexplicitarmazena somente o que você marcar. - São permitidas quatro escritas no cache por request. O breakpoint automático do modo implicit ocupa uma delas. Portanto, no modo padrão, sobram três posições para marcadores explícitos; no modo explicit, são quatro. Breakpoints de turnos anteriores da conversa ficam disponíveis apenas para leitura nos requests seguintes.
- O mínimo de 1,024 tokens continua valendo: um prefixo marcado abaixo desse limite não entra no cache.
ttl: "30m"garante um tempo de vida mínimo, não máximo: “pelo menos 30 minutos… pode ser mantido por mais tempo”. Esse parâmetro substituiprompt_cache_retention, agora deprecated no 5.6. Com isso, a antiga opção de retenção estendida por24htambém desaparece.prompt_cache_keyé necessário para obter correspondências confiáveis: o guia recomenda uma chave estável por tenant ou sessão para encaminhar repetições ao mesmo cache. Há um soft limit de aproximadamente 15 requests por minuto para cada chave. Os caches ficam restritos à sua organização.- Escritas no cache custam 1.25x a tarifa de input no 5.6 ou superior. A quantidade aparece no novo campo
usage.prompt_tokens_details.cache_write_tokens. Nas versões 5.x e anteriores, as escritas eram gratuitas.
O GPT-5.5 e as versões anteriores rejeitam os novos parâmetros com um 400 claro (prompt_cache_options is not supported on this model). Qualquer rollout deve validar a versão do modelo.
Esse desenho é conhecido: marcadores em blocos de conteúdo, quatro breakpoints, custo adicional de escrita e histórico deslizante disponível apenas para leitura. É o mesmo formato usado há tempos pelo cache_control do Claude. A diferença está no TTL: o mínimo garantido de 30 minutos da OpenAI é 6x maior que os 5 minutos padrão do Claude.
O que o medidor mostra
A documentação faz afirmações; abaixo estão os dados retornados pelo medidor do gateway em cada teste. Os registros brutos completos estão no log da execução. Todos os custos abaixo batem até o último dígito com as tarifas de cada tier.
| teste | resultado |
|---|---|
| escrita explícita, prefixo marcado com ≈3k tokens (Luna) | cache_write_tokens=3012, cobrados a $1.25/1M: exatamente o adicional de 1.25x |
| repetição com uma pergunta diferente | cached_tokens=3012, toda a parte marcada, a $0.10/1M; a chamada custou 90% menos que a chamada de escrita |
| adicional de escrita no Sol / Terra | $6.25 / $3.125 por milhão de tokens gravados: exatamente 1.25x em ambos |
| tarifa de cache no Sol / Terra | $0.50 / $0.25 por milhão: exatamente 10% do input |
| bloco marcado com 621 tokens, duas vezes | nunca entrou no cache: cache_write=0, cached=0, preço integral nas duas chamadas |
| bloco marcado com 1,221 tokens | gravado normalmente (1,212 tokens escritos) |
| dois breakpoints [A][B], depois alteração de B | cached=1212 (exatamente o bloco A) + cache_write=1210 (a nova parte final, a 1.25x) |
| cinco breakpoints em um request | aceitos sem erro, com todos os 5,548 tokens gravados (o limite de quatro escritas conta posições, não tokens; um marcador posterior cobre tudo o que vem antes) |
| prefixo gravado no Luna e reenviado ao Terra | cached=0, gravado novamente: os caches são separados por modelo |
| cache miss | também pode chegar com cache_write=0: preço integral, nada armazenado e nenhum erro |
Três dessas linhas exigem mais contexto.
O reaproveitamento parcial funciona e é o principal motivo para adotar breakpoints. Com um bloco A estável e uma parte final B substituída, o medidor cobrou novamente somente essa parte final: 1,212 tokens lidos pela tarifa de cache e 1,210 gravados para o novo B com o adicional de escrita, em um prompt de 2,431 tokens. O total bate até o último dígito com a tabela de preços. Esse é o comportamento de prefixos em camadas, system prompt, ferramentas e documentos, cada um marcado, usado por quem estrutura prompts para o Claude. O modo automático do GPT nunca conseguiu garantir isso. Há uma ressalva: em repetições completas, às vezes o tamanho correspondente fica abaixo do marcador. Em um teste, foram reaproveitados 1,897 tokens de uma escrita com 2,422. Faça estimativas com base na tarifa de desconto, não em contagens exatas de correspondência.
O limite mínimo e os misses silenciosos são os principais riscos operacionais. Um bloco marcado com 621 tokens não armazenou nada em nenhuma das duas chamadas. Não houve erro nem indicação em usage além dos zeros. Se o seu “prefixo estável” for um system prompt curto, você continuará pagando o preço integral sem nenhum aviso. Um miss também pode ocorrer sem escrita, igualmente em silêncio e pelo preço cheio. A taxa de acerto é uma distribuição, não uma garantia, independentemente do caminho percorrido pelos requests. Monitore cached_tokens em produção e crie alertas, como fazemos na nossa auditoria de cache de cinco minutos.
O adicional de escrita existe e altera o ponto de equilíbrio. Os tokens gravados custam exatamente 1.25x a tarifa de input nos três tiers. O medidor registra $1.25 por milhão de tokens escritos no Luna, $3.125 no Terra e $6.25 no Sol. Em todos os testes finais, os valores bateram até o último dígito. Esse custo adicional só se paga quando o prefixo é lido novamente. Uma escrita que nunca acerta o cache custa 25% mais do que não usar cache, o mesmo problema que medimos no custo de escrita do Claude no post sobre LangChain. Marque apenas prefixos que você sabe que serão repetidos, não tudo o que parece estável.
O mínimo de 30 minutos se manteve durante o período testado. Uma releitura com chave, feita 15 minutos após a escrita, veio totalmente do cache: 1,313 de 1,313 tokens, cobrados pela tarifa de 10%. Isso passa com folga do antigo intervalo em memória de 5 a 10 minutos. Um segundo teste com chave e o mesmo intervalo repetiu o resultado. Não testamos os 30 minutos completos.
A mesma carga no GPT-5.5, para comparação
A comparação justa mantém o mesmo preço: o Sol usa exatamente a tabela do gpt-5.5, $5/$30, portanto é seu sucessor direto. Terra e Luna são os tiers menores. O preço de tabela não mudou, mas as condições de caching são muito diferentes:
| gpt-5.5 | gpt-5.6-sol | |
|---|---|---|
| preço de tabela de input / output por 1M | $5.00 / $30.00 | $5.00 / $30.00 |
| tarifa de input em cache | 50% do input (documentado) | 10% do input (medido) |
| controle de cache | somente automático | automático + até 4 marcadores explícitos |
| duração | 5-10 min em best effort, retenção opcional de 24h | mínimo garantido de 30 min (com chave); opção de 24h removida |
| custo de escrita no cache | nenhum | 1.25x o input nos tokens gravados |
Com o mesmo preço de tabela, a melhoria está nas condições de caching. Um prefixo com 3,000 tokens custa $0.0075 por chamada no 5.5 quando o cache automático acerta, contra $0.0015 com o cache aquecido no Sol. A parte em cache fica 5x mais barata. A mudança mais profunda é o controle e a visibilidade: no 5.5, os acertos dependem de uma detecção opaca de prefixos que você não consegue acionar nem depurar. No 5.6, é possível marcar exatamente o que deve entrar no cache, encaminhar repetições com prompt_cache_key e acompanhar cada escrita em usage. Agora, um miss aparece como zero em um campo que você adicionou, em vez de não deixar sinal algum. Também é possível reduzir o tier: se o 5.5 oferecia capacidade acima do necessário, o Terra corta toda a tabela pela metade, e o Luna divide os preços por cinco. O mesmo prefixo aquecido cai para $0.00075 e $0.0003. A única vantagem mantida pelo 5.5 é a retenção opcional de 24 horas. Para um batch diário com um prefixo enorme, essa diferença pode favorecer o modelo antigo. Na migração, o segundo controle aumenta os custos: o 5.6 usa reasoning por padrão. Se uma carga do 5.5 for migrada sem fixar reasoning_effort, haverá um novo custo de output na mesma tabela de preços.
O segundo controle: reasoning effort
O caching determina quanto você paga pelo input. reasoning_effort controla o lado do output, porque tokens de raciocínio são cobrados pela tarifa de output e, ao contrário do prefixo, nunca podem entrar no cache. O GPT-5.6 aceita de none a xhigh em todos os tiers. O post de lançamento também apresenta um effort max para o Sol, mas ele não está disponível via chat completions: a API retorna 400: 'reasoning_effort' does not support 'max' with this model tanto no Sol quanto no Terra. Portanto, xhigh é o limite prático no caminho usado por gateways e SDKs.
Executamos uma matriz de 50 chamadas: quatro formatos de tarefa, classificar uma avaliação, extrair um campo de uma linha de log, resolver um problema aritmético em várias etapas e gerar um pequeno trecho de código, em todas as seis configurações, de none a xhigh, além do parâmetro omitido. Os testes rodaram no Terra e no Luna, com uma verificação pontual no Sol. Todas as 50 respostas estavam corretas em todas as configurações. O custo, porém, variou. Como são chamadas com output curto, de poucas dezenas de tokens visíveis, algumas dezenas de tokens de raciocínio cobradas pela tarifa de output dominam o total. A coluna de proporção compara o custo total da chamada:
| tarefa (Luna) | tokens de raciocínio em none | no padrão (omitido) | custo padrão vs none |
|---|---|---|---|
| classificação | 0 | 0 | 1.0x |
| extração | 0 | 0 | 1.0x |
| matemática | 0 | 24 | 3.5x |
| código | 0 | 39 | 2.5x |
Três conclusões. Primeiro, o 5.6 se adapta sozinho: nas duas tarefas triviais, nenhuma configuração consumiu sequer um token de raciocínio. Nesses casos, o controle não tem custo. Segundo, nas tarefas que parecem exigir reflexão, matemática e código, o padrão usa reasoning mesmo sem melhorar o resultado. Omitir o parâmetro custou de 2.5x a 3.5x o preço de none nas tarefas de matemática e código do Luna e na tarefa de matemática do Terra. A execução de código no Terra não consumiu reasoning no padrão. As respostas continuaram corretas, e o total da grade Terra e Luna ficou 1.5x mais caro. Terceiro, as configurações intermediárias, não exibidas na tabela, se comportam mais como ruído do que como um controle gradual: na execução de matemática do Terra, foram 19 tokens de raciocínio em low, zero em medium, 21 em high e novamente zero em xhigh. No código do Luna, foram 101 tokens em xhigh, contra 41 em high. Os nomes representam intenções, não limites de orçamento. Medimos o mesmo comportamento no GLM 5.2.
Envie reasoning_effort explicitamente em todas as chamadas e use none como padrão para classificação, extração, roteamento e transformações curtas. Aumente o nível em um ponto específico apenas quando seus evals mostrarem uma mudança no resultado, não porque a tarefa parece difícil. Nossos quatro formatos representam workloads de API com output curto. Trabalhos realmente difíceis e com várias etapas podem justificar esse custo, mas a decisão deve vir das medições.
Os dois controles se acumulam. Depois que um prefixo aquece, o input de uma chamada no Luna custa um décimo do preço de tabela. Em tarefas curtas, o reasoning padrão passa a ser o maior item restante: a chamada de matemática no Luna custou $0.00007 no total com none e $0.00025 com o parâmetro omitido. Só o padrão de reasoning adicionou $0.00018, mais do que o dobro do custo total da chamada controlada. Se você ativar cache sem fixar o effort, a economia reaparece como gasto no outro lado.
O que recomendar para cada workload
A decisão agora tem critérios claros. Estas são as recomendações que damos aos clientes do gateway:
| formato da carga | recomendação |
|---|---|
| chat, com um grande system prompt estável | mantenha implicit; o breakpoint automático resolve o caso, e o desconto é de 90% nos dois modos |
| agentes com prefixos em camadas (sistema + ferramentas + arquivos) | use o modo explicit, marque cada camada estável e deixe o conteúdo volátil por último; uma camada alterada só é cobrada novamente a partir do próprio marcador |
| RAG com contexto reordenado | use marcadores explícitos nas camadas anteriores aos trechos recuperados; assim, a reordenação cobra apenas a parte final |
| jobs via cron ou esporádicos, com intervalos de 10-30 min | o mínimo de TTL de 30m atende exatamente a esse caso, no qual a geração 5.x e os 5m padrão do Claude nunca acertavam; nos nossos testes, releituras com chave após 15 minutos vieram totalmente do cache |
| prompts curtos (<1,024 tokens) | o caching não se aplica; não perca tempo adicionando marcadores |
Independentemente do formato, envie um prompt_cache_key estável por tenant ou sessão. Segundo a documentação, a chave é a base para correspondências confiáveis. Mantenha cada camada marcada acima do mínimo de 1,024 tokens e monitore cached_tokens, porque misses silenciosos acontecem. Os caches são separados por modelo: em um teste A/B entre tiers, cada lado começa com o cache vazio. Configure o outro controle no mesmo commit: defina reasoning_effort conforme a matriz acima, usando none a menos que um eval indique o contrário.
Na escolha do tier, o desconto de 90% altera mais os cálculos do que a diferença entre tiers. Uma carga que repete um prefixo de 3,000 tokens paga cerca de $0.30 por mil chamadas no Luna com cache aquecido, contra $1.50 no Sol. A diferença entre tiers na parte em cache é menor do que a diferença nos tokens de output. Escolha o tier pela qualidade e pelo preço do output; o caching reduz o impacto do input. Para quem vem do gpt-5.5, o Sol é o upgrade direto com a mesma tabela, cache reads 5x mais baratas e controle sobre quando elas acontecem. Reduza para Terra ou Luna quando seus evals mostrarem que o tier menor mantém a qualidade. Além da economia de cache, a tabela cai pela metade ou é dividida por cinco.
O tokenizer não mudou
Nossas 24 amostras, um texto narrativo em nove idiomas, versões técnicas e jornalísticas em seis deles, uma função Python e uma chamada de ferramenta em JSON, tiveram contagens idênticas no GPT-5.5, Sol, Terra e Luna em todas as comparações concluídas. Orçamentos de tokens e estimativas do mínimo necessário para cache, calibrados no 5.5, continuam válidos sem ajustes. O comportamento entre idiomas está no nosso post sobre tokenizers por idioma e se aplica ao 5.6 sem mudanças.
Conclusão
- O aumento do desconto de cache de 50% para 90%, junto ao TTL mínimo garantido de 30 minutos, é o verdadeiro corte de preço desta versão. Os preços dos tiers chamam atenção, mas as condições de caching têm mais impacto na fatura.
- Use breakpoints explícitos em prompts organizados por camadas. O reaproveitamento parcial foi medido, não é apenas teórico, e o modelo mental do Claude se aplica diretamente.
- Respeite o mínimo de 1,024 tokens, envie um
prompt_cache_keye monitorecached_tokens. Há tanto misses silenciosos quanto casos em que nada entra no cache sem aviso. - Envie
reasoning_effortexplicitamente e usenonecomo padrão. O padrão não controlado custou 1.5x mais na nossa matriz e até 3.5x em tarefas individuais, com respostas idênticas. xhighé o limite disponível;maxretorna 400 via chat completions. Não é necessário recalibrar o tokenizer em relação ao 5.5.
FAQ
O GPT-5.6 oferece prompt caching explícito como o Claude?
Sim. Use prompt_cache_options: {"mode": "explicit"} com marcadores prompt_cache_breakpoint nos blocos de conteúdo. São permitidas até quatro escritas por request, ou três no modo implicit, em que o breakpoint automático ocupa uma posição. Em medições feitas por um gateway compatível com OpenAI, um prefixo marcado com 3,012 tokens foi gravado na primeira chamada e lido integralmente pela tarifa de cache na segunda.
Quanto custa o input em cache no GPT-5.6? 10% da tarifa de input, conforme medido nos três tiers: $0.10 por milhão no Luna, $0.25 no Terra e $0.50 no Sol. No GPT-5.x, os tokens em cache custavam 50% da tarifa de input. Portanto, a tarifa de tokens em cache é 5x menor no 5.6.
O caching do GPT-5.6 é melhor que o do GPT-5.5? Em desconto e controle, sim: tarifa de cache de 10% em vez de 50%, quatro breakpoints explícitos em vez de uma detecção exclusivamente automática que não pode ser acionada nem depurada, e um mínimo de 30 minutos com chave em vez de 5-10 minutos em best effort. A única vantagem restante do 5.5 é a retenção opcional de 24 horas, removida no 5.6.
Por quanto tempo o cache do GPT-5.6 permanece disponível?
A documentação garante pelo menos 30 minutos. ttl: "30m" é o único valor aceito, e o cache pode durar mais. A opção substitui o deprecated prompt_cache_retention, inclusive o antigo tier estendido de 24 horas. Nos nossos testes, releituras com chave feitas 15 minutos após a escrita vieram integralmente do cache. Não testamos os 30 minutos completos.
Preciso usar prompt_cache_key?
Envie-o. A documentação define uma chave estável por tenant ou sessão como base para correspondências confiáveis no 5.6, com um soft limit de aproximadamente 15 requests por minuto para cada chave. Incluí-la não custa nada. Em conjunto com o monitoramento de cached_tokens, ela permite verificar se o desconto realmente está 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, todas as configurações produziram respostas corretas. Omitir o parâmetro custou 1.5x mais do que usar none no total e chegou a 3.5x na tarefa de aritmética. Nas tarefas triviais, classificação e extração, nenhuma configuração consumiu tokens de raciocínio. Fixe none e aumente o nível somente com base em evals.
O nível máximo de reasoning está disponível no GPT-5.6 Sol?
Não via chat completions. Requests com reasoning_effort: "max" retornam um 400 que lista as opções de none a xhigh, tanto no Sol quanto no Terra.
Qual tier do GPT-5.6 uma carga de API deve usar? Sol é o sucessor do gpt-5.5 com o mesmo preço: tabela idêntica de $5/$30 e cache reads 5x mais baratas. Terra e Luna são os tiers menores, a metade e um quinto desse preço. Quando o prefixo está estável e usa uma chave, o desconto de cache de 90% reduz o peso do input. Desça de tier até o limite permitido pelos seus evals de qualidade de output e deixe o tier determinar o preço do output.
Outros guias desta série com custos medidos: custo de transcrição de áudio em sete modelos de ASR, custo de geração de imagens e preços de voz do GPT Realtime.