Como registrar os resultados do teste do GPT-6 Astra para decidir com dados (modelo de planilha)

Fala aí, beleza? Time que passa a manhã inteira testando modelo novo e à tarde não consegue explicar por que escolheu: isso não é decisão, é impressão

A OpenAI lançou o GPT-6 Astra em 3 de setembro de 2026 como seu modelo mais capaz, voltado pra trabalho de ponta a ponta: raciocínio complexo, código, uso de computador, pesquisa e criação de documentos

Só que o rollout foi confuso e desigual nos primeiros dias, com cliente pagante sem acesso ao modelo que o plano dizia incluir

O próprio Sam Altman classificou o rollout como "messy" em 4 de setembro de 2026

A liberação pros assinantes Plus só foi marcada como concluída em 6 de setembro de 2026

Aí acontece o óbvio: cada pessoa do seu time testou em um lugar diferente, num dia diferente, com um acesso diferente

E no fim da semana ninguém consegue comparar nada, a escolha sai pela última resposta bonita que alguém viu na tela

O que eu vou te mostrar aqui é bobo de tão simples: uma planilha de meia dúzia de colunas que transforma impressão solta em decisão que você consegue defender depois 🙂

O que definir antes de abrir a planilha

Antes do primeiro prompt, três coisas precisam estar fechadas, senão a planilha nasce torta

1. Onde seu time tem acesso

Isso muda tudo, porque o Astra não mora no mesmo lugar em todo plano

No ChatGPT Plus (US$ 20 por mês) o GPT-6 Astra é acessado por dentro do ChatGPT Work e do Codex, com limite de uso do plano

Formação Recomendada

Formação Claude Code

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

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Ou seja: ele não aparece no seletor de modelo do chat comum, onde o topo segue sendo o GPT-5.6 Sol

Já no chat comum o modelo aparece com o nome GPT-6 Pro, listado pela OpenAI apenas nos planos Pro, Business e Enterprise

E o Pro aqui aparece em dois níveis de preço, com teto de mensagens diferente em cada um: no Pro de US$ 100 são 50 mensagens do GPT-6 Pro por semana, e no Pro de US$ 200 são 200 por semana

Se você ainda está batendo cabeça pra saber quem já pode usar hoje, resolve isso antes: testar sem saber qual produto você está usando é jogar dado fora

Na API a história é mais direta, basta definir model = gpt-6-astra numa requisição da Responses API

2. As tarefas que vão entrar no teste

Escolhe de 5 a 10 tarefas REAIS do trabalho de vocês, não desafio de internet

E escreve, antes de rodar, o que conta como aprovado em cada uma

Pergunta chata que evita briga depois: "aprovado" é rodar sem erro, é passar no teste, ou é o time aceitar o código sem reescrever? Define e anota

3. Os números de custo que alimentam a coluna de preço

O preço padrão do Astra na API é de US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída

Entrada em cache sai por US$ 1 por milhão, e escrita de cache por US$ 12,50 por milhão

E tem a pegadinha que mais estoura orçamento em teste: prompts acima de 272.000 tokens de entrada mudam a tarifa da requisição INTEIRA, não só do excedente

Acima desse ponto são 2x nas taxas de entrada e de cache e 1,5x na saída, o que dá US$ 20 de entrada e US$ 75 de saída por milhão

Como a janela de contexto é de 1.050.000 tokens (divulgada como 1M), estourar os 272 mil é bem mais fácil do que parece, principalmente se alguém jogar o repositório inteiro no prompt

Detalhe pra anotar no rodapé da planilha: o corte de conhecimento do modelo é abril de 2026, e ele aceita texto e imagem na entrada, devolvendo texto

Como montar a planilha de teste do GPT-6 Astra passo a passo

O cabeçalho pode ser esse aqui, colado direto numa planilha nova ou salvo como CSV

tarefa,ambiente,prompt_usado,resultado,correcoes,desistiu,tokens_entrada,custo_estimado_usd,nota_0_5
landing page institucional,Codex,"<prompt completo aqui>","página abriu e o layout ficou usável",0,nao,18000,0.28,5
clone de plataforma 2d,chat,"<prompt completo aqui>","jogo abre mas o personagem nao pula",3,sim,42000,1.10,0

Agora o passo a passo de como preencher isso sem se enganar

1. Crie a aba de tarefas com uma linha por TAREFA, não por prompt. A unidade de decisão é a tarefa concluída, não a quantidade de mensagens trocadas. O erro comum deste passo: abrir uma linha nova a cada tentativa de correção, o que infla a planilha e esconde justamente o dado mais valioso, que é quantas idas e voltas aquela tarefa custou
2. Cole o prompt usado na íntegra, sem resumir. Nada de escrever "pedi uma landing page", porque daqui a duas semanas ninguém reproduz isso. O erro comum deste passo: resumir o prompt. Se o prompt é gigante, joga num arquivo .md na pasta do teste e coloca o caminho na célula
3. Registre o resultado em uma frase objetiva, mais o link ou arquivo gerado. "Rodou, mas o scroll travou na segunda seção" vale mais que "mais ou menos". O erro comum deste passo: registrar só o que deu certo. Falha não anotada vira falha esquecida, e falha esquecida vira decisão errada
4. Conte as correções. Cada prompt extra necessário até chegar num resultado aceitável conta como 1, e quando você desistir, marca a coluna desistiu e para de contar. O erro comum deste passo: deixar em branco quando desistiu, o que faz a tarefa parecer barata quando ela foi um buraco sem fundo
5. Anote ONDE rodou. Esse campo não é burocracia, é dinheiro: a regra de custo muda por produto. No Codex, a sobretaxa de contexto longo não se aplica e entradas em cache não são cobradas, e essa regra vale só pro Codex, enquanto a API continua aplicando a sobretaxa acima dos 272 mil tokens. O erro comum deste passo: comparar o custo de um teste feito no Codex com outro feito na API como se fosse a mesma conta
6. Dê nota final de 0 a 5, na mesma escala para todos os modelos comparados. Escala combinada e escrita em algum canto da planilha, do tipo: 0 não entregou (ou você desistiu), 3 entregou com retrabalho, 5 entregou pronto sem correção. O erro comum deste passo: cada pessoa usando a régua da cabeça dela, aí a média não significa nada
7. Feche com duas métricas só: média por categoria e taxa de tarefas concluídas SEM nenhuma correção. Essa segunda é a que separa modelo bom de modelo simpático. O erro comum deste passo: olhar só a média geral, que é gentil demais com um modelo que acerta muito no fácil e quebra no que importa

Se você quiser ir além, coloca uma coluna de tempo de resposta também

Em teste de lançamento isso costuma variar bastante entre ambientes, e vale entender por que o Astra demora para responder antes de culpar o modelo pela lentidão da sua aplicação

Por que a coluna de correções é a mais importante (o que vi testando na prática)

Eu já fiz esse tipo de maratona de teste e é por isso que insisto tanto nessa coluna

Quando testei um modelo de lançamento recente (não era o Astra, mas a mecânica do teste é a mesma), fiquei uma manhã e um pedaço da tarde nisso, quase o dia todo, e fui anotando projeto por projeto o que funcionou e o que quebrou

O jogo de tanques saiu com três ou quatro prompts

O clone de jogo de plataforma travou num detalhe idiota: gastei uns três prompts só pra fazer o personagem pular, e não consegui

A landing page, por outro lado, saiu com UM prompt só, e nas duas ferramentas que eu testei

E esses três são só uma parte do que passou pela planilha naquele dia: no balanço final, aproximadamente metade dos projetos falhou

Se liga no que acontece sem registro: no fim do dia a memória guarda a landing page bonita que saiu de primeira e apaga as três tentativas fracassadas do pulo

Aí você fecha o notebook com a sensação de "achei que ficou massa", e essa sensação vira a decisão do time inteiro 😅

Outras coisas que só apareceram porque eu estava anotando: os erros concretos se repetiam (jogo que não iniciava, scroll travado, preview que não carregava, erro recorrente no console)

E pedir correção ao modelo em cima do bug costumava piorar o código em vez de resolver, o que é exatamente o tipo de coisa que a coluna de correções denuncia e a impressão geral esconde

Eu também separei tipos diferentes de saída (código, imagem, vídeo e apresentação) e guardei uma avaliação pra cada, em vez de misturar tudo num julgamento só

E comparei modos de execução dentro da extensão: o modo de arquitetura deu resultados melhores que o modo padrão, mesmo demorando mais pra responder

Repeti a mesma landing page na interface web e na extensão dentro do editor de propósito, e joguei na segunda ferramenta os pedidos que tinham falhado na primeira, pra saber se o problema era do ambiente ou do modelo

Sem a coluna de ambiente eu nunca teria conseguido responder isso

No vídeo abaixo eu mostro esse dia todo de teste, com as tentativas e as falhas aparecendo uma a uma ao longo das horas

Como adaptar a planilha ao que seu time precisa decidir

A mesma planilha resolve três perguntas diferentes, mudando só o que você compara

Cenário 1: GPT-6 Astra ou Claude Fable 5.1?

Esse é o caso em que o preço não decide nada, porque os dois têm o mesmo preço de tabela por token

Na página viva do Artificial Analysis Intelligence Index, na versão v4.2, o Fable 5.1 lidera e o Astra fica em segundo, com dois pontos de diferença

Vale saber como esse número nasceu: o Artificial Analysis publicou a v4.2 depois de críticas de que os benchmarks anteriores não capturavam o avanço do Astra, usando tarefas mais difíceis e maior parcela de dados de teste secretos

Dois pontos num índice não pagam a conta da sua decisão, beleza? É a sua planilha que paga

Cenário 2: vale o upgrade em cima do GPT-5.6 Sol?

O Sol custa US$ 4 de entrada e US$ 20 de saída por milhão, cerca de 2,5x mais barato que o Astra

Então a pergunta não é "qual é melhor", é: a coluna de correções justifica pagar 2,5x?

Roda as MESMAS tarefas nos dois, com a mesma escala de nota, e compara a taxa de tarefas concluídas sem correção

Se o Astra resolve de primeira o que o Sol resolve em três tentativas, o mais caro por token pode sair mais barato no fim do mês

Se empatar, você acabou de economizar um bom dinheiro por ter anotado

Cenário 3: onde rodar (Codex, chat ou API)?

Aqui quem decide são as colunas de ambiente e de custo

A sobretaxa de contexto longo é o divisor de águas: na API ela existe acima de 272 mil tokens de entrada, no Codex ela não se aplica e o cached input não é cobrado

Uma coluna extra que vale a pena acompanhar é o consumo de tokens por tarefa

Segundo o Artificial Analysis, o Astra usa menos tokens por tarefa do que qualquer outro modelo de fronteira medido, e isso mexe direto na sua conta, mesmo com o preço por token mais alto

E sobre benchmark: a OpenAI divulgou no anúncio 97,6% no FrontierMath Tier 4, 99,9% no ARC-AGI-3, 100% no ExploitBench e 72,6% no OSWorld 2.0 de uso de computador, com cerca de 47% menos tempo por tarefa que o GPT-5.6 Sol

São números fortes, sem dúvida

Mas benchmark não é igual à realidade do seu código, do seu legado e do seu jeito de escrever prompt

A sua tabela de 8 tarefas reais decide melhor que a tabela deles, é isso que eu repito sempre

Conclusão

A planilha não serve pra provar que o GPT-6 Astra é bom

Ela serve pra você conseguir EXPLICAR a decisão depois, quando alguém perguntar por que o time trocou de modelo, ou por que não trocou

Recapitulando o que ela precisa ter: uma linha por tarefa, o prompt completo, o resultado em uma frase, o número de correções, o ambiente onde rodou, o custo e a nota de 0 a 5 na mesma escala

E duas métricas no fim: média por categoria e taxa de tarefas resolvidas sem nenhuma correção

Próximo passo, hoje mesmo: pega as 5 tarefas que vocês mais repetem na semana, roda cada uma UMA vez e preenche as colunas de correções e de nota antes de esquecer

Meia hora de trabalho chato agora vale mais que uma semana inteira de teste sem registro…

Até o próximo post! =)