Usar o Fable 5.1 para revisar o código do GPT-6 Astra funciona?

Fala aí, beleza? A cena de setembro de 2026 é essa: um modelo escreve o código, o outro entra atrás pra revisar

O Claude Fable 5.1 saiu em 1 de setembro de 2026 e o GPT-6 Astra em 3 de setembro de 2026, dois dias de diferença

Aí a pergunta que todo mundo passou a fazer deixou de ser "qual é melhor" e virou uma coisa bem mais prática: colocar um pra revisar o que o outro escreveu melhora o código, ou só te entrega mais texto pra ler antes do commit?

Bora destrinchar isso com o que dá pra checar, e só com o que dá pra checar

O que cada modelo traz e qual comando de revisão existe hoje

Do lado da Anthropic, o Fable 5.1 é modelo classe Mythos voltado a coding, análise de dados, uso de computador e trabalho agêntico longo, anunciado junto com o Claude Mythos 5.1

Preço de API: US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de saída

A leitura de cache levou um corte de 75%, saindo de US$ 1 para US$ 0,25 por milhão de tokens, com o cache write seguindo em US$ 12,50 por milhão (cache de 5 minutos)

Janela de 1.000.000 de tokens de contexto, até 128.000 tokens de saída, e ele aceita texto, imagens e arquivos como PDF

O identificador é claude-fable-5-1 na Claude API, no Google Cloud, no Microsoft Foundry e na Claude Platform na AWS, e anthropic.claude-fable-5-1 no Amazon Bedrock

No Claude Code, a versão 2.1.257 definiu o Fable 5.1 como modelo Fable padrão, com contexto de 1M e a mesma cobrança de US$ 10/US$ 50 por Mtok e US$ 0,25/Mtok em leitura de cache

Se tu já tinha prompt afiado na geração anterior, dá uma olhada no que muda quando seus prompts do Fable 5 vão pro 5.1 antes de culpar o revisor por resposta estranha

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 GPT-6 Astra?

O Astra foi lançado primeiro para um conjunto limitado de organizações

Preço igual no headline: US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de saída, com entrada cacheada a US$ 1 por milhão

Isso é 2,5x o preço do GPT-5.6 Sol, que era US$ 4/US$ 20

Contexto de 1.050.000 tokens, 128K de saída máxima, entrada de texto e imagem, corte de conhecimento em 30 de abril de 2026

O identificador na API é gpt-6-astra

Na virada de 6 para 7 de setembro de 2026, o estado era: disponível na API e para usuários Pro, Enterprise e Business Premium no Work e no Codex, com Plus tendo acesso no Work e no Codex

E o GPT-5.6 Sol continua sendo o padrão, se liga nisso antes de achar que já está revisando com o Astra

Os fluxos nativos de revisão que existem de verdade:

Não precisa gambiarra pra rodar revisão, os dois lados já têm caminho próprio

• /code-review no Claude Code: lê o diff não commitado e lista os achados, sem exigir o GitHub App. /review é alias dele. Aceita alvo opcional (diretório ou número de PR), níveis de esforço, --comment pra postar comentários inline no PR e --fix pra aplicar os achados na working tree
• /security-review no Claude Code: análise de segurança sob demanda no diretório do projeto, apontando itens como SQL injection, XSS, falhas de autenticação e tratamento inseguro de dados
• /review no Codex: abre os presets de revisão e inicia um revisor dedicado que lê o diff selecionado e devolve achados priorizados, sem alterar a working tree

Repara numa diferença que já muda teu fluxo: o revisor do Codex não mexe na working tree, e o do Claude Code mexe se tu pedir

Fable 5.1 x GPT-6 Astra como revisor: o que muda de lado a lado

Lendo a tabela sem romantizar: o Fable 5.1 tende a te entregar menos ruído por achado, com menos nitpick e mais precisão, pagando isso em tempo de revisão

O Astra tende a achar mais coisa quando o diff cruza vários arquivos

São perfis diferentes, e é exatamente isso que faz o cruzamento fazer sentido em alguns casos e virar barulho em outros

O que o cruzamento entre os dois modelos realmente pega

Antes de tudo, um aviso honesto: não existe estudo controlado testando especificamente o Fable 5.1 revisando código do GPT-6 Astra até 07/09/2026

O experimento cruzado que existe (arXiv 2607.21656) usa Claude e Codex em gerações anteriores, com 116 tarefas médias e difíceis, seis condições e esforço de raciocínio alto

Então tudo aqui é leitura de tendência, não profecia

Diff grande que cruza vários arquivos:

É o cenário em que o segundo par de olhos rende mais

A avaliação da CodeRabbit mostra o Astra ganhando justamente em revisões difíceis multiarquivo, com 20% sobre o Sol e 33% sobre o Opus 5

Quando a mudança espalha por serviço, model e teste, a chance de um revisor sozinho perder o fio é alta

O que isso NÃO cobre: o revisor do estudo vê o problema e o rascunho, mas não executa testes

Rascunho gerado sob pressa que precisa de checagem de lógica:

Aqui está o número mais forte do estudo cruzado: revisão do Claude eleva rascunhos do Codex de 71,6% para 89,7%

A auto revisão do Codex sobe pra 84,5%, ou seja, o revisor de fora rendeu mais que o próprio modelo se relendo

É como pedir pra outra pessoa ler teu texto: tu já sabe o que quis dizer, ela não

O que isso NÃO cobre: de novo, suíte verde continua sendo trabalho teu

Passada de segurança sob demanda:

O /security-review no Claude Code roda uma análise de segurança no diretório do projeto e aponta itens como SQL injection, XSS, falhas de autenticação e tratamento inseguro de dados

É um pedido separado, com escopo próprio, e não uma consequência automática da revisão geral

O que isso NÃO cobre: achado apontado não é achado corrigido, e nada disso substitui rodar o teste

Quando a revisão cruzada vira só ruído

Sintoma 1: pilha de achados que ninguém tria

A causa é simples e cruel: descoberta acelerada por IA sem capacidade de correção do outro lado

O caso mais duro disso é o Internet Bug Bounty, operado pela HackerOne, que parou de aceitar novas submissões a partir de 27 de março de 2026, citando o desequilíbrio entre a descoberta acelerada por IA e a capacidade de correção dos mantenedores open source

Um programa inteiro travou por excesso de coisa pra triar

Como prevenir: separar leitura de aplicação, e isso está nos passos logo abaixo

Sintoma 2: revisão que só concorda com o que já está escrito

A causa é viés de prompt, e o dado aqui é insano

O arXiv 2607.10411, estudo sobre bajulação em detecção de code smells, mediu Decision Flip Rate chegando a 72% e False Alignment Rate acima de 90% sob prompts enviesados, com o código inalterado

Mesmo código, veredito diferente, só porque a suposição embutida no pedido mudou

O trabalho é de Istiaq Ahmed Fahad, Kamruzzaman Asif e Md. Nurul Ahad Tawhid, do Institute of Information Technology da Universidade de Dhaka

Como prevenir: cuidar do enunciado do pedido, passo 1 da próxima seção

Sintoma 3: resultado bom demais pra ser verdade

A causa costuma ser o arranjo em volta do modelo, não o modelo

A ARC Prize mediu o GPT-6 Astra em 62,7% no ARC-AGI-3 com o harness dela e 99,9% com o harness da OpenAI

E os próprios autores do benchmark dizem que não estão declarando AGI

Mesmo modelo, mesmo teste, dois números que não conversam

Soma a isso as cinco métricas que a OpenAI alterou depois da publicação do lançamento do Astra: a taxa de alucinação apareceu como 4,2%, foi para 2% e voltou para 4,2%; o número do Fable 5.1 no FrontierMath caiu de 87,8% para 78% e ficou em 83%; e no ExploitBench interno o GPT-5.6 Sol subiu de 5,5% para 11,5%, com a OpenAI dizendo estar avaliando reverter para 5,5% porque o resultado refletia um nível de raciocínio não disponível comercialmente

Como prevenir: teu repo é o benchmark que importa, e a próxima seção é sobre como perguntar direito

Como pedir a revisão para não receber elogio vazio

1. Não enquadre o diff como já correto

Esse é o erro mais caro e o mais comum

O arXiv 2603.18740 testou 250 pares de CVE e patch em quatro modelos sob cinco enquadramentos de prompt: descrever a mudança como livre de bugs reduz a taxa de detecção de vulnerabilidades entre 16% e 93%

E o efeito é assimétrico: os falsos negativos disparam enquanto a taxa de falsos positivos quase não muda

Falhas de injeção são mais suscetíveis que corrupção de memória

Erro comum deste passo: abrir com "esse patch já corrigiu o bug, confere pra mim?"

2. Rode a revisão pelo caminho nativo do produto certo

Se o rascunho está no repo e tu quer revisão do diff não commitado, é /code-review no Claude Code, com alvo e nível de esforço quando fizer sentido

/code-review
/code-review src/auth

Se o rascunho está no Codex, é /review por lá, que abre os presets e roda o revisor dedicado

Erro comum deste passo: misturar instrução de um produto com a do outro, achando que o que vale num vale no outro. Não vale

3. Separe leitura de aplicação

Primeiro tu lê os achados, depois tu decide o que entra

--comment posta comentários inline no PR, --fix aplica os achados na working tree

/code-review --fix

Erro comum deste passo: mandar --fix de cara e deixar o modelo mexer em coisa que tu nem leu ainda

4. Peça a passada de segurança em separado

/security-review

Ele roda a análise sob demanda no diretório do projeto e aponta itens como SQL injection, XSS, falhas de autenticação e tratamento inseguro de dados

Erro comum deste passo: esperar que a revisão geral cubra segurança de brinde

5. Feche com execução de testes

O revisor do estudo cruzado vê o problema e o rascunho, mas não executa nada

Então a última palavra é da tua suíte, sempre

Erro comum deste passo: confundir "o revisor aprovou" com "o código passou"

E se tu quer que uma regra de revisão valha só naquela rodada sem sujar a configuração do projeto, dá pra usar instrução válida só por um turno no Fable 5.1

Veredito: vale usar o Fable 5.1 como revisor do Astra?

Vale, com condição: na direção Fable revisando o rascunho, não o contrário

O estudo cruzado é claro nisso, mesmo sendo de gerações anteriores: revisão do Claude eleva rascunhos do Codex de 71,6% para 89,7%, enquanto Codex revisando rascunho do Claude derruba de 91,4% para 82,8%

E a auto revisão do Claude apenas mantém os 91,4%, ou seja, não piora nem melhora

Na conta, os dois cobram US$ 10/US$ 50 por Mtok, então o desempate não vem do preço de tabela: vem do cache

US$ 0,25 por Mtok de leitura no Fable 5.1 contra US$ 1 na entrada cacheada do Astra, e revisão é justamente o tipo de trabalho que relê o mesmo contexto várias vezes

O contrapeso honesto existe: no Coding Agent Index da Artificial Analysis o GPT-6 Astra teve ganho significativo e pontuou no mesmo patamar do Fable 5 com custo menor, puxado por eficiência de tokens, ainda que no Intelligence Index essa eficiência seja anulada pelo preço mais alto

E no índice revisado (versão 4.2, publicada em 5 de setembro de 2026, com entrada de AA-Briefcase e GDP.pdf, saída do GPQA-Diamond, dados privados a 40% do peso e correção de erros de pontuação) o Astra ganha quatro pontos sobre o antecessor, com o Claude Fable 5.1 seguindo na liderança e o Astra em segundo

A Anthropic, por sua vez, posiciona o Fable 5.1 como resultado igual ou melhor que o Fable 5 com custo menor, condicionado a esforço low ou medium. É alegação da casa, trate como tal

Pra quem não vale: quem não tem tempo de triar achado

Revisão sem triagem não é qualidade, é dívida empilhada com carinha de produtividade

Conclusão

O próximo passo é chato e é o único que resolve: pega um diff real que tu já tem pronto, roda a revisão pelo caminho nativo do produto onde o código está, compara os achados com o que a suíte de testes mostra, e só então decide se o cruzamento entra no teu fluxo

Porque o que esses estudos todos apontam na mesma direção é que a direção da revisão e o enunciado do pedido pesam mais que a escolha do modelo

Diff enquadrado como "já correto" derruba detecção entre 16% e 93%, prompt enviesado vira veredito com o código intacto, e harness diferente muda o número de 62,7% pra 99,9%

Nenhum desses problemas se resolve trocando de modelo

Refaça o experimento no teu repo, com o teu código, e me conta o que apareceu 😀

até o próximo post!