No dia 2 de outubro de 2026, a OpenAI publicou A model guide for the GPT-6 family, um guia prático voltado para quem está construindo em cima da família GPT-6. O documento explica como escolher um modelo GPT-6, dar instruções efetivas, administrar trabalho de longa duração e preparar para produção. É menos anúncio de modelo e mais manual de uso: ensina a decidir entre Astra, 6.1 Sol e Luna, a ajustar o reasoning effort por tarefa, e a coordenar ferramentas.
Este artigo passa pelo mecanismo descrito no guia e na documentação da API, mostra onde a coisa quebra e aponta um caminho para você testar.
Os três modelos da família e o que diferencia um do outro
A família GPT-6, hoje, tem três cartas na mesa, com preços e posicionamentos distintos. GPT-6 Astra é o modelo mais inteligente para melhores resultados, a 10 dólares de input, 50 de output e 1 dólar de input em cache; GPT-6.1 Sol tem inteligência próxima da Astra por um quinto do preço, a 2 dólares de input, 10 de output e 0,10 de cache; GPT-6 Luna é rápido e eficiente para trabalho diário em escala, a 0,10 de input, 0,50 de output e 0,01 de cache (todos por milhão de tokens).
O posicionamento de cada um, segundo o próprio guia e a documentação de prompting:
- Astra: reservado para o trabalho de raciocínio mais difícil, que exige inteligência máxima. É o modelo que você paga para errar menos.
- 6.1 Sol: projetado para coding complexo, pesquisa e tarefas de uso de computador. É o cavalo de trabalho para agentes.
- Luna: foca em tarefas repetidas e em escala, como extrair campos de notas fiscais ou classificar requests.
Vale notar: todos os três compartilham uma janela de contexto de 1.050.000 tokens, até 128.000 tokens de output, suporte a imagens, Structured Outputs, computer use, code tools, MCP, web search, file search e outras ferramentas hospedadas. Trocar entre eles muda custo e capacidade de raciocínio, não o formato de entrada.
O que é reasoning effort e como ele muda o comportamento do modelo
Antes de entrar no mecanismo, uma analogia útil. Imagine que você pede para alguém revisar um contrato. Você pode dizer “dá uma olhada rápida” ou “senta e lê linha por linha”. O conteúdo que você entrega é o mesmo, mas o tempo gasto e a profundidade da análise mudam. Reasoning effort é esse controle, aplicado ao modelo, separado do que você escreve no prompt. A analogia quebra num ponto importante: a pessoa decide sozinha quando parar, o modelo não. Você precisa escolher o nível antes.
No mecanismo real, o parâmetro reasoning_effort controla quanto o modelo pensa antes de responder, e os valores suportados variam por modelo, incluindo none, minimal, low, medium, high, xhigh e max. Nem todo modelo aceita todos os valores:
- GPT-6 Astra não suporta reasoning effort none; definir reasoning.effort (Responses) ou reasoning_effort (Chat Completions) como none retorna HTTP 400.
- GPT-6.1 Sol não suporta none nem minimal e tem padrão medium.
- GPT-6 Sol e GPT-6 Luna suportam none.
Existe também uma distinção que o guia faz questão de separar: modo e esforço. Reasoning mode e reasoning effort são independentes. O modo seleciona execução standard ou pro, enquanto reasoning.effort controla quanto raciocínio o modelo aplica dentro daquele modo. Em outras palavras, modo é o onde o modelo roda, esforço é o quanto ele pensa.
Como isso aparece em código
const response = await client.responses.create({
model: "gpt-6-astra",
reasoning: {
effort: "high"
},
input: prompt
});
Esse é o padrão da Responses API. A documentação recomenda usar Responses: Astra e 6.1 Sol suportam Chat Completions, mas tool calling exige Responses. Se você está construindo agente, essa decisão é feita por você: Responses ou nada.
Caching, compaction e o que acontece com contexto longo
Dois mecanismos ajudam a manter custo e coerência sob controle em sessões longas. Para rodar efetivamente em produção, use caching e compaction para administrar contexto e custo. Caching aproveita o prefixo repetido entre chamadas (daí os preços de “cached input”, bem menores). Compaction comprime conversas longas para o modelo não precisar reconstruir contexto do zero a cada volta.
Um detalhe importante quando o agente muda de esforço durante uma sessão: se sua aplicação muda effort entre respostas, use itens configuration_update em requests padrão single-agent, e mantenha o reasoning.effort de nível de request inalterado para preservar o prefixo do prompt para caching. Mudar effort no lugar errado quebra o cache e você paga preço cheio.
O que isso significa na prática: montando um roteador por tarefa
A pergunta operacional que esse guia tenta responder não é “qual é o melhor modelo”. É “qual modelo para qual tarefa, a que esforço, com que fallback”. Um roteador útil, baseado no que o guia e documentações relacionadas sugerem:
- Luna, effort low ou none: classificação de ticket, extração de campos de documento, normalização de registros. Tarefa estreita, critério de sucesso claro, volume alto.
- 6.1 Sol, effort medium: tarefa com várias etapas dependentes, uso de ferramenta, contexto ambíguo. É o default razoável.
- Astra, effort high ou xhigh: debug difícil, planejamento complexo, trabalho onde errar sai caro.
Quando eu construí uma extensão de navegador que escrevia direto num CRM, aprendi na marra que escolher o modelo é só metade do problema. Na falha o sistema tenta de novo com prompt corretivo, depois cai para rascunho sinalizado para revisão humana, nunca escrita parcial. Chamada de API bem sucedida não diz nada sobre o payload fazer sentido. Vale para qualquer modelo da família: um Astra com reasoning max ainda pode retornar JSON válido com conteúdo errado. O que te protege é a validação depois da chamada, não o preço do token antes.
Um esqueleto de router
function pickModel(task) {
if (task.type === "classify" || task.type === "extract")
return { model: "gpt-6-luna", effort: "low" };
if (task.type === "agent_step" || task.type === "code_edit")
return { model: "gpt-6.1-sol", effort: "medium" };
if (task.type === "deep_debug" || task.type === "plan")
return { model: "gpt-6-astra", effort: "high" };
return { model: "gpt-6.1-sol", effort: "medium" }; // default
}
Isso é um ponto de partida, não uma receita. O ajuste real sai de rodar o mesmo conjunto de tarefas de produção pelos três e medir.
Onde isso quebra
Alguns pontos em que vale ter cuidado:
- Chat Completions com tool calling: Chat Completions não suporta function calling com GPT-6 Astra ou GPT-6.1 Sol. Se seu código legado chama Chat Completions e espera function calling, ele não vai funcionar com os modelos de topo. Migre para Responses.
- Parâmetros antigos de amostragem: o guia de migração da OpenAI diz que quando reasoning effort não é none, parâmetros como temperature, top_p e top_logprobs devem ser removidos. Como 6.1 Sol não suporta none, você não deve passar esses controles.
- Mudar effort errado quebra cache: já comentado acima, mas repito porque custa dinheiro.
- Latência de reasoning alto: effort high, xhigh e max geram muito token de reasoning invisível antes da resposta. Em UX interativo, isso é percebido como lentidão. Para batch e async, não importa.
- Validar antes de escrever custa: validar antes de escrever custa latência e obriga a desenhar o que fazer quando o modelo insiste em errar. Não é opcional em escrita em sistema de terceiro.
O que não dá para afirmar a partir deste material
Só consegui capturar o resumo e o TL;DR do guia da OpenAI diretamente, o restante vem da documentação da API, de referências do Microsoft Foundry e de guias de prompting de terceiros. Por isso evito afirmar como funciona por dentro:
- O que exatamente é “mid-turn steering” e como ele se comporta em erro. O guia menciona, mas o resumo não detalha.
- Como funciona a delegação multi-agente na prática: 6.1 Sol suporta workflows multi-agente que delegam subtarefas independentes para subagentes, atualmente em beta, mas beta significa que a interface pode mudar.
- O comportamento real de Fast e Ultrafast em throughput sustentado. Ultrafast mode acelera a geração de tokens independentemente do reasoning effort e está disponível para GPT-6 Astra em Codex e na API, mas não testei números.
- Se o roteador que sugeri acima bate com os seus dados. Não bate até você medir.
Como testar isso você mesmo
Um caminho pequeno para começar:
- Pegue 20 a 50 exemplos reais do seu fluxo, com critério de sucesso definido por humano.
- Rode o mesmo prompt nos três modelos (Luna, 6.1 Sol, Astra), em effort low, medium e high onde suportado.
- Para cada combinação, registre: acerto, latência, tokens de input, tokens de output, erros de ferramenta.
- Monte uma tabela e escolha o menor combo (modelo + effort) que passa seu critério de sucesso em pelo menos 95 por cento dos casos. Esse é seu default.
- Para os 5 por cento restantes, defina um fallback explícito: subir de modelo, subir de effort, ou cair para revisão humana.
É um protocolo chato e manual, e é o único jeito honesto de escolher. Preço e marketing de modelo não decidem isso por você.
