Como comparar o GPT-6 Astra com outro modelo no seu próprio projeto: guia do teste lado a lado

Escolher modelo por hype é o jeito mais caro de errar 😅

O GPT-6 Astra foi lançado em 03/09/2026 como prévia limitada pra parceiros e no dia seguinte, 04/09/2026, foi liberado pra usuários pagantes numa versão restrita

Desde então todo mundo já tem opinião formada, quase sempre baseada em print de benchmark alheio

Só que benchmark de terceiro mede a média do mundo, não mede o seu código, o seu prompt e o seu tipo de tarefa

Então bora fazer o teste que realmente decide: mesma tarefa, mesmo prompt, mesmo critério de julgamento, rodando no seu projeto

E se liga nisso: o método aqui serve pra qualquer par de modelos, hoje com o Astra contra um Claude, semana que vem com o que sair depois

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

Antes de sair mandando prompt, junta as peças:

• Acesso aos dois modelos. Na API da OpenAI o identificador é gpt-6-astra, e ele também é distribuído via Microsoft Azure e Amazon Bedrock
• Uma contraparte definida. Do lado da Anthropic tem Claude Sonnet 5 (lançado em 30/06/2026), Claude Opus 5 (24/07/2026), Claude Fable 5.1 e Claude Mythos 5.1 (setembro de 2026)
• Saber onde o Astra aparece pra você. No ChatGPT o acesso varia por plano: no Plus ele aparece em Work e Codex, e usar o Astra no Chat exige plano Pro. Pro, Business e Enterprise também recebem acesso
• Um conjunto de tarefas tiradas do projeto real, não charadinha de blog
• Um lugar pra registrar: planilha simples já resolve, JSONL resolve melhor ainda
• Orçamento definido, porque o Astra custa US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de saída

Esse último item não é frescura

Teste mal planejado vira fatura, e aí você desiste no meio e decide no achismo mesmo

Passo a passo: montando o teste lado a lado

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

1. Escolha o par e justifique pelo custo

O Astra sai a US$ 10 de entrada e US$ 50 de saída por milhão

O GPT-5.6 Sol sai a US$ 4 e US$ 20, ou seja, o Astra é 2,5 vezes o preço do Sol

Do outro lado, Claude Sonnet 5 fica em US$ 2 e US$ 10, e Claude Opus 5 em US$ 5 e US$ 25

O erro comum deste passo: comparar o modelo topo de linha com o mais barato da casa e comemorar a vitória do caro

Compare com quem você usaria de verdade se o Astra não existisse

2. Defina as tarefas a partir de trabalho real

Pega commit real, bug real, refactor real que você já resolveu

Cinco a dez tarefas já dão sinal, e o fato de você já saber a resposta certa é justamente o que permite julgar

O erro comum deste passo: montar tarefa sintética que nenhum dos dois modelos vai errar

Se os dois acertam tudo, seu teste não mediu nada

3. Fixe o prompt e as variáveis

Mesmo texto, mesmo contexto anexado, mesma ordem dos arquivos

E fixe o esforço de raciocínio, que no Astra aceita cinco níveis: low, medium, high, xhigh e max

Os valores none e minimal deixaram de existir nesse modelo, então prompt antigo que usava isso quebra o seu controle

Na Responses API o campo é reasoning.effort:

{
  "model": "gpt-6-astra",
  "reasoning": { "effort": "high" },
  "input": "<seu prompt fixo, exatamente o mesmo dos dois lados>"
}

Na Chat Completions o campo tem outro nome:

{
  "model": "gpt-6-astra",
  "reasoning_effort": "high",
  "messages": [{ "role": "user", "content": "<seu prompt fixo>" }]
}

O erro comum deste passo: rodar um lado em max e o outro no padrão, e depois anunciar vencedor

Esforço diferente é teste diferente, ponto

4. Controle o tamanho da entrada

O Astra tem 1.050.000 tokens de contexto e entrega até 128.000 tokens de saída

Parece que dá pra jogar o repositório inteiro dentro, né? Tome cuidado

Requisições que passam de 272 mil tokens de entrada caem numa faixa de preço mais cara pra requisição inteira: US$ 20 de entrada, US$ 2 de entrada em cache, US$ 25 de escrita de cache e US$ 75 de saída, por milhão

O erro comum deste passo: deixar o contexto crescer entre uma tarefa e outra e comparar a primeira execução barata com a última execução na faixa cara

5. Rode e registre saída, custo e tempo

Uma linha por execução, sem exceção

{"tarefa": "t01-refactor-auth", "modelo": "gpt-6-astra", "effort": "high", "tokens_in": 18420, "tokens_out": 3110, "custo_usd": 0.34, "segundos": 62, "saida": "..."}
{"tarefa": "t01-refactor-auth", "modelo": "claude-sonnet-5", "effort": "n/a", "tokens_in": 18420, "tokens_out": 2890, "custo_usd": 0.07, "segundos": 41, "saida": "..."}

O erro comum deste passo: guardar só a resposta e esquecer custo e tempo

Sem esses dois campos você não consegue responder a única pergunta que importa no fim, que é se o modelo caro se pagou

6. Julgue com rubrica fechada

Escreva os critérios ANTES de ler qualquer saída

Algo tipo: resolveu a tarefa (sim ou não), quebrou teste existente (sim ou não), precisou de quantas correções, seguiu o padrão do projeto (0 a 2)

O erro comum deste passo: inventar critério depois de ver a resposta que você já gostou

Isso não é avaliação, é torcida organizada 😀

Três formas de rodar o teste: playground, Evals API e Claude Code

Caminho manual rápido: chat playground

Pra sentir o cheiro dos dois modelos em meia hora, o chat playground do OpenRouter resolve

Você manda o mesmo prompt e compara as respostas lado a lado, com modelos de OpenAI, Google, Anthropic e outros na mesma interface

É o caminho pra triagem: serve pra cortar candidato ruim cedo, não pra fechar veredito

Caminho automatizado: Evals API da OpenAI

Quando você já tem as tarefas escritas, dá pra parar de rodar na unha

A Evals API deixa você criar uma avaliação uma vez e rodar ela várias vezes trocando modelo ou prompt

Um eval reúne data source, critérios de teste e configuração

Cada run executa o eval contra os dados, opcionalmente amostra respostas do modelo, aplica os critérios e agrega pass/fail por critério

Os dados de teste podem ser enviados como arquivo JSONL, no schema que você mesmo definiu na criação do eval, com as entradas de teste e os rótulos de referência:

{"item": {"pergunta": "<tarefa 01 do seu projeto>", "referencia": "<resposta certa conhecida>"}}
{"item": {"pergunta": "<tarefa 02 do seu projeto>", "referencia": "<resposta certa conhecida>"}}

E tem um detalhe que salva o teste: graders do tipo score_model e label_model usam um modelo juiz definido no campo model, independente do modelo que está sendo testado

Ou seja, dá pra manter o juiz fixo enquanto os concorrentes trocam

O erro comum aqui é deixar o juiz variar junto com o testado, e aí você não sabe mais o que mudou

Caminho dentro do editor: Claude Code

Se boa parte do seu trabalho já acontece no terminal, a troca de modelo pode ser feita ali mesmo

No Claude Code dá pra trocar o modelo de quatro formas: /model <alias|nome> no meio da sessão, claude --model <alias|nome> na inicialização, a variável de ambiente ANTHROPIC_MODEL ou o campo model no arquivo de configuração

claude --model <alias|nome>

E antes de rodar a tarefa, confere o que está ativo:

/status

O erro comum deste passo: achar que trocou o modelo e não ter trocado

Um /status de três segundos evita jogar uma bateria inteira de teste no lixo

As armadilhas de método que só aparecem quando você roda os dois lados

O método acima não nasceu de teoria

Mas ele também não nasceu comparando modelo com modelo: ele veio de um teste que eu fiz colocando duas ferramentas de fluxo de trabalho (Superpowers e GSD) pra resolver o MESMO projeto

Ferramenta não é modelo, eu sei, só que a mecânica de botar dois concorrentes na mesma tarefa é idêntica, e foi ali que eu apanhei pra acertar a regra do jogo

Essa regra eu defini antes de começar, e é a parte que vale pra qualquer comparação, inclusive Astra contra Claude: mesmo projeto, mesma ideia, mesmo prompt nos dois lados, pra ver onde cada um chega

Abri o VS Code com duas pastas separadas, uma pra cada ferramenta, com um terminal aberto em cada uma, e instalei as duas em paralelo antes de encostar no projeto

Escolhi de propósito um projeto simples (um e-commerce funcional) em vez de algo complexo

O objetivo era avaliar o comportamento das ferramentas, não o produto final

Deixei explícito qual modelo eu estava usando e usei o mesmo dos dois lados, porque a variável em teste tinha que ser só a ferramenta

O prompt eu preparei com antecedência, revisei com calma e mandei exatamente o mesmo texto pros dois

E aí começam as armadilhas de método, que é o que você não descobre lendo comparativo pronto

Primeira: não deu pra manter os dois terminais lado a lado o tempo todo, porque cada ferramenta abre a sua própria rodada de perguntas

Fui respondendo tentando manter as duas execuções no mesmo passo do fluxo, e quando uma perguntou algo que a outra não perguntou (campo de estoque, login obrigatório pra comprar, fonte das imagens), eu respondi de forma a igualar as escolhas nos dois projetos

Se você não faz esse trabalho chato, os dois projetos divergem no minuto cinco e a comparação morre ali

Segunda: eu passei reto na revisão das specs só pra mostrar o desenrolar do fluxo

Numa situação real eu leria tudo pra conferir se está nos conformes, e é isso que eu recomendo pra quem for repetir

Terceira: eu reduzi o número de fases no planejamento de um dos lados pra execução não ficar longa demais, porque planejamento muito extenso afetaria a comparação

E optei pelo modo de auto aprovação num dos lados pra acelerar, sendo que o modo iterativo é a melhor escolha quando o projeto é mais sério

Olha o tamanho da decisão de método escondida aí: cada corte desses precisa ser anotado, senão você compara maçã com bicicleta

O que só apareceu porque os dois resolveram a mesma tarefa foi a diferença de filosofia

Uma foca em disciplina e em forçar o caminho certo

A outra foca em levantar contexto e montar uma base de informações antes de codar, e eu achei esse lado mais burocrático, com mais perguntas e mais fases, alongando o tempo de planejamento

O ciclo que eu observei de uma delas foi: brainstorm, worktree por funcionalidade, escrita dos planos, subagente com TDD, revisão de código e entrega da funcionalidade

O fluxo da outra foi uma sequência de comandos: discutir a fase, planejar a fase, executar a fase, verificar o trabalho e por fim publicar

Teve até detalhe de ambiente entrando na conta: uma delas pedia permissão pra escrever arquivos, porque eu não tinha aberto o Claude Code com permissões totais

Isso não é defeito da ferramenta, é configuração minha, e num teste mal registrado viraria "a ferramenta X é mais lenta"

No fim eu não elegi vencedor único, minha conclusão foi que as duas podem coexistir no mesmo fluxo de trabalho

A lição aqui não é sobre ferramenta de fluxo, é sobre método: rubrica fechada ANTES, escolhas igualadas dos dois lados, e todo desvio anotado

Troca "ferramenta" por "modelo" e cada uma dessas armadilhas continua valendo igualzinho

Números públicos que servem de linha de base (mas não substituem seu teste)

Os dados abaixo servem pra você escolher o par e estimar a conta, não pra decidir por você

O corte em 30/04/2026 muda o desenho das tarefas, então vale entender até onde vai o corte de conhecimento do Astra antes de montar caso de teste sobre biblioteca recente

Preço dos candidatos que costumam entrar no páreo:

Agora a parte que todo mundo cita errado

O score do Astra no Artificial Analysis Intelligence Index varia conforme o nível de esforço configurado:

E o Top 5 atual da página viva de dados do Artificial Analysis, entre 79 modelos avaliados:

Repara que o mesmo modelo aparece em posições diferentes só por causa do esforço

É exatamente por isso que o passo 3 lá em cima existe

Benchmarks divulgados pela própria OpenAI pro Astra: 72,6% no OSWorld 2.0 (uso de computador), 97,6% no FrontierMath Tier 4 e 100% no ExploitBench

E tem um detalhe que pode derrubar o SEU teste antes de começar

A versão liberada em 04/09/2026 pra usuários pagantes é restrita e recusa certos prompts, com cibersegurança no exemplo

O Astra é o primeiro modelo da OpenAI a atingir o nível Crítico de capacidade em cibersegurança no Preparedness Framework da própria empresa

Ou seja: se metade das suas tarefas de teste é análise de vulnerabilidade, você não vai medir capacidade, vai medir recusa

Como fechar o veredito sem se enganar

Quatro critérios e olhe lá:

• Acerto na tarefa: resolveu o que precisava, sem quebrar o resto
• Custo por tarefa resolvida: não é o preço por milhão, é quanto saiu a tarefa que ficou de pé
• Retrabalho: quantas idas e voltas até virar código aceitável
• Consistência entre execuções: rodou três vezes e deu resultado parecido, ou foi sorte na primeira?

O modelo caro se paga quando ele resolve na primeira o que o barato só resolve na terceira, porque aí o custo por tarefa resolvida encosta e o seu tempo entra na conta

Ele NÃO se paga quando a tarefa é mecânica e repetitiva, e nessa hora ajuda muito ter mapeado quando não usar o Astra antes de padronizar o time no topo de linha

Regra de desempate honesta: empatou no acerto, ganha o mais barato

Empatou no acerto e no custo, ganha o mais consistente

E o erro clássico do final: decidir por uma única rodada

Uma rodada mede sorte, três rodadas medem comportamento

O veredito é do seu projeto, não é a média de um índice público, e não tem problema nenhum a sua conclusão ir contra o ranking

Conclusão

O que a gente montou aqui não é um post de comparação, é um procedimento

Tarefas tiradas do projeto real, prompt fixo, esforço de raciocínio declarado, registro de saída, custo e tempo, rubrica escrita antes

E o melhor: isso é ativo reutilizável, não trabalho descartável

Próximo passo bem concreto pra hoje: salva as suas tarefas num arquivo JSONL, roda a primeira bateria com o par que você escolheu e guarda a rubrica junto

Quando sair o próximo modelo, você não recomeça do zero, só troca o campo model e roda de novo

E aí a resposta pra "esse modelo novo é bom?" deixa de ser opinião de timeline e passa a ser o seu número

Bora testar? 😀

até o próximo post!