Como usar o GPT-6 Sol em tarefa difícil: estruture o ciclo de tentativas em vez de pedir tudo de uma vez

Despejar a feature inteira num prompt só e torcer é o jeito mais caro de descobrir que o modelo entendeu outra coisa

Fala aí, beleza? A OpenAI soltou em 22/09/2026 o GPT-6 Sol e o GPT-6 Luna, levando os avanços do GPT-6 Astra pra versões mais rápidas e mais baratas

E o Sol veio com um posicionamento bem específico: "Built to power complex coding and agentic workflows"

A própria OpenAI enquadra o modelo como algo que te dá mais espaço pra iterar em trabalho difícil, por causa dos limites de uso maiores e do custo menor

Repara no verbo: iterar

Não é "acerta de primeira", é "você tem mais rodadas disponíveis". Então a habilidade que passa a valer dinheiro é saber ESTRUTURAR essas rodadas, e é isso que a gente monta aqui 🙂

O que você precisa antes de começar

Primeiro, onde o bicho vive hoje

GPT-6 Sol e Luna estão no ChatGPT Work e no Codex para usuários Plus, Pro, Business, Enterprise e Edu. Nenhum dos dois está no Chat ainda, e o rollout é gradual ao longo do dia, então pode não aparecer pra você na hora

Se não apareceu, é espera mesmo, nada de sair reinstalando app. Isso é um problema bem diferente de quando o ChatGPT trava de vez, que tem solução própria

No GitHub Copilot a divisão é por plano: GPT-6 Sol nos planos Pro+, Max, Business e Enterprise; GPT-6 Luna em Pro, Pro+, Max, Business e Enterprise

Qual modelo escolher no Codex:

A recomendação oficial é direta: nos planos Plus, Pro, Business, Enterprise e Edu, escolha gpt-6-sol quando disponível

Pra maioria das tarefas no Codex, comece com o Sol, que é o mais forte pra trabalho ambíguo e multi-etapas, aquele que exige planejamento, uso de ferramentas, validação e acompanhamento em contexto maior

O contexto ajuda nisso: 1.050.000 tokens de janela, 128.000 tokens de saída máxima e knowledge cutoff em 20/04/2026

Trocando modelo e esforço no CLI:

Dentro de uma sessão interativa você usa /model pra trocar o modelo ou ajustar o reasoning effort

E dá pra já abrir escolhendo, com --model ou o alias -m:

codex exec -m gpt-6-sol "Review the current changes"

Os níveis aceitos pelo reasoning.effort do Sol são: none, low, medium (padrão), high, xhigh e max

E se você for pela API, tome cuidado com uma restrição chata: use a Responses API pra ferramentas nativas e function calling. A Chat Completions só suporta function calling com reasoning_effort definido como none

Ou seja, tentar raciocínio alto + function calling no endpoint errado não vai rolar

Como montar o ciclo de tentativas passo a passo

A orientação oficial do Codex pra trabalho complexo é bem pé no chão: quebre em passos menores e focados, porque tarefa menor é mais fácil de o Codex testar e de VOCÊ revisar

E tem a segunda metade, que quase todo mundo pula: o Codex produz saída de mais qualidade quando consegue verificar o próprio trabalho

Sem meio de verificação, o ciclo vira achismo. Bora montar?

1. Crie o arquivo de instruções do projeto com /init

O comando /init cria um AGENTS.md com instruções pro Codex. É ali que mora o que NÃO muda entre as rodadas: stack, convenções, o que é proibido mexer, como rodar os testes

O erro comum deste passo: escrever o AGENTS.md depois da primeira frustração, já com o contexto poluído. Escreva antes do primeiro prompt grande

2. Use /plan antes de tocar no código

/plan

Ao usar /plan o Codex entra em plan mode e trata o prompt inline opcional como o primeiro pedido de planejamento. O plan mode é nativo no app, no CLI e na extensão de IDE, e serve exatamente pra quebrar uma tarefa maior numa sequência revisável de passos antes de mexer no código

E se você não souber como dividir? Peça pro Codex propor o plano, isso é orientação oficial também

O erro comum deste passo: aprovar o plano no automático. Plano ruim aprovado rápido é só um erro mais caro lá na frente

3. Ache (ou escreva) o comando que pontua a saída atual

A receita oficial do Codex pra iterar em problema difícil começa assim: antes de começar, ler o AGENTS.md e achar o script ou comando que pontua a saída atual

Pode ser sua suíte de testes, um lint, um script de eval do projeto:

./scripts/eval.sh

Registre o score inicial. Sem número inicial, você não tem delta, e sem delta você não tem ciclo, tem conversa

O erro comum deste passo: aceitar "parece melhor" como métrica. Não é

4. Uma melhoria focada por vez, e re-rodar o eval

O loop oficial é esse: fazer uma melhoria focada por vez, re-rodar o comando de eval após cada mudança relevante e registrar os scores e o que mudou

E inspecionar os artefatos gerados diretamente, não só olhar o resumo bonitinho que o agente escreveu

O erro comum deste passo: empilhar três mudanças na mesma rodada. Aí o score mexeu e você não sabe qual delas mexeu

5. Revise com /review e confira o diff

/review

O /review abre os presets de revisão do CLI e inicia um revisor dedicado, que lê o diff selecionado e reporta achados priorizados e acionáveis SEM alterar a working tree

Isso é ouro no ciclo: separa "olhar" de "mexer". Depois você usa /diff pra inspecionar as mudanças exatas de arquivo

O erro comum deste passo: deixar o mesmo agente revisar e já corrigir no mesmo fôlego, e você perde a chance de julgar o achado antes da edição

6. Feche a rodada com o log

A saída esperada do loop é bem definida: melhores scores atuais, log das iterações principais e riscos ou pontos fracos restantes

Parece burocracia, mas é o que te deixa retomar amanhã sem reabrir a investigação do zero

O erro comum deste passo: fechar a sessão com tudo na cabeça. Contexto que só existe no chat morre com o chat

Outros comandos de barra que valem conhecer no CLI: /feedback, /goal, /init, /mcp, /plan, /review e /status. No composer, digita / e vai filtrando

O que manter fixo entre as iterações (e o que pode variar)

Ciclo de tentativas só funciona se a maior parte das variáveis ficar PARADA

Se tudo muda a cada rodada, você não está iterando, está sorteando

O que fica fixo:

• o critério de sucesso (qual número precisa subir, e até quanto)
• o comando de eval (mesmo script, mesma forma de rodar)
• o AGENTS.md
• o escopo da rodada
• o plano autocontido

Sobre o plano: existe um padrão de ExecPlan (um PLANS.md) pensado pra trabalho de várias horas. A ideia é que seja um documento de design que o agente de código segue pra entregar a feature, tratado como documento VIVO, que você verifica antes de o Codex começar a implementação longa

E tem uma regra de escrita que muda tudo: trate o leitor como alguém totalmente novo no repositório, que só tem a working tree atual e aquele único arquivo de plano, sem memória de planos anteriores e sem contexto externo

Esse material de ExecPlan foi escrito em cima do Codex com o modelo gpt-5.2-codex

O que pode variar:

• a mudança focada daquela rodada
• o nível de reasoning.effort

E aqui vai o alerta honesto, porque eu vi gente já confundindo: existe um item de input chamado configuration_update, que deixa subir o esforço pra trabalho difícil ou baixar pra follow-up de rotina mantendo o reasoning.effort de nível de requisição inalterado e preservando o prefixo em cache

Esse recurso é suportado apenas pelo GPT-6 Astra (gpt-6-astra) em modo padrão single-agent

Não vale pro Sol. Então, no Sol, mexer no esforço é mexer no esforço, sem o truque de preservar cache

E pra conversa que estica demais, a Responses API tem mecanismos de compactação de contexto: dá pra ligar compactação server-side numa requisição de create passando context_management com compact_threshold, e existe o endpoint standalone /responses/compact, que devolve uma janela compactada pra você mandar como input no lugar do transcript inteiro

O que aconteceu quando eu rodei esse ciclo na geração anterior

Aviso antes, pra ninguém se confundir: o teste que eu fiz foi na geração ANTERIOR, com o GPT-5.6 Sol contra o Fable 5, e não na leva nova. Mas a parte que interessa aqui, a estrutura do ciclo, é a mesma

No vídeo eu mostro que dividi o projeto em 3 etapas e mandei um prompt por etapa, em vez de pedir o sistema inteiro de uma vez: primeiro a landing page, depois autenticação e sistema base, depois outra parte

Rodei o mesmo prompt da primeira etapa nos dois modelos, com reasoning no máximo, pra comparar em igualdade de condições

O Sol terminou a landing page em 11 minutos e eu já consegui pedir pra iniciar o projeto

O Fable passou de 20 minutos ainda rodando a mesma etapa, inclusive fazendo testes extras antes de entregar, e travou e errou um comando na hora de criar a estrutura de pastas, o que atrasou ele

Durante esse teste com o Sol, minha cota caiu de 100% pra 83%

Detalhe divertido: vi o GPT gerando imagens automaticamente pra usar como foto de cliente fictício na landing, e o Sol rodando dois subagents em paralelo. E teve o clássico: ele tentou subir o projeto na porta 3000, que já estava ocupada por outro projeto meu, e eu tive que pedir pra trocar de porta 😀

Agora a parte que eu quero que fique: nenhum dos dois entregou rápido de verdade

Isso mostra o problema dos reasonings mais altos, nem sempre compensa esperar tanto. No meio do teste eu baixei o reasoning effort dos dois só pra conseguir terminar o vídeo

Eu, pessoalmente, não uso muito o extra high no dia a dia, prefiro o nível alto porque sai mais rápido e eu não sinto diferença de qualidade

E quanto custa iterar assim?

Aqui o Sol muda a conta, porque o preço caiu pela metade em relação ao GPT-5.6 Sol nas duas pontas

A escrita de cache do Sol é US$ 2,50 por 1M em contexto curto, e US$ 5,00 na faixa longa

Repara no que isso premia: prefixo estável entre as rodadas. Se o AGENTS.md e o plano ficam parados e só a mudança da rodada varia, você paga entrada em cache no que repete

E presta atenção na faixa longa, porque prompts acima de 272K tokens de entrada são cobrados a 2x nas taxas de entrada e cache e 1,5x na saída, pra requisição INTEIRA. Não é só o excedente

Ou seja, deixar o transcript inchar não é só ruim pra qualidade, é caro. É a mesma lógica de olhar o custo por tarefa resolvida em vez do preço por token cru

Quando parar de insistir e mudar a abordagem

Essa é a parte que separa ciclo de teimosia

O loop de reparo iterativo tem três fases bem definidas: Review (inspecionar o artefato atual e devolver achados estruturados sem editar arquivos), Repair (aplicar edições focadas usando os achados e o feedback de validação mais recente) e Validate (rodar as checagens e reportar o que ainda falta)

E o sinal que importa NÃO é o agente ter editado alguma coisa

O sinal é o delta de validação restante diminuir a cada rodada

Um bom loop costuma parar por um de quatro motivos:

1. A validação passou, e acabou
2. O loop atingiu o número máximo de tentativas que você definiu antes de começar
3. O delta restante parou de mudar, ou seja, três rodadas e o mesmo número teimoso na tela
4. A próxima decisão precisa de revisão humana, porque virou escolha de arquitetura, não de implementação

E duas restrições da receita oficial que eu acho que quase ninguém segue:

Não pare no primeiro resultado aceitável

E não volte pra uma versão anterior a menos que o novo resultado seja claramente PIOR em scores ou artefatos. Aquele reflexo de dar git checkout . no primeiro susto costuma jogar fora progresso real

Se o eval melhorou mas ainda está abaixo da meta, a orientação é explicar o gargalo e continuar. Explicar, não só continuar

E o realismo sobre o modelo:

No anúncio, o GPT-6 Sol marcou 64,6% no SWE-bench Pro. No mesmo recorte citado, o Claude Fable 5 aparece com 80%

Ou seja: ciclo de tentativas não é frescura de metodologia, é consequência de um número desses. Vai falhar em uma parte boa das tarefas difíceis na primeira tentativa, e tudo bem, desde que você tenha estrutura pra rodar de novo com informação nova

O que ajuda é o ganho de confiabilidade factual: na avaliação interna de factualidade da OpenAI (baseada em conversas reais desidentificadas em que usuários sinalizaram erros), o GPT-6 Sol comete cerca de metade dos erros do antecessor, se aproximando da confiabilidade do Astra

Isso conta MUITO num loop, porque o relato de cada rodada ("o teste X passou, o Y quebrou por causa disso") é o insumo da rodada seguinte. Relato errado envenena o ciclo inteiro

Próximo passo

O resumo é quase constrangedor de simples: antes do primeiro prompt grande, você precisa de duas coisas

Um comando que pontua a saída

E um AGENTS.md que fixa o que não muda

Com esses dois no lugar, o resto é rodar: /plan pra quebrar, uma melhoria focada por vez, re-rodar o eval, /review pra olhar sem mexer, e fechar com o log

Minha sugestão pra hoje: pega uma tarefa real que você já ia pedir de uma vez só e roda ela em 3 rodadas curtas, anotando o score de cada uma. Compara com o teu hábito antigo e me conta o que deu

E pras partes baratas do fluxo (resumo, classificação, rascunho descartável), joga no Luna, que sai por US$ 0,10 de entrada e US$ 0,50 de saída por 1M de tokens. Não precisa queimar o Sol em tudo

Até o próximo post!