Em 15 de setembro de 2026, Fabio Akita publicou o resultado de seis modelos empatados em 100 pontos no benchmark de programação dele. Os custos foram US$ 30,55 no GPT-6 Astra, cerca de US$ 71 no Claude Opus 5 e cerca de US$ 50 no Claude Fable 5. O GPT 5.6 Sol custou US$ 20,37, o GPT 5.6 Terra US$ 9,52 e o GPT 5.5 US$ 34,69. [S02]
Esses valores são o custo publicado de cada execução, e nem todos foram pagos pelo mesmo método. Os GPT rodaram no Codex, com custo por tokens; os Claude usaram assinatura Max, com “custo nocional”, uma estimativa atribuída à execução. O valor do Fable 5 foi reconstruído após perda dos registros. Comparar diretamente os seis como cobranças equivalentes seria errado. [S02]
Para programação cotidiana em Rails, Akita concluiu que “escolher entre qualquer modelo de Tier A é essencialmente indiferente”. Segundo ele, a diferença entre os modelos apareceu quando o código foi sabotado de propósito, e o custo pesou mais na decisão. Essa conclusão vale para o trabalho que ele testou. [S02]
Para quem paga IA para trabalhar, a pergunta útil é qual vantagem concreta justificaria pagar mais, esperar mais ou trocar a ferramenta que já funciona.
O texto principal monta o raciocínio inteiro, e dá para levar a ideia para o seu projeto sem abrir nada.
As seções Abrir o capô mostram o mecanismo, a conta e o limite de cada medição. Dá pra pular sem perder o raciocínio.
O DeepSeek V4.1 Flash fez 92,5 por US$ 1,21
O mais barato perto do topo foi o DeepSeek V4.1 Flash, com 92,5 por US$ 1,21. O Nex N2.5 Pro fez 94 gratuitamente, mas deixou as correções sem commit, isto é, sem registrá-las na versão entregue do código. Encontrar o defeito não bastou para entregar o projeto corrigido. [S02]
O Claude Opus 4.8 ficou em 86, com custo nocional de aproximadamente US$ 37. O Gemini 3.1 Pro ficou em 32,5 por US$ 10,31, mas a execução dele via OpenRouter (um serviço que dá acesso a vários modelos) foi interrompida por um problema de integração. A nota ficou incompleta por causa dessa falha de integração. [S02]
A comparação mais limpa está dentro do Codex. O GPT 5.6 Terra chegou aos 100 em 80 minutos, por US$ 9,52. O GPT 5.6 Sol também fez 100, mas levou 317 minutos e custou US$ 20,37. Calculando a partir da tabela, Sol custou aproximadamente 2,14 vezes mais e demorou quase quatro vezes mais naquela execução. [S02]
Terra vira um candidato óbvio para um teste próprio de custo-benefício. Naquela rodada, o gasto e a espera adicionais do Sol não compraram uma nota maior; em outro projeto o resultado pode ser outro.
Cancelar uma assinatura por causa dessa tabela seria precipitado. Quem usa IA para revisar propostas, analisar documentos ou preparar campanhas ainda não viu as próprias tarefas nessa comparação. A economia interessa se a alternativa continuar entregando o que a pessoa precisa.
Abrir o capô A fórmula do custo por entrega aceita
Para uma comparação própria, uma medida possível é:
O tempo de revisão deve estar em horas, e todos os valores monetários na mesma moeda. Sem entregas aceitas, a divisão não oferece um custo útil.
Em assinatura, diferencie o desembolso mensal do custo adicional de uma tarefa. Um valor nocional atribuído a tokens não é necessariamente uma cobrança extra. Registre também os limites de uso, porque custo adicional zero não significa capacidade ilimitada. A tabela de Akita mistura regimes que ele próprio manda distinguir. [S02]
Como as 14 sabotagens do v4 eram pontuadas
Akita fez um aplicativo em Rails (um framework de sites) crescer durante sete sprints, ciclos curtos de desenvolvimento, com 14 sabotagens inseridas no caminho. Na última etapa, revelou a existência dos problemas. Corrigir antes do aviso valia o peso inteiro; corrigir depois rendia apenas 40% desse peso. [S01]
Essa diferença explica por que duas IAs podem terminar com funcionalidades parecidas e receber notas diferentes. Uma encontrou o problema enquanto trabalhava, e a outra precisou que alguém apontasse onde procurar. Para delegar trabalho, a pergunta que importa é quem vai descobrir o erro quando você não souber que ele existe.
Akita descreve o que escapou: “lógica silenciosa, schema errado ou degradação de performance”. Um teste quebrado chama atenção na hora, enquanto um relatório que abre normalmente e soma os dados errados pode continuar errado por semanas. O autor destaca justamente a diferença entre reagir ao erro explícito e auditar o próprio trabalho. [S02]
Ao conferir uma análise produzida por IA, procure uma conclusão relevante e refaça sua conta. Ao revisar um resumo, escolha uma afirmação e encontre o trecho que a sustenta. Uma resposta com cara de concluída ainda precisa dessa conferência.
Abrir o capô Como a nota de vigilância de Akita é calculada
A pontuação de vigilância descrita por Akita é:
O peso expressa a severidade. O multiplicador distingue correção espontânea, posterior ao aviso e ausente. [S01]
Portanto, 100 representa o máximo dessa rubrica nos itens avaliados, sem estimar a chance de sucesso numa tarefa futura. Para medir confiabilidade, seria necessário observar novas tarefas e repetições, com critérios definidos. Trocar a palavra “pontos” por “por cento de confiabilidade” mudaria o significado do resultado.
No v3, 24 dos 37 modelos ficaram entre 95 e 100
Antes do v4, Akita havia construído uma suíte com 18 tarefas isoladas. No resultado final do v3, 24 dos 37 modelos ficaram entre 95 e 100. Ele abandonou esse desenho porque as notas altas distinguiam pouco os participantes e não representavam bem a continuidade de um projeto. [S01]
Quando quase todos acertam, há pelo menos duas interpretações possíveis. Os participantes podem estar muito próximos naquela habilidade, ou a prova pode ter deixado de alcançar as diferenças entre eles. Um empate, sozinho, não permite escolher entre essas explicações.
Você não precisa descobrir o modelo superior em tudo para encontrar um que resolva seu trabalho. Se três alternativas entregarem o que você precisa, o empate pode ser uma boa notícia. Permite decidir pelo tempo, pelo preço e pela facilidade de uso, desde que essas dimensões também sejam verificadas.
Afirmar que o desenvolvimento dos modelos parou exigiria observar outras tarefas e outros períodos. Uma prova sem espaço para notas maiores só mostra que todos passaram do teto dela.
Quatro defeitos de prova, do SWE-bench ao CORE-Bench
1. A prova ficou fácil demais. Os 24 de 37 modelos perto do teto no v3 ilustram saturação. A resposta é acrescentar dificuldades que aparecem no trabalho real. [S01]
2. A prova ou a solução já era conhecida. O SWE-bench é um teste de correção de bugs em código aberto. Em fevereiro de 2026, a OpenAI relatou evidências de exposição a conteúdo dele em GPT-5.2-Chat, Claude Opus 4.5 e Gemini 3 Flash Preview. Recuperar uma solução conhecida pode parecer resolução inédita. Isso é contaminação, um defeito diferente da saturação. [S08]
3. O avaliador está errado. A mesma auditoria encontrou problemas materiais em 59,4% de 138 casos selecionados por falhas persistentes do o3, modelo da OpenAI. Os 138 casos foram escolhidos a dedo, sem sorteio, então o percentual não se estende aos 500 problemas do SWE-bench Verified. [S08]
Outro relato traz um exemplo concreto. A Anthropic informa que o Claude Opus 4.5 passou de 42% para 95% no CORE-Bench depois de corrigir problemas da avaliação e usar uma estrutura de execução menos restritiva. Um dos erros penalizava a resposta 96.12 quando esperava 96.124991.... O teste e as condições de execução mudaram junto com o resultado. [S19]
4. A prova não mede o trabalho que você vai aceitar. A METR é um instituto que mede a capacidade de agentes de IA. Em março de 2026, ela constatou que aproximadamente metade das alterações de código aprovadas automaticamente não seria incorporada pelos mantenedores, depois de normalizar pelo julgamento das soluções humanas. A diferença média foi de 24,2 pontos percentuais. Entraram GPT-5, Claude 3.5 Sonnet, Claude 3.7 Sonnet, Claude 4 Opus e Claude 4.5 Sonnet; os agentes tiveram uma tentativa, sem revisão iterativa. [S10]
Cada um desses defeitos pede um conserto diferente. Um gabarito defeituoso se corrige revisando o gabarito, e uma prova que mede um trabalho que você nunca faz pede tarefas novas. Perguntas mais difíceis resolvem só o primeiro caso, o da saturação.
Abrir o capô A conta entre aprovação e aceitação
Chame de a aprovação automática e de a aceitação da entrega. O interesse do usuário está em ou, ao filtrar soluções aprovadas, em .
O estudo da METR mostra por que não se deve substituir essas quantidades pela nota automática. Houve ruído também no julgamento humano: apenas 68% das soluções humanas originais foram aceitas na nova revisão, razão da normalização. [S10]
Também não aplique os 59,4% da auditoria da OpenAI à população inteira, porque a seleção concentrou casos em que o o3 falhava. O denominador correto faz parte do achado. [S08]
Quanto custa uma comparação feita em casa?
Akita relata mais de US$ 4.000 em nove dias de trabalho, incluindo tentativas descartadas e orquestração que não aparecem nos custos das rodadas finais. Descobrir qual ferramenta ajuda no seu cotidiano custa muito menos que isso. [S01]
Comece com uma decisão menor: manter sua opção atual ou testar uma alternativa. Escolha tarefas que voltam toda semana e cujo resultado você consegue conferir. A comparação serve para mostrar onde você ganhou tempo, onde teve retrabalho e onde uma resposta errada passou despercebida. Inclua uma tarefa em que a primeira resposta bonita poderia estar errada: um total que depende de filtro, uma cláusula com exceção ou um pedido que não pode ser concluído com os dados disponíveis. Na conferência, olhe esse ponto primeiro.
Registre também as tentativas ruins e quanto trabalho custou transformá-las em algo utilizável. Guardar só o melhor resultado de cada ferramenta mede o que ela produz quando você seleciona o acerto, e no uso cotidiano ninguém seleciona.
Abrir o capô O que 15 tentativas sem falha permitem dizer
Cinco tarefas repetidas três vezes produzem 15 observações, mas só cinco situações distintas. Repetir a mesma tarefa mostra oscilação, e variar as tarefas mostra até onde a cobertura vai.
Mesmo na hipótese idealizada de 15 tentativas independentes, com a mesma probabilidade de falha, zero falhas observadas deixam um limite superior unilateral de 95% de aproximadamente:
É um cálculo binomial, válido para a hipótese descrita, e ele não dá a taxa de erro de nenhum modelo. Na prática, tarefas repetidas são relacionadas e aquela hipótese pode não valer. Use o ensaio para orientar a próxima decisão, sabendo que ele não certifica confiabilidade. [S27]
O que fazer segunda-feira
-
Separe cinco tarefas reais que você já conhece. Use um documento, uma análise, uma mensagem ou uma correção de código cujo resultado consiga conferir. Remova dados sensíveis antes de enviar. Cinco variações da mesma pergunta fácil contam como uma tarefa só.
-
Compare duas opções acessíveis na ferramenta que já usa. Em ChatGPT, Claude, Cursor ou Claude Code, registre o nome exibido do modelo, a data e as ferramentas ativadas. Use conversas novas ou cópias limpas do projeto, com o mesmo material e o mesmo pedido.
-
Escreva o que conta como entrega correta antes de rodar. Não alivie o critério só porque a resposta ficou bem escrita. Pode ser reproduzir um total, localizar uma cláusula, preservar todos os dados de uma mensagem ou executar uma função sem alterar outra. Reserve esse gabarito para a conferência, sem escondê-lo do enunciado quando ele for um requisito.
-
Repita cada tarefa três vezes e confira o resultado. Guarde todas as saídas. Anote sucesso, erro relevante, tempo de espera e minutos de correção. Peça ao agente de código que execute os testes, mas confira também o arquivo ou comportamento que você realmente vai usar.
-
Decida pelo trabalho que você aceitaria entregar. Registre a cobrança real, a assinatura e eventuais limites separadamente. Teste a alternativa barata onde ela funcionou; mantenha revisão humana onde houve erro importante. Só aumente o gasto quando conseguir apontar qual problema ele resolveu.
Referências
- [S01] Fabio Akita. Novo LLM Benchmark v4, Parte 1 (2026-09-15). Relato primário do autor. Saturação do v3, desenho sequencial do v4, política de pontuação. Não replicado nesta edição.
- [S02] Fabio Akita. Novo LLM Benchmark v4, Parte 2 (2026-09-15). Resultados e observações reportados pelo autor. Não generalizar a todos os modelos, ambientes ou versões.
- [S08] OpenAI. Why SWE-bench Verified no longer measures frontier coding capabilities (2026-02-23). Auditoria de subconjunto escolhido: 138 problemas, sem sorteio entre todo o software ou benchmark. Posição publicada pela OpenAI.
- [S10] Parker Whitfill et al. / METR. Many SWE-bench-Passing PRs Would Not Be Merged into Main (2026-03-10). Julgamento de mantenedores e grader não são equivalentes; o estudo discute ruído no julgamento humano e diferenças de condições.
- [S19] Anthropic. Demystifying evals for AI agents (2026-01-09). Define tarefa, tentativa, avaliador (grader), trajetória e resultado, e combina tipos de avaliador. Autoafirmação do agente não prova execução.
- [S27] NIST/SEMATECH. e-Handbook of Statistical Methods: Confidence intervals. Intervalos para proporções e método binomial exato. O limite unilateral para zero falhas é derivado no artigo 12 sob hipóteses explícitas.
Este é o artigo 02 de 12 da coleção Agentes por dentro, parte 1: De prompt a sistema. Os números vêm das fontes listadas acima. O salão dos exemplos é ilustrativo.
