Como montar um teste justo entre o GPT-6 Sol e o modelo que você já usa?

Escolher modelo por benchmark de terceiro é tipo contratar dev pelo currículo sem nunca ter olhado uma linha de código dele

A OpenAI anunciou o GPT-6 Sol e o GPT-6 Luna em 22 de setembro de 2026, os dois entrando na linha GPT-6 junto com o GPT-6 Astra

No mesmo dia a Anthropic anunciou o Claude Opus 5.5

Ou seja: em 24 horas o seu setup virou "o modelo antigo" e a pergunta prática caiu no seu colo

Vale trocar o que eu já uso?

A resposta honesta não está em tabelinha de terceiro, está no seu backlog

Então bora montar um teste justo, barato e repetível, que você roda hoje e guarda pro próximo lançamento (que vem semana que vem, né? 😅)

O que você precisa antes de começar o teste

Nada de PC da Nasa aqui, o custo desse teste é quase todo de organização

• Acesso aos dois modelos que você quer comparar. O GPT-6 Sol e o GPT-6 Luna estão em ChatGPT Work e Codex para usuários Plus, Pro, Business, Enterprise e Edu, e também na API. Quem é Free ou Go consegue testar o GPT-6 Luna no app desktop. No GitHub Copilot, o GPT-6 Sol aparece nos planos Pro+, Max, Business e Enterprise, e o GPT-6 Luna nos planos Pro, Pro+, Max, Business e Enterprise
• Do outro lado do ringue, o Claude Opus 5.5 está no Claude para usuários Pro, Max, Team e Enterprise, na plataforma Claude, em Amazon Web Services, Google Cloud e Microsoft Foundry, e também chegou ao GitHub Copilot em 22 de setembro de 2026. O fast mode do Opus 5.5 está disponível no Claude Code e na plataforma Claude
• Os identificadores de API na mão, porque é isso que você vai anotar na planilha: gpt-6-sol, gpt-6-luna e claude-opus-5-5
• Um arquivo de registro. Planilha, markdown, Notion, tanto faz, contanto que seja SEU

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Duas observações que economizam dor de cabeça

A primeira: o rollout no ChatGPT é gradual ao longo do dia do anúncio, e a própria OpenAI orienta tentar mais tarde se os modelos ainda não aparecerem em ChatGPT Work ou Codex

Se não apareceu, calma, não é bug do seu lado

A segunda: a plataforma Evals da OpenAI está descontinuada, fica somente leitura em 31 de outubro de 2026 e é desligada em 30 de novembro de 2026

Por isso eu insisto tanto no arquivo próprio

Ferramenta de avaliação vai e vem, mas o histórico do que o modelo acertou no SEU código é seu ativo

Passo a passo para montar o teste justo

1. Escolha de 3 a 5 tarefas reais do backlog

Pega tarefa que já existe e que você sabe como deveria terminar

Um refactor chato de arquivo grande, um bug com stack trace real, um trecho de código legado que ninguém quer tocar, uma doc que você adiaria pra sempre

Três já dá sinal, cinco já dá conforto

O erro comum deste passo: pedir "faça um todo list app" pros dois e achar que decidiu alguma coisa

Tarefa de demo todo mundo passa, ela não separa ninguém

2. Congele o prompt e o contexto

Mesmo texto, mesmos arquivos anexados, mesmo tamanho de entrada, mesma ordem

Escreve o prompt num arquivo e cola dos dois lados, sem improviso

O erro comum deste passo: reescrever o prompt no meio do teste porque a primeira resposta veio ruim

Aí você não está mais comparando modelo, está comparando prompt

Se precisar melhorar o prompt, beleza, mas volta e roda os dois de novo do zero

Essa lógica de prompt fixo e rodada repetida é a mesma de um teste de AEO com prompts repetidos: o que dá confiança não é a resposta bonita, é a repetição controlada

3. Escreva o critério de aprovação ANTES de rodar

Esse é o passo que quase todo mundo pula e é justamente o que torna o teste justo

Antes de ver qualquer resposta, escreve numa linha o que significa "aprovado" naquela tarefa

Exemplos de critério que funcionam:

• compila e sobe sem erro
• passa na suíte de testes que já existe
• não inventa método nem parâmetro de API que não existe no projeto
• respeita o formato de saída pedido (JSON, diff, arquivo único)
• não tocou em arquivo fora do escopo

O erro comum deste passo: definir o critério depois de ler a resposta

Sempre que eu faço isso, o critério mágicamente vira aquilo que o modelo que eu já gostava entregou 😄

4. Fixe as variáveis do modelo

Aqui mora a injustiça silenciosa

O GPT-6 Sol aceita os níveis de esforço de raciocínio pelo parâmetro reasoning.effort: none, low, medium (padrão), high, xhigh e max

Escolhe UM nível, anota na planilha e não muda no meio

O erro comum deste passo: rodar um modelo no esforço alto e o outro no padrão

Aí a comparação morreu antes de começar, e você ainda vai achar que descobriu algo

5. Rode os dois com o mesmo comando

No Codex CLI, você troca de modelo e ajusta o esforço de raciocínio com /model dentro da sessão interativa, ou já abre apontando o modelo com --model (alias -m):

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

No Claude Code, a ideia é a mesma: /model <alias|nome> durante a sessão, ou a flag --model na abertura:

claude --model opus

Repara que no exemplo da doc vai o alias opus, e não o identificador de API claude-opus-5-5

Alias é atalho, identificador é o nome exato do modelo na API, por isso a própria doc escreve <alias|nome>

Na planilha eu anoto sempre o identificador, porque é ele que não deixa dúvida de qual modelo rodou naquela linha

Repare que o comando é curto de propósito

Quanto menos coisa variar entre uma rodada e outra, mais limpo fica o resultado

O erro comum deste passo: rodar um modelo no agente de coding e o outro no chat do navegador

Ferramenta diferente muda contexto, muda permissão, muda tudo

6. Avalie às cegas

Salva as duas saídas como saida_a.md e saida_b.md, guarda num arquivo separado qual é qual, e só depois julga

Parece frescura, mas não é

A marca do modelo pesa MUITO na hora de avaliar, principalmente quando você já defendeu essa marca pros seus colegas

O erro comum deste passo: olhar o nome do modelo antes de dar a nota

7. Registre resultado, custo e tempo

Uma linha por rodada, sem exceção

Se não foi registrado, não aconteceu, e daqui a duas semanas você não vai lembrar de nada

O erro comum deste passo: anotar só "gostei mais do A"

Daqui a três lançamentos, esse registro vale ouro pra ver se o modelo novo realmente evoluiu no SEU tipo de tarefa

Planilha de registro: o que anotar em cada rodada

Essas são as colunas que eu manteria, nem mais nem menos:

E aqui os números de referência que entram na conta de custo:

Duas variáveis da ficha técnica mudam quais tarefas cabem no seu teste

A documentação da OpenAI indica contexto de 1.050.000 tokens e até 128.000 tokens de saída para o GPT-6 Sol

Isso define se aquele bug com repositório inteiro no contexto é testável ou se você vai ter que recortar (e recortar igual dos dois lados, claro)

A outra é a data de corte de conhecimento do GPT-6 Sol: 20 de abril de 2026

Se a sua tarefa depende de uma lib que mudou depois disso, o modelo não está errando por ser burro, está errando por não saber

Tarefa desse tipo só é justa se você entregar a doc no contexto, pros dois

O que aprendi comparando modelos na prática

Eu montei esse tipo de comparação no vídeo aqui embaixo, e dá pra te adiantar onde o teste escorrega

No vídeo eu deixei cada modelo na mesma condição de uso, sem mexer em configuração de um lado só, justamente pra não existir vantagem de setup

E rodei os três com acesso completo e permissões liberadas, sem perguntas no meio: cada um recebia só o prompt e ia executar sozinho

A segunda decisão foi usar o agente de coding nativo de cada modelo

Porque senão você não sabe se o resultado ruim é do modelo ou da ferramenta que você enfiou ele dentro

Depois escolhi dois projetos bem diferentes: um e-commerce completo e um jogo 3D em terceira pessoa estilo velho oeste

No e-commerce dividi em três prompts separados, homepage e scaffolding, fluxo de compra (produto, carrinho, checkout, página de obrigado) e área administrativa

E os critérios ficaram definidos antes: qualidade do design, tempo de criação, nível de detalhe do fluxo de compra, clareza do layout pro usuário final e completude da área admin

No jogo eu fui mais duro ainda: prompt idêntico nos três, one-shot, uma tentativa só, sem chance de ajuste depois

O prompt pedia projeto do zero em pasta nova, com todos os elementos (personagens, nomes, lugares) 100% originais, sem referência a jogos ou marcas existentes

E antes de qualquer teste prático, fiz a comparação das fichas técnicas (preço, contexto, multimodalidade) só pra contextualizar

Inclusive montei um cenário hipotético de custo, com documento grande de entrada e resposta longa de saída, pra mostrar como o preço se comporta num uso de verdade

O que eu tiro disso tudo: a diferença entre modelos quase nunca aparece na primeira tela bonita

Ela aparece no detalhe do fluxo, na parte que o modelo decidiu não fazer e não avisou, na área admin que ficou pela metade

Por isso o vídeo mostra rodada por rodada, do primeiro prompt até a área admin, pra você ver onde cada um travou e comparar com o critério que eu tinha escrito antes

Bora ver na prática?

Quais tarefas do backlog escolher para o teste

Tarefa genérica não decide nada porque todo modelo moderno passa nela

O que separa modelo é tarefa com atrito real

• Bug com contexto grande: stack trace, arquivo grande, dependência entre módulos. Aqui você vê quem lê o contexto inteiro e quem chuta pela metade
• Refactor multiarquivo: o clássico assassino. Renomeou em um lugar e esqueceu no outro? Reprovado
• Geração de teste: pede teste pra um código que você conhece bem. Teste que sempre passa e não valida nada é reprovação disfarçada de aprovação
• Revisão de PR: solta um diff real e veja se o comentário é útil ou só educado
• Documentação: obriga o modelo a explicar o código do jeito que a sua equipe escreve, não do jeito genérico
• Alto volume: a orientação da documentação do Codex é escolher o GPT-6 Sol (gpt-6-sol) pra equilibrar inteligência e custo, e o GPT-6 Luna pra cargas de alto volume sensíveis a custo. Então testa também a tarefa repetitiva no modelo barato: às vezes ela nem precisa do modelo caro

Esse último ponto é meio primo da discussão de quando o modelo aberto resolve: nem toda tarefa merece o modelo mais caro do catálogo, e quem descobre isso é o registro, não o feeling

Por que benchmark de terceiro não decide por você

Olha, número público é útil, só não é veredito

Na página do Artificial Analysis, o GPT-6 Sol (max) marca 48 no Artificial Analysis Intelligence Index na versão v4.3.2, composta por 10 avaliações, rodando a 104 tokens por segundo (a mediana do conjunto é 75)

Velocidade alta é uma informação prática de verdade, porque muda a sua experiência de uso no dia a dia

Já o número de inteligência é média de coisas que talvez não sejam o seu trabalho

Tem também a avaliação interna de factualidade da OpenAI, baseada em conversas reais desidentificadas em que usuários sinalizaram erros: o Sol comete cerca de metade dos erros do antecessor

Só que o próprio anúncio faz a ressalva de que essa avaliação seleciona de propósito conversas que induzem erro e não representa o uso normal do ChatGPT

Repara como a ressalva é honesta e mesmo assim o número vira manchete sem ela

Veredito: esses números servem pra você montar HIPÓTESE, tipo "parece que vale trocar"

Quem aprova é o seu teste, no seu código, com o seu critério escrito antes

Conclusão

O teste justo é chato de montar na primeira vez e barato pra sempre depois

A receita inteira cabe em cinco linhas: tarefas reais do backlog, prompt e contexto congelados, critério de aprovação escrito antes, mesmo esforço de raciocínio dos dois lados, avaliação às cegas e registro

O próximo passo concreto é hoje mesmo: escolhe 3 tarefas do seu backlog, escreve o que significa "aprovado" em cada uma e roda a primeira rodada

Guarda essa planilha com carinho

Porque quando sair o próximo modelo (e vai sair rápido), você não vai precisar ler thread de ninguém pra saber se vale trocar

Você roda a planilha de novo e descobre sozinho 😀

até o próximo post!