O GPT-6 Astra alucina? Como validar a resposta antes de colocar no código

Modelo que erra menos e modelo em que dá pra confiar sem olhar são duas coisas MUITO diferentes

Fala aí, beleza? A OpenAI anunciou o GPT-6 Astra em 03/09/2026 e posicionou ele como o modelo mais capaz da casa: raciocínio complexo, programação, uso de computador, pesquisa e criação de documentos

E mesmo com esse currículo todo, a pergunta que todo mundo faz continua de pé: o GPT-6 Astra alucina?

Alucina

O que mudou é que hoje dá pra apontar com bastante precisão ONDE ele inventa, e isso muda a sua rotina de revisão inteira

Neste post eu te mostro os três lugares onde o erro nasce, e montamos juntos uma rotina de validação em 5 passos pra rodar antes do código entrar no repositório 🙂

O que os números realmente dizem sobre alucinação do GPT-6 Astra

Vamos começar pelo que é medido, não pelo que o hype fala

No AA-Omniscience, benchmark da Artificial Analysis, o GPT-6 Astra reduziu a taxa de alucinação de 92% para 51% no esforço máximo, e ganhou 4 pontos de acurácia no mesmo movimento

O benchmark tem 6.000 perguntas cobrindo 42 tópicos, entre eles Engenharia de Software, Direito, Saúde, Negócios e Ciências

E o índice dele é interessante pelo desenho: escala de -100 a 100, pontua acerto, penaliza alucinação e é NEUTRO quando o modelo se abstém de responder

Ou seja: não responder não custa nada, inventar custa

Nota negativa ali significa mais erros do que acertos

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

E o system card, o que diz?

A OpenAI afirma no system card que o Astra comete substancialmente menos erros factuais que o GPT-5.6 Sol, e que tem menor probabilidade de reproduzir alucinações reportadas por usuários

O ganho é mais acentuado nos ajustes de baixa latência e baixo raciocínio, o que faz sentido: é justamente onde a geração anterior escorregava mais

Tem ainda um número que eu achei mto massa: em uma das avaliações, o Astra é três vezes menos propenso que o GPT-5.6 Sol a fazer afirmações imprecisas sobre as PRÓPRIAS capacidades e limitações

Agora a ressalva, e ela é da própria OpenAI: essa avaliação de factualidade é montada sobre conversas do ChatGPT que usuários sinalizaram como contendo erro factual

Traduzindo: é um conjunto de casos propensos a alucinação, as taxas absolutas são muito mais altas que as de produção e não devem ser lidas como taxa de alucinação real

O system card também separa duas coisas que a galera costuma misturar: se a resposta tem erro em QUALQUER ponto, e se o modelo reproduz o erro específico que o usuário sinalizou

O contexto de fronteira:

Ah, e um detalhe de bastidor que resume bem o clima do lançamento: a Forbes registrou que veículos como CNBC, Reuters, The Verge e VentureBeat publicaram citando o material de lançamento antes de a página principal do Astra ficar acessível, e a página sumiu e reapareceu

Nem o anúncio do modelo escapou de um errinho de execução, imagina o código que ele te devolve haha

Onde o GPT-6 Astra ainda inventa (e como o erro aparece no seu código)

Alucinação não é uma coisa só, são padrões diferentes com causas diferentes

Se liga nos três que mais aparecem no dia a dia de quem programa

1. O pacote que não existe:

Sintoma: o modelo te entrega um import ou uma linha de instalação com um nome de dependência que soa perfeito, mas não existe no registro

Causa: nome de pacote é altamente previsível estatisticamente, então o modelo completa um nome plausível do mesmo jeito que completaria uma frase

Uma pesquisa de 2026 mediu esse fenômeno na coorte de modelos de fronteira e achou taxas entre 4,62% (Claude Haiku 4.5) e 6,10% (GPT-5.4-mini), uma compressão relevante frente às gerações anteriores

Vale marcar: essa pesquisa cobre a geração anterior, não o Astra especificamente

E aqui mora a parte feia: um estudo da Socket identificou que cinco LLMs de fronteira geraram os MESMOS nomes de pacotes inexistentes, deixando 53 nomes disponíveis pra registro malicioso em PyPI e npm

Esse ataque tem nome: slopsquatting, o registro de pacotes maliciosos usando nomes que os modelos alucinam com frequência

Pensa na cena: a IA erra o nome, alguém registra o nome errado com payload dentro, e você roda o install sem olhar

Como prevenir: nenhuma dependência entra sem passar pelo registro oficial primeiro, sem exceção

2. A assinatura de função que parece certa:

Sintoma: a função existe, a biblioteca existe, mas o parâmetro não existe, ou a ordem dos argumentos está trocada, ou o retorno não é aquele

Causa: o modelo aprendeu o padrão de bibliotecas parecidas e mistura as convenções, ainda mais quando a API mudou entre versões maiores

Como prevenir: conferir contra a doc oficial da versão QUE VOCÊ TEM instalada, não contra a memória do modelo e nem contra a doc da última major

3. O dado que ele não pode saber:

Sintoma: resposta segura, bem escrita e completamente desatualizada

Causa: o corte de conhecimento do GPT-6 Astra é 30 de abril de 2026

Tudo que aconteceu depois disso, se ele não tiver o material no contexto, é chute plausível

Como prevenir: para qualquer coisa posterior a essa data, você cola a fonte no contexto ou não pergunta

Esse tipo de erro é o mais perigoso dos três, porque ele não quebra na execução, ele só fica lá parecendo verdade

O que você precisa antes de validar qualquer resposta

A lista é curta, e é bem menos glamourosa que o lançamento:

• Acesso ao modelo. O rollout é escalonado desde 03/09/2026: primeiro um conjunto limitado de organizações e, nos dias seguintes, usuários ChatGPT Plus, Pro, Business e Enterprise, além da API da OpenAI e da AWS
• O identificador certo na API: gpt-6-astra
• Um ambiente onde dê pra EXECUTAR o código gerado. Sem isso, metade da rotina abaixo não funciona
• A doc oficial da biblioteca aberta numa aba, na versão que você usa
• O lockfile do projeto à mão, pra comparar nome e versão de dependência

Os parâmetros que mudam o comportamento:

Duas coisas na página do modelo na API da OpenAI importam direto pra essa conversa

A primeira é o reasoning.effort, que aceita os níveis low, medium, high, xhigh e max

A segunda é que o modelo usa max_completion_tokens no lugar de max_tokens

Se você veio de uma integração antiga e só trocou o nome do modelo, é bem aqui que a request quebra

{
  "model": "gpt-6-astra",
  "reasoning": { "effort": "max" },
  "max_completion_tokens": 8192
}

A janela de contexto é de 1.050.000 tokens e a saída máxima é de 128K tokens

Guarda esse número da janela, ele volta lá na frente e é a arma mais subestimada contra alucinação

Rotina de verificação em 5 passos antes de colar no repositório

Bora ver na prática?

A rotina inteira leva poucos minutos e cabe em qualquer fluxo, inclusive no vibe coding mais apressado

1. Peça a fonte e o caminho da doc, e trate resposta sem fonte como não verificada

Em vez de aceitar a resposta pronta, feche o pedido com algo assim: "cite a página da documentação oficial e a versão da biblioteca em que essa assinatura existe, e se você não tiver certeza, diga que não tem"

Lembra da mecânica do AA-Omniscience? Abstenção não é penalizada ali

Você pode aplicar a mesma lógica no seu prompt: deixar claro que "não sei" é uma resposta aceitável reduz o incentivo do modelo a preencher o vazio

Tratar cada afirmação como hipótese até virar fato checado é o mesmo raciocínio que vale na hora de separar achado real de falso positivo num code review assistido por IA

O erro comum deste passo: aceitar uma URL de documentação que o modelo escreveu de cabeça

Link também alucina, abre e confere

2. Confira toda dependência citada no registro oficial antes de instalar

Essa é a defesa direta contra slopsquatting, e é a checagem de maior risco evitado com menor esforço da lista inteira

# antes de rodar qualquer install, confira o nome no registro oficial
npm view nome-do-pacote

Olha se o pacote existe mesmo, quantas versões tem, quem publica e há quanto tempo

Pacote novinho, com nome parecidíssimo com um pacote famoso e sem histórico? Tome cuidado!

O erro comum deste passo: rodar o install "só pra ver se funciona"

Se o pacote for malicioso, o dano já aconteceu no momento da instalação, não na hora que você importa

3. Rode o código

Parece óbvio, mas muita gente revisa lendo

E aqui tem um argumento que eu acho ótimo: Simon Willison defende, no Hallucinations in code are the least dangerous form of LLM mistakes, que alucinação em código é a forma MENOS perigosa de erro de LLM

O motivo é simples: método inventado quebra na hora que você roda, o erro fica evidente na sua cara

O problema mesmo é a afirmação em prosa, que passa despachada porque não tem interpretador pra reclamar dela

Se você já tem o hábito de revisar o código antes do PR com outro modelo, encaixa a execução nesse mesmo momento

O erro comum deste passo: rodar só o trecho gerado, isolado, e não o caminho real que chama aquele trecho no projeto

4. Teste o caminho de erro, não só o feliz

Código gerado por IA costuma acertar o happy path e ser otimista demais no resto

Então joga o input vazio, o input malformado, o timeout, a resposta 500, o arquivo que não existe

É nesse pedaço que aparece o try que engole exceção sem logar nada, o retorno None que ninguém trata e o retry infinito

O erro comum deste passo: aceitar o teste que a própria IA escreveu como prova

Se ela alucinou a função, ela alucina o teste da função com a mesma confiança, e aí os dois combinam entre si e você acha que está tudo certo xD

5. Suba o reasoning.effort e refaça a pergunta quando o assunto for factual

Quando a resposta depende de conhecimento e não de estilo, vale reperguntar em xhigh ou max

Foi exatamente esse movimento que levou a taxa de alucinação de 92% para 51% no AA-Omniscience, com os 4 pontos a mais de acurácia

Mas não é de graça: esforço maior significa mais tokens de saída, e saída é a parte cara da conta

O erro comum deste passo: subir o esforço para TUDO

Pra renomear variável e ajustar formatação, esforço máximo é só dinheiro queimado

Quando vale gastar esforço máximo (e quando é desperdício)

Essa decisão fica muito mais fácil quando você olha a tabela de preço

Repara na assimetria: saída custa cinco vezes a entrada, e entrada em cache custa um décimo da entrada normal

Isso desenha sozinho a estratégia

Onde vale o esforço máximo:

• Decisão de arquitetura que vai custar caro pra desfazer depois
• Qualquer resposta que envolva número, versão, preço ou compatibilidade
• Código que toca autenticação, permissão ou dado sensível
• Migração de biblioteca entre versões maiores, onde a assinatura muda e o modelo mistura as convenções

Nesses casos, revisar sai mais barato que reprocessar

Um bug de assinatura que passa direto vira uma sessão inteira de debug depois, e essa sessão consome muito mais token do que a pergunta bem feita teria consumido

Onde é desperdício:

• Renomear coisa, formatar, escrever docstring
• Refatoração dentro de um arquivo que você já leu inteiro
• Boilerplate que você reconhece de olho fechado

A janela de 1.050.000 tokens é a sua melhor defesa:

Essa parte é a que mais gente deixa na mesa

Em vez de confiar na MEMÓRIA do modelo sobre uma biblioteca, você cola a doc real no contexto

A janela de 1.050.000 tokens comporta a documentação de verdade, o trecho relevante do seu código e o lockfile juntos

Modelo lendo a doc que você colou alucina muito menos que modelo lembrando da doc que ele viu no treino, e o corte de conhecimento em 30/04/2026 deixa de ser um problema porque a informação está ali na frente dele

Só fica de olho no limite: passou de 272 mil tokens de entrada, a requisição inteira entra no multiplicador

Então cola a seção certa da doc, não a doc inteira 😀

Veredito: o que dá para confiar sem revisar

Sem enrolação

Dá pra soltar com revisão leve:

• Código que roda e tem teste passando (teste escrito por você, ou pelo menos lido por você linha a linha)
• Refatoração dentro de um arquivo que você já conhece
• Boilerplate de framework que você reconhece de bate pronto

Não dá pra soltar sem checar, nunca:

• Nome de pacote ou dependência
• Assinatura de API e nome de parâmetro
• Número, preço, limite, versão
• Qualquer coisa posterior a 30/04/2026
• E principalmente: afirmação em prosa

A prosa é o ponto cego

Ela não quebra na execução, não tem stack trace, não tem teste vermelho, ela só entra no seu README, na sua decisão técnica e na sua cabeça

Duas coisas pra fechar o quadro sem romantizar o modelo

A primeira é preço: a Artificial Analysis aponta que o GPT-6 Astra custa 2,5x o GPT-5.6 Sol, o que anula parte do ganho de eficiência em tokens que ele mostra no Intelligence Index

Ele usa menos tokens que o Sol pra desempenho similar no índice, mas o token dele é mais caro, então a conta não fecha automaticamente a favor

A segunda é mais séria: o GPT-6 Astra é o primeiro modelo que a OpenAI classificou como tendo atingido o limiar "crítico" de capacidade cibernética no preparedness framework, ou seja, capaz de encontrar e explorar vulnerabilidades desconhecidas sem orientação humana passo a passo

O treinamento, aliás, foi o maior já feito pela OpenAI, com mais de 100 mil GPUs no site Stargate, no Texas

Greg Brockman, presidente da empresa, chamou o modelo de "salto geracional" e encerrou o briefing com um "bem-vindo à era da AGI"

Pode ser salto geracional e ainda assim inventar nome de pacote, as duas coisas cabem na mesma frase…

Conclusão

O GPT-6 Astra alucina menos que a geração anterior, isso os números sustentam

Mas "menos" não é "não", e a diferença entre os dois mora exatamente no seu processo de revisão

A rotina que a gente montou aqui custa poucos minutos: pede a fonte, confere a dependência no registro, roda o código, testa o caminho de erro e sobe o esforço quando o assunto for factual

Poucos minutos contra uma dependência maliciosa em produção é um dos melhores câmbios que existem no seu dia

Meu próximo passo prático pra você: pega a última resposta que o modelo te deu HOJE e roda os 5 passos nela

Começa pela checagem de dependência, que é a de maior risco e menor esforço da lista

Bora testar? 😀

até o próximo post!