Mesmo prompt, três IAs, recibos reais: comparando Claude vs Codex vs Gemini num PR real

Se você programa com IA, você já compara modelos. Só que mal.

Três terminais. O mesmo prompt colado três vezes. Você dá uma olhada nos diffs, escolhe qual “parece” melhor, cola no PR, e não tem nenhum registro de quem disse o quê nem do que custou. A discordância que deveria ser o sinal mais valioso do seu dia — sumiu no histórico do seu clipboard.

Essa semana eu rodei o mesmo code review em Claude, Codex e Gemini numa sessão compartilhada, com tool calls e um ledger de custo, e os recibos mudaram qual modelo eu vou usar da próxima vez.

O setup

Um PR real num repo real: refator de lógica de invalidação de sessão num auth middleware. Diff de ~80 linhas. Aquele tipo de mudança em que os testes unitários passam mas um merge descuidado pode deslogar todo mundo às 3 da manhã.

Um comando, três runtimes:

ato review --consensus \
  --reviewer claude \
  --reviewer codex \
  --reviewer google

Cada reviewer rodou na mesma sessão. O turno #2 viu os achados do #1 via replay de histórico (sem precisar colar prompt de novo). Tool calls (read_file, grep, git_log) deixaram cada modelo andar pelo repo de verdade em vez de chutar. Cada chamada de ferramenta foi logada com o caminho do arquivo que tocou.

O que cada modelo disse

Claude (claude-sonnet-4-6):

“LGTM. O refator está limpo — o novo helper invalidateSession() consolida lógica que estava duplicada em três callers. Os testes cobrem o caminho feliz. Manda ver.”

Codex (gpt-4.1):

“BLOQUEANDO. Essa mudança quebra a invalidação de sessão no logout. O código anterior chamava db.deleteSession(sid) de forma síncrona antes de retornar a resposta. O refator moveu isso pra um fire-and-forget assíncrono via o novo helper, que roda depois da resposta ser enviada. Se o helper der erro (ex: db inacessível), a sessão persiste no storage; o cookie do usuário some no lado cliente mas o servidor ainda aceita o session ID antigo.”

“Verificado lendo middleware/auth.ts:142 e helpers/session.ts:38. O novo helper não tem error handler; o código antigo dava throw em erros de db e expunha um 500.”

Gemini (gemini-2.5-flash):

“Endosso o achado do Codex. Rodei grep -r ‘invalidateSession’ de novo — o novo helper também é chamado do endpoint de password-reset, onde o mesmo padrão fire-and-forget agora abriria uma janela em que a sessão antiga continua válida. Esse é o segundo caso do bug, não só o do logout.”

Três modelos. Um falou pra mandar ver. Dois pegaram o bug. Sem ATO, eu teria seguido a recomendação do Claude, ficado sabendo da regressão por um ticket de cliente, e perdido o resto do dia revertendo.

Os recibos

Aqui está o ledger de custo e qualidade que o ATO registrou para esse review:

Três coisas que essas linhas mostram:

• O modelo mais barato pegou o bug. Gemini a US$ 0,01 foi a segunda voz mais confiante no achado BLOQUEANDO. Se eu tivesse adotado “use sempre o modelo mais caro” como regra, perderia a pegada.
• Tool calls indicam profundidade, não verbosidade. Claude fez 1 tool call (leu o diff) e parou. Codex fez 3 (diff + dois arquivos relacionados). Gemini fez 2 (diff + um grep). O modelo que quis verificar a afirmação fez mais chamadas; o que quis aprovar fez menos.
• A auditoria toda custa menos que um cafezinho. US$ 0,07 totais para um code review N-vias num diff real. Sem a comparação, eu teria pago US$ 0,04 ao Claude e estaria errado.

O que muda quando você faz isso direto

Depois de algumas semanas rodando todo diff não-trivial através de ato review --consensus, os recibos começam a contar uma história:

• Codex tende a ganhar em refatores e diffs com cara de segurança.
• Claude tende a ganhar em explicações de arquitetura greenfield.
• Gemini tende a ganhar em sumarização de contexto longo onde preço por token importa.

Isso não é um benchmark genérico. É um benchmark pessoal, sobre o seu trabalho, no seu repo. O objetivo de ter recibos é parar de chutar e começar a citar.

Como rodar isso aqui

brew install willnigri/ato/ato
ato review --consensus

Ou rode ato demo-compare no primeiro launch e o ATO te coloca numa sessão pré-carregada mostrando dois LLMs comparando um refator lado a lado — sem configuração.

Tudo cai num banco SQLite em ~/.ato/local.db na sua máquina. Cada dispatch grava custo, tokens, duração, tool calls, arquivos tocados. Você pode rodar sqlite3 direto. Login é opcional e só serve se você quiser sync entre dispositivos, LLM-as-judge hospedado, ou sessões compartilhadas com time — grátis durante o beta.

MIT. Local-first. Traga suas chaves.

Baixar ATO → Ver no GitHub →

Os recibos deste post são de uma sessão real ato review --consensus rodada em 2026-05-16. O diff do auth middleware é representativo da classe de bug que a comparação multi-LLM pega; o repo específico é privado mas a sessão, prompts e tool calls são reproduzíveis pela CLI pública em qualquer repo que você aponte.