Guia de Prompting do GPT-5.6: Dois Defaults que Cobram 1,5x e 10x a Mais

Fazer prompting bem no GPT-5.6 se resume a dois parâmetros de request, e ambos vêm com o default mais caro. Omitir o reasoning_effort cobrou 1,5x mais do que fixá-lo em "none" na nossa matriz de 50 chamadas, com respostas idênticas; deixar um prefixo estável sem marcação faz cada chamada custar 10x a taxa de leitura em cache. Este guia é o playbook de request que sai das medições do nosso guia de custos do GPT-5.6: como é um request bem formado, como ajustar o nível de esforço por tarefa, como estruturar um prompt para o cache trabalhar a favor e o que quebra ao portar prompts do GPT-5.5.

TL;DR

• Fixe o reasoning_effort em todo request do GPT-5.6: omiti-lo cobrou 1,5x mais que "none", com respostas idênticas na nossa matriz de 4 tarefas.
• Os esforços aceitos vão de none a xhigh; "max" retorna 400 tanto no Sol quanto no Terra.
• Marque prefixos estáveis com cache breakpoints explícitos: leituras em cache custam 10% da taxa de input, escritas 1,25x. Marque o que se repete, não o que apenas parece estável.
• prompt_cache_options e breakpoints retornam 400 no GPT-5.5 e anteriores; controle o rollout por versão.

Como deve ser um request do GPT-5.6?

Comece por este formato e apague o que não precisar. Ele fixa as duas alavancas de forma explícita em vez de herdar os defaults caros:

{
  "model": "gpt-5.6-terra",
  "reasoning_effort": "low",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    { "role": "system", "content": "…stable instructions…",
      "prompt_cache_breakpoint": { "mode": "explicit" } },
    { "role": "user", "content": "…the part that changes per request…" }
  ]
}

A regra de ordenação por trás disso: tudo que é estável vem antes do breakpoint, tudo que muda a cada request vem depois, e nada dinâmico (timestamps, nomes de usuário, documentos recuperados que diferem por chamada) fica dentro do bloco marcado, porque um único byte alterado recobra o bloco pelo prêmio de escrita de 1,25x. O prompt_cache_key roteia as repetições para o mesmo cache; use uma chave estável por tenant ou sessão, e lembre do soft limit documentado de cerca de 15 requests por minuto por chave.

Como configurar o reasoning_effort?

Explicitamente, sempre: a única configuração a evitar é não configurar nada. Nas nossas medições, requisições sem reasoning_effort custaram 1,5x mais do que requisições fixadas em "none", e as respostas foram idênticas em toda a matriz. Os valores aceitos são none, low, medium, high, xhigh; "max" é rejeitado com um 400 listando o intervalo válido. O que o ajuste rendeu na nossa verificação matemática de uma linha, na Luna:

A GPT-5.6 foi a única família no nosso estudo de anatomia do uso de tokens que continuou acertando com o thinking totalmente desligado nessa verificação, o que torna none um default defensável para extração, classificação, formatação e chamadas com formato de retrieval. Quando ela raciocina, os tokens são invisíveis e cobrados à taxa cheia de output: 88% do custo de output no exemplo matemático com a configuração default foi chain of thought que você não pode ler. Suba o ajuste quando os seus evals disserem que a tarefa precisa, não porque o default já gastou por você.

Como estruturar um prompt para que o cache compense?

Organize o prompt em camadas por ordem de estabilidade e marque as camadas: primeiro as instruções de sistema, depois as definições de tools, depois os documentos de referência, cada uma terminando num breakpoint, e o turno volátil do usuário depois da última marca. Você tem quatro escritas de cache por requisição; no modo implícito default, um breakpoint automático na última mensagem consome uma delas, então o modo explícito te dá as quatro completas e, mais importante, faz cache apenas do que você marca.

O ganho está no reuso parcial, e ele é mensurável. Com um bloco estável A e uma cauda B trocada, o medidor recobrou apenas a cauda: 1.212 tokens lidos de volta à taxa de cache, 1.210 escritos do zero à taxa premium, de um prompt de 2.431 tokens, batendo com a tabela de preços até o último dígito. Daí saem três regras de orçamento:

• Leituras custam 10% da taxa de input, então um prefixo em camadas quente achata o lado de input da conta.
• Escritas custam 1,25x, então um bloco marcado que nunca é lido de novo custa 25% a mais do que não fazer cache. Marque o que se repete, não tudo que parece estável.
• Em repetições completas, o comprimento correspondido pode cair abaixo da marca (1.897 em cache de uma escrita de 2.422 tokens num teste), então faça o orçamento pela taxa de desconto, não pela contagem exata de correspondências; o nosso estudo de mínimos de cache tem os pisos por família.

O piso ttl: "30m" é um mínimo garantido, não um teto, e é 6x os 5 minutos default da Claude; não existe mais um tier de 24 horas, então workloads de batch diário que dependiam de retenção estendida devem refazer o cálculo de break-even.

O que quebra ao portar prompts da GPT-5.5?

Duas coisas quebram de forma barulhenta e uma em silêncio. Barulhentas: prompt_cache_options e prompt_cache_breakpoint retornam um 400 limpo na GPT-5.5 e anteriores (prompt_cache_options is not supported on this model), então qualquer prompt-builder compartilhado precisa de um gate por versão. Também barulhento: o effort "max", que algumas configs da 5.5 carregavam, é rejeitado.

Em silêncio, e mais caro: a GPT-5.6 raciocina por default, enquanto um workload da 5.5 pode ter tido o reasoning desligado. Um prompt portado que nunca define reasoning_effort herda a taxa de omissão de 1,5x na mesma tabela de preços. A migração de cache vai no sentido contrário: a detecção automática de prefixo da 5.5 não precisava de marcação, mas não podia ser acionada nem depurada; na 5.6 o mesmo prompt não faz nada até você marcá-lo, e aí reporta cada escrita em usage.prompt_tokens_details.cache_write_tokens, onde um miss aparece como um zero num campo que você criou, em vez de silêncio.

Em qual tier rodar o prompt?

O mesmo formato de request roda nos três tiers, então a escolha do tier é uma decisão de preço, não de prompting: Sol a $5/$30 por milhão de tokens, Terra pela metade, Luna por um quinto. Depois que o prefixo está estável, com key e aquecido, o desconto de leitura cacheada nivela o lado do input em todos os tiers, e o preço de output passa a ser o diferenciador; desça o máximo que suas evals de qualidade de output permitirem. A aritmética completa dos tiers, incluindo o break-even do prêmio de escrita por tier, está no guia de custos.

FAQ

O GPT-5.6 suporta reasoning_effort: “max”?

Não. Requests com "max" retornam 400 listando de none até xhigh como valores válidos, tanto no Sol quanto no Terra. Workloads que quiserem o teto devem enviar xhigh explicitamente.

Os breakpoints de cache funcionam no GPT-5.5?

Não. O GPT-5.5 e versões anteriores rejeitam prompt_cache_options e marcadores de breakpoint com 400. Nesses modelos você volta à detecção automática de prefixo, que não dá para acionar, associar a key nem debugar; trate o comportamento de cache como best-effort ali e coloque um version-gate em qualquer prompt builder que emita os novos campos.

Quantos breakpoints um prompt deve usar de fato?

Quantas camadas realmente se repetirem, até o limite do budget: quatro escritas por request, uma delas consumida pelo auto-breakpoint implícito, a menos que você mude para o modo explícito. Um prompt em camadas típico precisa de dois ou três (instruções, tools, bloco de referência), e um quinto marcador é aceito sem erro, mas apenas divide os slots de escrita, já que uma marca posterior cobre tudo o que veio antes dela.

Todos os números deste guia foram medidos através do gateway da Synthorai nos modelos GPT-5.6 do dia do lançamento e batem com o medidor usage.cost ao vivo; a metodologia e as sondagens brutas estão no guia de custos e no estudo dos mínimos de cache. Verifique contra seus próprios registros de uso; as taxas e os valores aceitos podem mudar.

← Voltar ao blog