GPT-6 Sol disse que terminou o código: como conferir se ele entregou mesmo

Fala aí, beleza? Aquela cena todo mundo já viveu: o modelo escreve "pronto, implementei e testei tudo, está funcionando", você abre o projeto e ele nem sobe 😅

A OpenAI acabou de lançar o GPT-6 Sol e o GPT-6 Luna, expandindo a linha GPT-6 ao lado do GPT-6 Astra

E tem um detalhe do anúncio oficial que interessa MUITO pra quem programa com IA: os dois novos modelos mostram melhorias de alinhamento sobre os equivalentes GPT-5.6, incluindo uma taxa menor de alegações enganosas sobre o próprio trabalho de coding

Ou seja: mentem menos sobre o que fizeram

Mentem menos não é mentem nunca, então bora montar um protocolo de verificação pra você medir isso no SEU repositório, em vez de acreditar no relato

O que a OpenAI mediu (e o que esses números querem dizer)

Primeiro, o que é uma "alegação enganosa sobre trabalho de coding"?

É quando o modelo afirma que fez algo que não fez: diz que rodou o teste sem rodar, diz que corrigiu o bug sem tocar no arquivo, diz que validou a integração quando só chutou

Na avaliação interna da OpenAI, o GPT-6 Sol ficou em 1,3%

O antecessor, GPT-5.6 Sol, estava em 10,4%

O GPT-6 Luna marcou 2,8% e o GPT-6 Astra, o modelo mais caro da linha, está em 0,5%

Tem mais dois testes de comportamento que valem a leitura

A ferramenta de busca quebrada:

A avaliação entrega ao modelo uma ferramenta propositalmente quebrada e observa se ele revela o problema ou se prefere chutar uma resposta como se estivesse tudo certo

O Sol deixou de revelar a falha em 4,9% das vezes

O antecessor deixava passar em 77,5%

Salto absurdo, é o tipo de coisa que muda o dia de quem roda agente em repositório grande

O caso do "access denied":

Aqui o resultado é bem menos animador

Quando instruído a respeitar um aviso explícito de access denied, o GPT-6 Sol ainda tentou contornar a restrição em 64,4% das execuções, contra 68,2% do antecessor

Melhorou pouco

A própria OpenAI ressalta que essas avaliações testam deliberadamente situações difíceis e não medem taxa de falha em uso típico, então não leia esses percentuais como "2 em cada 3 tarefas vão furar tua permissão"

Leia como: em cenário hostil, o modelo ainda empurra

Vale citar também que em avaliação interna de factualidade o novo Sol comete cerca de metade dos erros do antecessor

Taxa de alegações enganosas em coding: Sol, Luna, Astra e a geração anterior

Juntando taxa de engano e preço de API, dá pra enxergar onde vale pagar mais por confiabilidade:

Repara no detalhe: o GPT-6 Sol custa 50% menos que o GPT-5.6 Sol (que era US$ 4 de entrada e US$ 20 de saída) e ainda assim mente bem menos sobre o próprio trabalho

O Astra é o mais confiável nesse recorte, mas sai cinco vezes mais caro na entrada e cinco vezes na saída

O Luna é o barato de verdade, e a diferença de 1,3% pra 2,8% é o preço disso

Protocolo de verificação: 5 passos para conferir se o código foi entregue mesmo

A lógica é simples: o relatório do modelo é a HIPÓTESE, o repositório é o juiz

1. Rode antes de ler qualquer resumo

Antes de ler o texto bonito de "implementei X, Y e Z", sobe o projeto com o mesmo comando que tu usa todo dia

Build, teste, servidor local, o que for do teu fluxo

Se não sobe, acabou a conversa, o resumo não importa

O erro comum deste passo: ler o resumo primeiro e já entrar viciado, procurando confirmação em vez de falha. Essa mesma lógica de rodar antes de aceitar vale pra qualquer agente: já escrevi sobre quando o Claude Code diz que terminou e o código não sobe

2. Leia o diff, não o relato

No Codex CLI existe o /diff, que inspeciona o diff do Git e mostra mudanças staged, não staged e arquivos ainda não rastreados

/diff

Esse terceiro grupo é o mais traiçoeiro: arquivo novo que nunca foi rastreado costuma ser exatamente onde mora a surpresa

O erro comum deste passo: olhar só o que está staged e achar que viu tudo

3. Peça prova, não relato

Em vez de perguntar "funcionou?", peça o que dá pra conferir: a saída de execução, os nomes dos arquivos tocados e as linhas alteradas

Pergunta fechada gera resposta verificável

Pergunta aberta gera redação

O erro comum deste passo: aceitar "os testes passaram" sem a saída colada. Se o modelo não mostra a saída, considere que ele não rodou

4. Passe o /review no working tree

Ainda no Codex CLI, o /review faz o Codex resumir os problemas encontrados no working tree, com foco em mudanças de comportamento e testes faltando

/review

É o segundo par de olhos barato: você já tem o diff na mão do passo 2, agora deixa a máquina apontar o que mudou de COMPORTAMENTO e o que ficou sem cobertura

O erro comum deste passo: tratar o /review como aprovação final. Ele é insumo pro teu review, não substituto

5. Cace o teste que passa por estar vazio

Teste verde é a ilusão mais cara do vibe coding

Abra os testes novos e pergunta: esse teste chega a chamar a função real? O mock não está devolvendo justamente a resposta que o assert espera? Existe caso de erro coberto ou só o caminho feliz?

O erro comum deste passo: confiar na contagem de testes. Vinte testes que não exercitam nada passam mais rápido do que dois que exercitam

Rodou os cinco passos e bateu? Aí sim é entrega

O que vi rodando o GPT-5.6 Sol contra o Fable 5 em um projeto real

Aqui vale o aviso: meu teste prático foi com a geração anterior, o GPT-5.6 Sol, contra o Fable 5, mesmo projeto e mesmo prompt, no reasoning máximo e nos modos turbo de cada ferramenta (Ultra no GPT e Ultra Code no Fable)

O GPT-5.6 Sol terminou a primeira etapa do projeto em 11 minutos

O Fable passou de 20 minutos e ainda estava rodando a MESMA etapa, com a cota de uso da ferramenta caindo de 100% para 83% no caminho

Velocidade insana

Mas quando o 5.6 Sol avisou que tinha terminado, eu não aceitei o aviso: pedi pro próprio modelo iniciar o projeto pra rodar e conferir na prática

Deu erro na hora 😅

A porta 3000 já estava ocupada por outro projeto meu, tive que pedir pra subir em outra porta (o projeto do Fable também precisou de porta diferente, então nem é culpa do modelo)

É bobo, mas é o passo 1 do protocolo funcionando: só rodando você descobre

Outra coisa que me incomodou: o Codex rodando o 5.6 Sol não mostra de antemão o que vai fazer, só informa o que está fazendo naquele momento

Eu queria a lista prévia do que falta, ajuda a saber se ele está seguindo o plano ou improvisando

Entregar rápido não é o mesmo que entregar certo

O protocolo lá de cima é justamente o que separa os dois

No vídeo acima eu mostro os dois rodando lado a lado, com os arquivos aparecendo em tempo real, o Fable travando num comando de estrutura de pastas e o 5.6 Sol gerando imagens com o GPT Image pra simular fotos de clientes na landing page

O que muda no seu dia a dia de dev

Onde o Sol aparece pra você hoje:

• ChatGPT: Sol e Luna estão em ChatGPT Work e Codex para usuários Plus, Pro, Business, Enterprise e Edu. Usuários Free e Go acessam o Luna no app desktop. O rollout é gradual ao longo do dia e administradores Enterprise precisam habilitar os modelos, então se não apareceu ainda, não é bug. Se o teu time já vive dentro do ChatGPT Work, vale olhar também o data agent para dashboards
• GitHub Copilot: GPT-6 Sol nos planos Copilot Pro+, Max, Business e Enterprise; GPT-6 Luna em Pro, Pro+, Max, Business e Enterprise. Cobrança por uso e rollout gradual também
• API: o identificador é gpt-6-sol (e gpt-6-luna pro irmão barato)

Na API, os números do Sol são: 1.050.000 tokens de janela de contexto, 128.000 tokens de saída máxima e corte de conhecimento em 20 de abril de 2026

O esforço de raciocínio tem seis níveis: none, low, medium (padrão), high, xhigh e max

No Codex CLI, o /model é o comando pra selecionar ou configurar o modelo da sessão, documentado junto dos outros slash commands

E o argumento de custo-benefício vem do DeepSWE v1.1, que testa tarefas complexas de engenharia de software em repositórios reais: o Sol em esforço max marca 68,8%, a 1,1 ponto percentual do melhor resultado do Claude Fable 5 na avaliação (69,9% em xhigh), com custo por tarefa cerca de 80% menor

Quase o mesmo resultado por uma fração do custo, é isso que o número diz

Conclusão: confie no diff, não no relatório

Sair de 10,4% para 1,3% de alegações enganosas em coding é uma melhoria real e relevante, não é marketing

E o teste da ferramenta quebrada, de 77,5% para 4,9%, é o tipo de mudança que você SENTE rodando agente o dia inteiro

Mas 1,3% não é zero, e o caso do access denied ainda está em 64,4%

O verificador continua sendo você 🙂

Próximo passo prático: na próxima tarefa que o modelo declarar concluída, roda os 5 passos e compara o que ele DISSE com o que o /diff mostra

Se bater, ótimo, confiança construída com evidência

Se não bater, você economizou um debug de duas horas…

Até o próximo post!