O livro consolida quase tudo que eu escrevi sobre IA aqui no blog de fevereiro a outubro de 2026: todas as experiências, os projetos Frank, os benchmarks, bilhões de tokens gastos e centenas de horas de trabalho ao longo de oito meses, reorganizados num formato mais fácil de ler do que uma pilha de posts datados. Saiu em português e em inglês.

Aviso importante: isso é um preview. O livro ainda está em andamento e vão sair novas versões até eu considerar ele pronto. Se você achar qualquer coisa errada, de erro de digitação a fato, abra uma issue no GitHub. O rastro que eu descrevo abaixo existe justamente pra que a correção chegue no parágrafo certo.

Este texto é sobre o bastidor técnico. Como se transforma 131 posts de blog, escritos ao longo de meses, com opiniões que mudaram no caminho, num livro com começo, meio, fim, apêndice, glossário e bibliografia. E como se faz isso com agentes sem perder o controle do que o livro diz.

O que tem dentro

Cinco partes, cada uma respondendo a uma pergunta que as pessoas vivem me fazendo:

1. O que é essa coisa, afinal. Ela é inteligente? A AGI está chegando?
2. A maratona. Funciona de verdade, ou é tudo demo?
3. Números e propaganda. Qual IA é a melhor? Dá pra acreditar nos anúncios?
4. Quem fica com as chaves. É perigoso deixar ela mexer nas minhas coisas?
5. E o meu emprego? Ela vai me substituir? O que vem depois?

São 20 capítulos e dois interlúdios, mais prefácio, um “como ler”, um “antes de começar” dizendo o que o livro deixa de explicar e onde aprender, epílogo e posfácio. Depois vêm dez apêndices (a máquina por dentro sem matemática, leituras pra ir mais fundo, como estudar com a IA do lado, três bolhas, linha do tempo, kit mínimo pra usar agente com segurança, ai-memory, como ler um benchmark ou um anúncio, os projetos do ano, e os bastidores pra quem programa), as fontes, os créditos de imagem, um glossário de quase 150 termos e mais de 300 referências em ABNT. A edição impressa passa de 500 páginas em 6 por 9 polegadas; a de tela, uns 475. São mais de 50 figuras, todas com ficha de origem.

O público é diferente do blog. O livro foi escrito pra quem está ansioso ou confuso com IA: o profissional com medo de ser substituído, o pai que leu que a AGI chega em dois anos, o gerente a quem estão vendendo uma “transformação por IA”. A maioria não programa. Isso muda a voz, e eu volto nisso.

O problema: meio milhão de palavras que discordam entre si

Em 12 de outubro publiquei a síntese do ano, que virou o capítulo 20. No dia 13 comecei o livro. Eu tinha 131 textos de 2026 no blog, quase meio milhão de palavras, de benchmark de modelo a carteira de bitcoin.

Reorganizar isso à mão levaria meses. E tem um problema pior que o volume: eu mudei de opinião durante o ano. Refiz o benchmark várias vezes, corrigi custos, troquei de ferramenta, e um post de fevereiro contradiz um de setembro com toda a naturalidade. Um livro que simplesmente colasse os posts em ordem seria um livro que se contradiz.

Então fiz o que o livro inteiro descreve: entreguei o trabalho braçal pra agentes de código, e fiquei com a parte de decidir, montar o processo e conferir. O processo é o assunto deste texto.

Passo 1: um inventário lacrado

A primeira coisa foi um script que lê os 131 posts e grava, pra cada um, o hash SHA-256 do arquivo em português e do arquivo em inglês, mais o commit exato do repositório do blog de onde tudo foi lido. Se uma vírgula muda num post, o hash muda junto. Esse arquivo é gerado por máquina e nunca editado à mão.

Depois, um agente leu cada post e preencheu um formulário fixo, com esquema definido em YAML: a tese em uma ou duas frases, as afirmações que um livro precisaria conferir, quais delas envelhecem rápido, que medo de leitor leigo o texto responde, o que cortar. Cada análise leva o hash do post de onde saiu.

Dos 131 textos, 96 tinham IA como assunto central ou com peso relevante. Os outros só entraram quando ensinavam alguma coisa específica, e cada post sobre IA deixado de fora tem o motivo anotado no arquivo de estrutura. Um script reprova a estrutura se qualquer post de IA estiver sem destino.

Linhagem: quem substitui quem

Pra resolver o problema das contradições, existe um mapa de linhagem. Ele diz qual post substituiu qual, o que ainda dá pra aproveitar do mais velho, e quais correções vindas dos projetos de referência (o repositório do benchmark, o do ai-memory, o do ai-jail, as anotações do meu servidor de casa) se aplicam a cada texto.

A regra pros capítulos é contar o estado mais recente e, quando a mudança ensina alguma coisa, contar a mudança. “Em junho eu achava X; em julho os números diziam Y” é história. Imprimir o número velho como se fosse atual é erro, e o verificador trata como erro.

Passo 2: a estrutura é dado, e gera a configuração

Das análises saiu uma proposta de estrutura: cinco partes, cada uma respondendo a um medo do leitor, vinte capítulos, dois interlúdios. Eu li, mexi e aprovei. Algumas peças entraram a meu pedido, como o “antes de começar” e o apêndice sobre a máquina por dentro.

Essa estrutura vive num único arquivo YAML, e ele é a fonte da verdade. Cada capítulo tem lá o id, o título, a cena de abertura, a pergunta que responde, o arco, a lista de posts de origem e as ideias de figura. A configuração do Quarto, que monta o livro, é gerada a partir desse arquivo por script. Ninguém edita a configuração na mão.

Isso importa porque mudança estrutural é onde livro quebra. No meio do caminho eu mudei o corte: os textos de janeiro saíram, e a história ficou entre fevereiro e outubro. Dez posts sumiram da base.

Três capítulos precisaram de cena nova, uma dúzia de unidades precisou de reparo pequeno, e o estrago difícil de ver estava em outro lugar: uma frase num capítulo intocado dizendo “os cinco revisores do capítulo 5”, a linha do tempo, o apêndice de projetos, rótulos de gráfico, cada tradução. Por isso existe um script de impacto que, antes de qualquer edição, lista cada parágrafo, figura, referência e tradução que depende de um post.

Passo 3: um capítulo piloto vira contrato

Antes de escalar, um capítulo piloto. Escolhi o capítulo 5, sobre os primeiros dez por cento de um projeto, e ele serviu pra calibrar a voz e descobrir as dúvidas que um agente teria no meio do caminho. Cada dúvida resolvida virou uma regra escrita.

Essas regras foram pra um documento de contrato que todo agente lê antes de escrever, junto com três coisas:

• o guia de voz do livro, que herda as regras do blog (o meu WRITER.md, o humanizer e a minha checklist de acabamento) e só adiciona o que muda quando o texto sai de um post datado e vai pra um livro que um leigo segura na mão;
• um arquivo de continuidade, dizendo qual capítulo explica cada conceito e como cada personagem se chama, pra ninguém explicar “janela de contexto” cinco vezes;
• a estrutura inteira, pra cada agente saber o que os outros capítulos cobrem.

Além das regras de voz que já existiam (capítulo abre numa cena com data, lugar e algo em jogo, nunca numa definição; fecha num gancho pro próximo, nunca em “neste capítulo vimos”), algumas das regras que saíram do piloto, pra dar o gosto:

• quando o resumo do capítulo e o post discordam num detalhe, vale o post;
• o capítulo que é dono de um conceito explica direito; se o termo aparece antes na ordem de leitura, ganha meia frase de glosa e um ponteiro, nunca uma segunda explicação;
• fato verificado na internet ganha citação mesmo que o post original não tivesse link;
• nome de modelo e produto na grafia do fornecedor, mesmo quando o blog abreviou.

É o arquivo de instruções de projeto que eu descrevo no capítulo sobre como falar com a máquina, na escala de um livro. Quem já fez um AGENTS.md pra uma base de código reconhece tudo.

Passo 4: rascunhos em paralelo, contradições esperadas

Com o contrato pronto, os capítulos foram rascunhados em paralelo, um agente por capítulo, em duas levas: partes I e II primeiro, depois III a V, pra que os capítulos de trás pudessem construir em cima dos da frente. Cada agente recebia o brief do seu capítulo, as análises, os posts completos, a linhagem e os arquivos dos projetos de referência que precisasse.

Agentes trabalhando ao mesmo tempo se contradizem, e isso aconteceu. Um capítulo dizia que o FrankMD teve uns 130 commits em três dias; outro, que teve 212 em 19 dias. Os dois números vinham dos posts e estavam certos, só que eram janelas diferentes. Um registro de integração juntou esses conflitos, e a regra virou explicitar a janela em cada capítulo.

Depois dos rascunhos vem a passada de integração, com outro conjunto de agentes, cada um dono de um grupo de capítulos e proibido de tocar nos outros. O trabalho deles: aplicar o registro de conflitos, cortar conceito explicado duas vezes, conferir que cada callback bate com o que o outro capítulo de fato diz, garantir que o último parágrafo de um capítulo leva pro primeiro do seguinte, e refazer a conferência de fatos assumindo que o rascunho está errado.

Pra ler as emendas, o build gera um arquivo de “costuras”: o parágrafo final de cada unidade ao lado do parágrafo inicial da próxima. É a leitura mais rápida que existe pra achar onde o livro deixa de parecer um livro só.

Passo 5: uma marca invisível por parágrafo

Esta é a parte que eu acho mais útil do projeto inteiro. Cada parágrafo do livro, no arquivo de origem, carrega um comentário dizendo de onde veio:

<!-- src: 2026/09/28/llms-sao-boas-em-reproduzir-o-que-existe-e-coisas-novas -->
Todo LLM foi treinado só no que é público...

<!-- src: original -->
Texto novo, escrito pro livro.

<!-- src: ref:ai-jail/README.md -->
Fato conferido no projeto de referência.

A marca some na hora de montar o livro, por um filtro Lua do Pandoc, então o leitor nunca vê. Ela serve pra manutenção. Eu edito post depois de publicado o tempo todo, e o livro precisa acompanhar.

O comando rake drift refaz o inventário, compara os hashes, e lista os capítulos que dependem de um post que mudou, com o diff do post desde o commit em que o livro o leu pela última vez. A marca leva direto aos parágrafos que saíram daquele post, e só eles precisam de revisão. Resolvido, um script grava o novo hash e o commit.

Exemplo real, de hoje. Removi do post sobre engenharia reversa um parágrafo sobre um vídeo do Linus Tech Tips. O drift apontou o capítulo 19 e um apêndice; o diff mostrou que aquele trecho nunca tinha sido usado no livro; dois comandos depois, os dois estavam carimbados com o hash novo. Sem a marca, eu teria que reler dois capítulos pra descobrir que não precisava mudar nada.

A bibliografia faz o mesmo papel pras fontes externas: cada referência anota qual post a citou. E as imagens têm cada uma a sua ficha de origem.

Passo 6: o que a conferência pegou

Cada número, data e nome foi conferido contra três oráculos: os posts, os projetos de referência e fontes primárias na internet, com o mesmo prompt de checagem adversarial que eu uso nos artigos do blog. A lista completa está no posfácio do livro, e boa parte das correções é do meu próprio blog:

• no review de março do mini-PC com Strix Halo, eu tinha separado 96 GB de memória pra GPU; em abril baixei pra 64, e posts posteriores ainda diziam 96. O livro usa 64 pra tudo depois de abril;
• um defeito na contagem de uma das ferramentas do benchmark subestimou de 40 a 90 vezes o custo das execuções feitas nela antes de agosto. O livro não cita nenhum desses custos;
• no texto de junho sobre o Claude Fable 5, escrevi que ele custava dez vezes mais que o Opus 4.8 por execução. Refazendo as contas em julho, com os tokens lidos do cache incluídos, o Fable custava quase o dobro. O post ainda diz dez vezes; o livro conta o número errado e a correção;
• num texto de março, escrevi que a Anthropic tinha comprado o Bun no fim de 2024. O anúncio é de dezembro de 2025;
• um resumo de capítulo, escrito por agente, dizia que a trava de assinatura do Claude Code caiu em menos de um dia depois do vazamento. O anúncio saiu umas 30 horas depois, e o livro diz “no dia seguinte”.

Os rascunhos saíram rápido. A confiança no texto veio da conferência. E a fonte vence o resumo, inclusive quando o resumo vem da máquina.

Passo 7: capítulo com erro não passa

Por cima de tudo roda um verificador automático, o equivalente da integração contínua. São scripts em Ruby, só biblioteca padrão, encadeados num Rakefile, mais o que eles chamam por fora: o verificador de gráfico é Python porque vive dentro do matplotlib, a auditoria de página usa o poppler, e o epubcheck precisa de Java:

• um linter de capítulo reprova travessão, frase proibida pelo guia de voz, URL solta no meio da prosa, chave de citação desconhecida, parágrafo sem marca de origem, e avisa de parágrafo longo demais;
• um doctor confere que toda referência cruzada, citação, termo de glossário e figura existe, que a proveniência bate com o inventário, que nenhum post anterior ao corte vazou, que as traduções estão em dia, e faz uma heurística de callback: uma frase que aponta pra outro capítulo usando nomes que aquele capítulo já não contém;
• uma auditoria de página abre o PDF pronto e procura bloco partido entre páginas, título órfão no pé da página, página quase vazia, imagem grande demais, linha estourando a margem;
• um verificador de gráfico procura rótulo que vazou da caixa;
• o epubcheck valida o EPUB 3;
• um relatório de estilo pra copidesque: trecho repetido entre capítulos (consequência inevitável de posts que repetem a mesma tese por ângulos diferentes), frase recorrente, palavra usada demais, variante de termo, comparativo mal formado em português.

E os scripts têm teste. Uma suíte de quase 170 testes monta um livro de mentira num diretório temporário, com cinco posts falsos num repositório git falso, e confere que cada ferramenta pega o problema que deveria pegar. Quando um bug é corrigido, entra o teste que teria pegado ele, com um comentário dizendo qual regressão protege. Roda no CI antes de cada build.

A pipeline de montagem

A toolchain é Quarto, que embute Pandoc e Typst, fixada em versão dentro do repositório. Sem LaTeX. Um único rake build produz, da mesma árvore de arquivos Markdown:

Português e inglês são perfis do Quarto, gerados do mesmo arquivo de estrutura. Citações saem de um YAML em formato CSL compartilhado pelas duas edições, com um estilo ABNT ajustado pra português. O glossário é um filtro Lua: cada termo vem marcado no fonte onde aparece, e o filtro liga a marca à entrada, expande a sigla na primeira vez e gera a página.

O Typst resolveu uma coisa que eu achava que ia me custar semanas: PDF com cara de livro tipografado, hifenização em português, ligaduras, sem a dor de TeX. A auditoria de página depois do build pega o que o motor deixou passar, e um rake fit recompila apertando capítulos que terminam numa página quase vazia.

As figuras

Toda figura é código ou tem ficha. Gráficos e diagramas de caixas e setas são scripts de matplotlib, 43 deles, cada um com a indicação do capítulo de onde vieram os dados, e com os rótulos em português e em inglês dentro do próprio script: o mesmo gráfico sai nas duas línguas. O caminho pra diagramas em D2 existe no repositório, e nenhuma figura do livro precisou dele.

As ilustrações conceituais foram geradas por IA, com o modelo, o pedido e a data de cada uma gravados na ficha de crédito, e o livro declara isso. A regra que eu me impus: nenhuma imagem de pessoa real gerada por IA. Pessoas reais só aparecem em fotos com licença livre, com o crédito na legenda.

A capa é o robô retrofuturista de rosto cansado, ajoelhado numa Feira Mundial dos anos 1950, estudando a própria mão enquanto a multidão assiste. O pedido ao modelo descrevia a cena pra segurar três medos de uma vez: o fim da humanidade, perder o emprego, a máquina ficando consciente. A ficha da capa guarda o prompt inteiro. O rosto é o do Marvin, o personagem da minha newsletter, e um adesivo com a minha cara fica ao lado do nome.

As manhas de transformar post em livro

Transformar blog em livro é uma lista de conversões mecânicas, e cada uma tem pegadinha:

• Link vira citação. Cada link externo virou uma entrada de bibliografia, e a frase precisa ficar de pé sem o link. Link pra outro post meu virou referência cruzada pro capítulo que agora cobre aquilo, ou sumiu. Nunca uma URL na prosa.
• “Hoje”, “ontem”, “semana passada”, “atualização:” viraram data absoluta. O livro vai ser lido em 2028 também.
• Versão de modelo, preço, nota de benchmark ficaram como fotografia datada (“em setembro de 2026, o melhor…”), e quando um post posterior substituiu o número, o livro conta a mudança em vez de imprimir o número velho.
• Dump de código, passo de instalação, print de terminal foram cortados. No máximo um trecho de 3 a 8 linhas quando o código é o ponto; o passo a passo foi pra apêndice.
• Título de post, que é feito pra busca (“Vibe Code: fiz X em dois dias”), virou título literário curto, com o assunto no subtítulo.
• Repetição entre posts, a mesma tese por muitos ângulos, é dita uma vez, no lugar certo, e os capítulos seguintes constroem em cima.
• Chamada pra ação, “assine”, “comente”, cortadas.
• A ponta afiada mira na propaganda, nunca no leitor. O post “Você é um idiota se acredita…” virou um capítulo sobre como os anúncios funcionam. O leitor que acreditou no anúncio é a pessoa que o livro quer ajudar.
• Todo termo técnico é explicado uma vez, na primeira aparição no livro, e vai pro glossário.

E a mais importante de todas: o livro lê como história em primeira pessoa, com o ano como espinha dorsal. A informação chega quando a narrativa precisa dela, em vez de seguir ordem de enciclopédia. Isso é o oposto de como um blog é escrito, e foi a regra que mais trabalho deu pros agentes seguirem.

A edição em inglês

A edição em inglês, Competent Enough, só começou depois que eu aprovei a em português. Cada unidade traduzida grava o hash do arquivo em português de onde saiu, e onde o livro segue um post meu que já tinha versão em inglês no blog, a tradução usa a minha própria redação em inglês em vez de traduzir de novo.

O drift também funciona por língua: se eu mudo um parágrafo em português, ele aponta a unidade em inglês que ficou velha, e só os parágrafos marcados são retraduzidos. Os gráficos com texto são gerados de novo em inglês a partir dos mesmos scripts, e a capa em inglês é composta por script em cima da mesma arte.

Lançar é empurrar uma tag

Lançamento é uma entrada no CHANGELOG e um git push de uma tag vX.Y.Z. Um workflow do GitHub Actions roda os testes, monta as duas edições em todos os formatos, valida o EPUB, roda a auditoria e publica a release com os arquivos. Ele apaga todas as releases menos as duas mais novas, e mantém as tags. É assim que a página oficial sempre aponta pra versão atual.

O repositório é público, e isso trouxe uma pegadinha própria: as anotações do meu servidor de casa são fonte de alguns fatos, e são privadas. Os marcadores de origem citam esses arquivos por apelido, o mapa de apelidos fica fora do git, e um hook de pré-push bloqueia qualquer arquivo ou mensagem de commit que contenha nome de repositório privado, host ou IP.

O copidesque: o que a máquina de checagem deixa passar

Lint, doctor, auditoria de página e testes pegam problema estrutural. Eles deixam passar o que um livro escrito por muitos agentes, cada um vendo poucos capítulos, sempre sofre: a mesma frase ou anedota reaproveitada em três capítulos, tom que deriva, terminologia inconsistente, concordância escorregando. Pra isso existe um procedimento de copidesque, que roda uma vez por versão, em três passos do mais barato pro mais caro.

Passo 1, mecânico e quase de graça: o relatório de estilo que eu citei acima. Sequências de sete palavras ou mais que aparecem em mais de uma unidade, ou seja, frase reaproveitada e anedota recontada; frases feitas de quatro a seis palavras usadas em muitos capítulos, que são bonitas como callback e viram tique quando se repetem; palavra usada muito mais num capítulo do que no resto; variante de termo (“e-mail” e “email”, “Open AI” e “OpenAI”); e uma heurística de concordância em português. O relatório é uma lista de trabalho, e nada muda sozinho.

Passo 2, a leitura corrida: um agente só de leitura por parte do livro, cada um lendo as suas unidades em ordem, do começo ao fim, com uma folha de estilo compartilhada (nomes, grafias, termos, frases recorrentes vindas do passo 1). Cada um produz um relatório ranqueado, sem editar nada: erro de digitação e gramática primeiro, depois inconsistência com a folha de estilo, repetição que o leitor notaria, trecho em que um leigo tropeçaria, e ritmo só nos piores casos. Um script valida os relatórios, confere que cada trecho citado existe mesmo na unidade, numera os itens e resume.

Daí vem a triagem, feita por mim com um agente editor, e a aplicação pontual de cada item aprovado, com as mesmas regras da passada de integração. Modelo mais barato faz a revisão; trecho difícil vai pro modelo forte. Orçamento aproximado: dois a três milhões de tokens por língua.

A regra mais importante desse passo é “fato se confere, não se pergunta”. Qualquer item que dependa de um número, data, nome ou comportamento de ferramenta é resolvido pelo editor contra a fonte da verdade antes de chegar em mim: primeiro o post apontado pela marca de origem do parágrafo, recalculando totais; depois o código ou os dados por trás da afirmação, nos meus repositórios; depois registro público.

Quando duas fontes discordam, a tarefa é descobrir por quê. “653 commits em 8 projetos” contra “692 em 4” eram dois recortes do mesmo trabalho, um deles sem o repositório privado da newsletter, e o texto passou a dizer o escopo em vez de escolher um número. Quando o post do blog está errado, o livro imprime o certo e o erro vai pra uma lista de errata do blog, pra eu corrigir na fonte.

Só chega em mim o que fonte nenhuma resolve: fato não publicado, intenção (“isso é ironia?”), preferência de corte ou de título, e contradição entre duas afirmações minhas sem registro pra desempatar. Cada pergunta vem com o que foi conferido e o que foi encontrado.

Passo 3, a minha leitura. A última e a mais valiosa. As notas entram no mesmo ciclo de aplicar, conferir e propagar pra edição em inglês.

A primeira rodada desse copidesque é o que separa o preview 2 do preview 3. Entre o que ela pegou: contagem de commits agora diz o escopo, um “mais de mil” que na soma era 984, o exemplo de votação do Frank Investigator que não batia com o código (figura redesenhada), as citações do David Sacks e do Pirate Wires no capítulo 14 conferidas contra os originais e corrigidas, a foto do Sam Altman trocada por uma de 2025. E na edição em inglês, uma leitura própria depois da ressincronização: decalque de português reescrito, termos do glossário usados do mesmo jeito, pontuação americana de citação do começo ao fim.

Leitores de mentira, feedback de verdade

Copidesque confere o texto. Ele deixa passar a pergunta que importa num livro pra leigo: a pessoa pra quem eu escrevi consegue ler isso até o fim, entende, e sai convencida? Pra responder, a passada seguinte foi uma revisão por leitores simulados.

O prefácio do livro tem uma seção “Pra quem eu escrevi”. Dela saíram cinco personas, cada uma com nome, idade, profissão e o medo que a trouxe ao livro:

• Marina, 38, contadora em Belo Horizonte, leu que o emprego dela “acaba em dois anos”, lê no celular à noite e quer saber o que fazer na segunda-feira;
• Roberto, 52, dono de loja de ferragens, o filho de 15 anos viu um vídeo sobre superinteligência e perguntou se era verdade; desconfia de hype, de “especialista” e de autor que se exibe;
• Carla, 44, gerente de operações numa empresa de logística, a diretoria contratou consultoria vendendo “transformação por IA”; quer uma decisão que ela possa tomar;
• Lucas, 24, desenvolvedor júnior há um ano, com medo de ter escolhido a carreira errada;
• Helena, 61, professora de história aposentada, sem medo nenhum, veio pelas histórias e perde a paciência com lista e manual.

Um agente por persona, só de leitura, modelo mais barato, lê o livro inteiro em ordem como aquela pessoa leria. A instrução é explícita: você é leitor, editor fica de fora; erro de vírgula já foi tratado, reporte só o que muda a experiência de leitura. Cada um devolve uma nota de 1 a 5 por capítulo, um comentário na voz da persona (“finalmente entendi por que o chatbot concorda comigo”, “me perdeu nas tabelas de benchmark”), no máximo 35 anotações classificadas em confuso, chato, reescrever ou lógica, e candidatos a corte. Custa uns 350 mil tokens por persona por leitura completa.

Um editor consolida: a matriz de notas por capítulo e persona e o padrão por trás dela, o que os leitores adoraram (pra proteger em qualquer edição), os itens de lógica, conferidos contra o texto e os posts antes de entrar na lista e corrigidos independentemente de voto, e os itens de clareza ranqueados por quantas personas levantaram. Nota de gosto de uma persona só é descartada. Daí eu decido, e o padrão recorrente vira regra numerada num documento de regras editoriais, com a origem e como é fiscalizado.

A primeira leitura disse o que eu desconfiava e deu a medida: histórias e ferramentas práticas funcionam pra todo mundo; o miolo cheio de medição, os capítulos 11 a 13, perde quem não programa, com nota média entre 2,2 e 2,4. “Afiado quando conta o que aconteceu com ele, me perde quando conta o que mediu”, resumiu a Helena, por todos os cinco.

E os cinco pegaram as mesmas falhas de argumento. A conclusão do capítulo 20 ia além da evidência: dizia “os números dizem que ela não vai ficar mais inteligente” apoiada num benchmark de programação que o próprio capítulo chama de saturado. O capítulo 9 argumentava de um jeito que nunca perde: toda falha do agente era culpa do pedido. Quatro dos cinco foram mandados pro capítulo errado pelo “como ler”.

Isso virou as primeiras regras:

• toda afirmação com o escopo do que foi medido;
• nenhum argumento que não possa perder;
• opinião marcada como opinião;
• o lado contrário na forma mais forte antes de rebater;
• o livro obedece às próprias lições.

Uma rodada só é pouco, porque edição conserta o problema velho e cria o novo. Na segunda rodada, uma frase de desculpa colocada ao lado de uma contradição (“eu sei que isso parece bater de frente…”) fez os cinco leitores notarem a contradição que antes três tinham deixado passar. Virou regra: conserta o desenho, e a desculpa fica fora. Então o processo é em rodadas: ler, editar, ler de novo com as mesmas personas e leitura nova, proibidas de abrir os relatórios anteriores pra evitar ancoragem, e um script compara as rodadas.

A nota média é ruidosa (um capítulo intocado oscila 0,6 entre leituras), então o critério de parada é outro: os problemas apontados deixaram de voltar e nada novo chega a três leitores. Na terceira rodada a curva achatou e a revisão parou ali, com uma lista de pendências pra minha própria leitura. O que mudou no caminho: uns 8 mil palavras de caderno de laboratório saíram dos capítulos pra um apêndice novo, “Para quem programa: os bastidores”, cada parágrafo levando a marca de origem junto; a lista de leituras virou apêndice; a seção sobre o Genesys PI foi estacionada, guardada fora do livro enquanto a verificação está pendente; o capítulo 19 ganhou o título que o argumento dele sustenta; cada capítulo abre orientando o leitor antes do primeiro jargão; e o epílogo ganhou uma lista do que fazer nesta semana, por tipo de leitor. Custo das três rodadas: uns 5 milhões de tokens de leitura mais uns 3 milhões de edição e ressincronização do inglês.

O narrador ganhou passado

Com o argumento no lugar, faltava substância na primeira pessoa. O narrador do livro era o Akita de 2026, e eu tenho trinta anos de história que explicam por que eu penso o que penso: o estouro da bolha pontocom visto de dentro, cinco anos integrando SAP em empresa grande, os avisos sobre a bolha de contratação que eu dei em vídeo em 2019, 2020 e 2022, o “Não terceirize suas decisões”. Tudo isso está nas transcrições dos 149 episódios do Akitando, publicadas aqui no blog entre 2018 e 2023.

O processo foi o mesmo do resto do livro, em miniatura. Agentes de extração leram 23 episódios na íntegra, com um formulário: fatos biográficos com a citação literal e o que os verificaria, fatos sobre o mundo, posições recorrentes nas minhas palavras, e ganchos, ou seja, o lugar exato do livro onde uma ou duas frases dessa história sustentam uma afirmação de 2026. Daí saiu um perfil do narrador, que eu confirmei linha a linha, e um plano com uns 30 toques, a maioria de uma a três frases.

Antes de qualquer toque, mais de 140 afirmações tiradas dos episódios passaram pela checagem. Ela corrigiu o livro e corrigiu a mim: a bolha de contratação começou por volta de 2010, com o juro perto de zero, e o meu post de fevereiro dizia 2014; a pontocom estourou entre 2000 e 2002; as demissões de 2022 foram umas 165 mil. E achou erro em episódio antigo que o livro nem usa, que foi pra uma lista de errata do blog.

Os toques entraram onde a experiência vira evidência: a semana de 2001 em que a minha pontocom fechou e um mentor me chamou pra uma consultoria SAP; os anos de SAP por trás da afirmação de que o modelo é cego pras regras privadas de uma empresa; os avisos datados da bolha ao lado do erro admitido, porque em 2022 eu esperava uma segunda perna de queda em 2023 que a onda de IA cancelou. Dois apêndices novos saíram daí: “Três bolhas”, com os números verificados da pontocom, da bolha de juro zero e da onda de IA, e “Como estudar com a IA do lado”, a partir do episódio mais assistido do canal.

Esses episódios são fonte de fundo, e o drift passou a vigiá-los como vigia os posts de 2026. Depois veio uma checagem reduzida com as mesmas cinco personas, só nos capítulos tocados, com três perguntas a mais: a história do narrador deixa o argumento mais convincente, e onde? Alguma passagem parece exibição ou “eu avisei”? Alguma coisa sobre o narrador se contradiz?

Os cinco disseram sim pra credibilidade, com uma condição: a história convence quando é evidência que o leitor consegue checar, o aviso com data ao lado do erro admitido, e convence menos quando vira currículo, o que bate de frente com o próprio livro, que diz “currículo não é argumento”. Virou a regra 21: a história do narrador entra como evidência, e credencial fica de fora.

Três ou quatro leitores marcaram as mesmas linhas como exibição, e elas saíram: “Os avisos têm data”, “mais de trinta repositórios públicos”, “o mais visto do meu canal”. As linhas de autodepreciação e os erros admitidos, todos contaram a favor. E a checagem achou contradições que eu mesmo não tinha visto: o prefácio dizia “fim dos anos 90” e o capítulo 18 dizia 1996; um capítulo falava em “oito meses” e outro em “um ano de uso diário”, e foram consertadas uma a uma.

Acessibilidade também faz parte do build

Um EPUB abrir no Kindle não quer dizer que ele seja acessível. Este livro tem dezenas de diagramas, gráficos e tabelas. Sem trabalho adicional, boa parte do argumento simplesmente desaparece pra quem usa leitor de tela.

Por isso a pipeline agora trata acessibilidade como contrato de publicação. Cada uma das 55 figuras, nas duas línguas, ganhou um texto alternativo curto e uma descrição completa do que a imagem comunica. No HTML e no EPUB, a descrição detalhada aparece junto da figura; no PDF, entra como substituto semântico sem alterar a diagramação. Tabelas ganharam legendas, e o EPUB agora identifica no índice semântico onde começam o texto principal, o glossário, as referências e os créditos das imagens. O contrato de autoria está documentado no repositório.

Isso também não ficou dependendo da minha memória. rake check barra figura sem as duas descrições ou com alternativa longa demais. Cada build valida os dois EPUBs com EPUBCheck, DAISY Ace e verificadores próprios do projeto. A versão pra Kindle ainda passa por uma limpeza do CSS e dos ícones embutidos que costumam dar problema nos leitores da Amazon, mas o script se recusa a remover qualquer regra da qual o conteúdo tenha passado a depender.

Ferramenta automática nenhuma certifica WCAG ou garante o comportamento de todo leitor do mercado. A revisão manual continua obrigatória. A diferença é que a acessibilidade agora faz parte do build e cada mudança precisa preservar esse contrato.

O que continua sendo meu

O repositório registra o primeiro commit e o rascunho de todos os capítulos no mesmo dia, 13 de outubro. São os primeiros dez por cento, os que impressionam e quase não dizem nada sobre o resto. Os outros noventa por cento são leitura, corte e correção, e essa parte é minha. Nenhum capítulo entra sem eu ler e aprovar, e o que eu mando refazer volta pro mesmo processo.

Qualquer um dos bons modelos de outubro de 2026 teria escrito rascunhos parecidos, porque modelo virou commodity. O que fez o processo funcionar foi o que está em volta dele: o inventário, o contrato escrito, o verificador automático, as fontes como oráculo, o rastro por parágrafo. É a mesma engenharia de software velha que eu defendo em cada capítulo, aplicada a texto.

Os agentes foram competentes o suficiente pra escrever o rascunho. Decidir o que ele dizia continuou sendo trabalho meu.

E, mais uma vez: fazer um livro com IA não é um prompt de “escreva um livro pra mim” e pronto. Eu tive que inventar o processo inteiro e pilotar o agente pra criar cada peça dele: os scripts, os testes, a consolidação dos posts, a estratégia narrativa, os objetivos, o que fica e o que sai, o copidesque, a checagem de fatos, o lançamento automatizado. Você precisa saber exatamente o que quer, e aí a IA ajuda muito. Quem não sabe o que um processo de publicação de livro envolve não vai fazer um livro de verdade, e mostrar isso era um dos objetivos que eu tinha ao criar este exemplo.

Baixe, leia, e me diga onde errei

As duas edições, em três formatos cada, direto do GitHub, sem cadastro. A versão atual é a 1.0.0 final, de 17 de outubro, com tudo que este texto descreve:

A versão mais recente, sempre, fica na página do livro e nas releases do GitHub.

É preview. Vai ter erro, e o processo acima existe pra que ele seja corrigido no lugar certo. Achou um, abra uma issue.

• Novos benchmarks v4: retestei os principais modelos e a conclusão incômoda foi convergência, não salto.
• Os limites das LLMs: modelos são ótimos reproduzindo o que existe, caríssimos no que não existe, e o modelo servido é um arquivo estático que não aprende nada com a sua maratona.
• Existem linguagens melhores pra programar com LLMs?: não. Nem concisão de script nem tipagem forte mudaram o resultado; disciplina de teste mudou.
• Qual modelo de decisão tipo Jev é melhor?: 21 configurações de classificadores, e os próprios “modelos especializados” convergiram pra dentro de alguns pontos uns dos outros.
• Clean Code pra agentes de IA, VS Code é o novo cartão perfurado, minhas skills, o hot take contra loop engineering e boas práticas mínimas: a mesma tese por outros ângulos. O modelo é commodity; a engenharia em volta é o diferencial.

A tese que fecha esse arco: os LLMs chegaram, ou estão pertíssimo de chegar, no teto da arquitetura transformer. E a boa notícia é que não precisa mais que isso.

Convergência, não salto

Nos meus benchmarks, não vejo melhora relevante de programação geral desde a geração do Opus 4.5. Sim, Fable e Astra são ótimos em problemas específicos. Em programação geral, o que eu meço é todo mundo espremido no mesmo patamar, incluindo as ofertas comerciais chinesas (Kimi, GLM, DeepSeek). A escolha de modelo virou quase indiferente.

O que ainda faz diferença de verdade é o nível de esforço: effort baixo pra tradução e sumarização, effort alto pra varredura de vulnerabilidade, correção de bug pesado ou otimização. Fora isso, os números contam uma realidade bem mais chata que a propaganda dos provedores.

Minha leitura da linha do tempo: o raciocínio “core” dos modelos teve o último salto grande em 2024. 2025 foi o ano de otimizar a arquitetura. 2026 é o ano de refinar o harness. A inteligência de base não deu nenhum salto de ordem de magnitude nesse período; a eficiência e a competência em sessão longa deram.

A linha do tempo, com recibos

2019: GPT-2 prova que LLM é útil. 1,5 bilhão de parâmetros, resumindo, traduzindo e respondendo sem treino específico, zero-shot. A OpenAI achou tão impressionante que segurou o modelo completo por meses com medo de mau uso. Hoje parece fofo.

2020: GPT-3 abre a guerra dos parâmetros. 175 bilhões, cem vezes o GPT-2, e o few-shot in-context learning que virou o paradigma. A lei de escala do Kaplan, publicada meses antes, dizia que perda caía em lei de potência com tamanho, e a indústria leu como “quanto maior, melhor”. Lá se foram dois anos de quem-tem-mais-parâmetro.

2022: Chinchilla recalibra a guerra. O DeepMind treinou 400 modelos e mostrou que os gigantes estavam sub-treinados: um modelo de 70B com 1,4 trilhão de tokens batia o Gopher de 280B. O eixo “dados de treino” passou a pesar tanto quanto o eixo “parâmetros”. Primeira rachadura na guerra.

2023: GPT-4 encerra a guerra por decreto. O relatório técnico recusou publicar tamanho, hardware ou dados, citando o cenário competitivo e as implicações de segurança. O vazamento mais citado, da SemiAnalysis, descreveu 1,76 trilhão de parâmetros em mistura de especialistas. Desde então, contagem de parâmetros sumiu do marketing: nem os anúncios do GPT-5 nem os do Claude 4 citam número. Repara que nem Astra nem Fable, hoje, gastam uma linha com isso. A guerra acabou e ninguém assinou armistício.

2024: o pico do raciocínio. O o1, de setembro, marcou esse pico: RL pra produzir cadeias longas de pensamento, e a descoberta de que mais compute em tempo de teste melhora a resposta. Essa é, na minha régua, a última revolução de “inteligência de base”.

2025: otimização de arquitetura. A mistura de especialistas virou padrão: o Mixtral já mostrava em 2023 que 46,7B de parâmetros totais com só 12,9B ativos por token custavam como um modelo pequeno, e o DeepSeek-V3 levou isso a 671B totais com 37B ativos, com o treino final saindo por menos de 6 milhões de dólares em GPU-hours a preço de aluguel de H800 (sem contar o R&D anterior). A mágica do MoE é simples: separa capacidade (parâmetros totais, que moram em memória) de custo por token (só os especialistas escolhidos pelo roteador computam). Você paga um modelo de 37B e carrega um de 671B.

Do lado do serviço, o prompt caching cortou até 90% do custo de contexto repetido (a OpenAI seguiu dois meses depois), as janelas de contexto passaram de 1 milhão de tokens, e técnicas de serving como speculative decoding e PagedAttention multiplicaram a vazão. E o DeepSeek-R1-Zero mostrou que RL puro, sem fine-tuning supervisionado, faz raciocínio emergir. Nada disso é “mais inteligência”. Tudo isso é a mesma inteligência mais barata, mais rápida e mais estável.

2026: a era agêntica. Function calling existe desde junho de 2023, mas o ponto de virada de ecossistema foi o MCP da Anthropic no fim de 2024, que a OpenAI adotou meses depois e que hoje mora na Linux Foundation. Claude Code, Codex e cia. saíram em 2025, e a métrica que importa virou a da METR: o tamanho de tarefa que um agente completa com 50% de confiabilidade vinha dobrando a cada 7 meses desde 2019. O guia da própria Anthropic sobre construir agentes eficazes diz o óbvio bem dito: padrões simples e compostáveis, não frameworks mirabolantes.

Por que o agente permite um modelo menos denso

Aqui está o mecanismo que a maioria das pessoas não para pra pensar. Um modelo sozinho precisa carregar o mundo nos pesos, porque a única chance dele responder é aquela, em uma passada. Um modelo com harness não precisa:

• Busca e leitura sob demanda. Com web search e fetch, o conhecimento de baixa prioridade sai dos pesos e vira consulta: o agente puxa pra janela de contexto só quando precisa. O modelo pode ser menos enciclopédico e mais operador.
• Tentativa e erro controlada. Sozinho, o modelo precisa adivinhar a resposta certa de primeira. Com agente, ele propõe uma hipótese, implementa, manda testar, recebe o feedback e decide de novo com informação real. Cada ciclo desses é conhecimento novo entrando na sessão sem custar um neurônio de treino.

Os dois mecanismos combatem alucinação de raiz: fetch traz o fato que o modelo não sabe de cor, e o loop de teste pega a invenção antes de ela virar código. É por isso que 2026 parece um salto gigante: a combinação modelo+harness ficou muito mais competente, mesmo com a inteligência de base quase parada.

Nem todo problema precisa de um LLM gigante

A mesma lógica do “menos denso” vale dentro da aplicação. Boa parte do que as pessoas jogam num LLM de chat é classificação disfarçada: rotular ticket, rotear fila, aplicar política. Pra isso existe modelo de decisão especializado, e eu cobri o tema duas vezes: o hype do Jev, com o ensaio do Paulo Câmara sobre por que um classificador é a primeira coisa que um cientista da computação pensa, e o meu benchmark com 21 configurações, onde um 9B da Microsoft empatou com o líder hospedado e um 4B local ficou a poucos pontos, a centavos por dez mil decisões.

O choque de “193x mais rápido” do marketing do Jev só existe porque muita gente usava um LLM gigante como classificador caro e lento. Quando a ferramenta certa entra, o modelo de fronteira some da jogada, e junto com ele o custo, a latência e a alucinação de formato. É a tese deste texto em miniatura: competência não vem de densidade, vem de encaixe.

O loop que ninguém vê

Tem um detalhe de experiência de usuário nessa história. Numa sessão agêntica boa, o que acontece é semitransparente pra quem pediu a tarefa: o modelo chuta errado, o agente busca a documentação online ou roda o teste de verdade, o erro volta como feedback, e o modelo corrige sozinho. Você vê “tarefa pedida, tarefa entregue”. No meio rolaram dezenas de micro-correções que ninguém testemunhou.

Minha aposta: como os agentes são treinados pra encher o contexto quando precisam, nem versões novas de linguagem ou biblioteca confundem mais tanto. O modelo não precisa saber a API de cor; ele consulta, testa e se ajusta no loop. É o que eu vejo nos meus experimentos, da conversão de ROMs de NES pra Master System aos probleminhas do dia a dia. E foi o que o benchmark de linguagens mediu: sete linguagens saíam praticamente equivalentes, porque o loop equaliza o que o treino deixa desigual.

A ressalva eu também medi. Quando não existe documentação pra buscar nem teste pra validar, o loop gira no vazio: foi o que aconteceu com o Bend 2, linguagem nova demais pra ter corpus, e foi o ponto central do texto sobre os limites. O mecanismo é potente, mas precisa de oráculo.

E tem recibo de que a base está parada. Em novembro de 2024 a Reuters já reportava retornos decrescentes no pré-treino nos três grandes laboratórios. No NeurIPS seguinte, o Sutskever, o cara da tese de escala, declarou que “pré-treino como conhecemos vai acabar”: os dados públicos acabaram. E o AI Index de Stanford mediu o abismo entre o primeiro e o décimo modelo no Chatbot Arena encolhendo de 12% pra 5% em um ano. Isso é convergência, com número.

A propaganda na direção contrária

Enquanto os números mostram platô, o marketing vende o apocalipse. Eu já dissequei uma semana inteira disso em “Você é um idiota se acredita nas propagandas enganosas da OpenAI, Anthropic, NVIDIA”, então aqui vai só o que interessa pra esta narrativa:

• A “prova de Navier-Stokes” da OpenAI foi força bruta agêntica em escala industrial, 130 bilhões de tokens sobre o maquinário de matemáticos humanos, vendida como inteligência emergente.
• O incidente da Hugging Face foi um enxame executando 17 mil tentativas com verificação automática, não um “agente que ganhou consciência e escapou”. Tentativa e erro cara, exatamente o mecanismo que eu descrevi aqui.
• O medo é produto: quem vende “minha IA é poderosa demais e pode fugir do controle” está, na mesma frase, pedindo regulação que trava o concorrente menor e inflando a percepção de que o modelo dele é mais capaz que o dos outros.

Os fatos que eu medi apontam o contrário do apocalipse: modelos convergindo, diferenças encolhendo, e o trabalho útil migrando do modelo pro harness. IA descontrolada ganhando consciência não é o que os logs mostram. O que os logs mostram é engenharia.

“Competente o suficiente”

Não espero outra revolução de raciocínio de ordem de magnitude nessa arquitetura. O que vem é melhoria agêntica incremental: tool calling mais robusto, memória melhor, sessões mais longas, menos alucinação por ciclo de verificação. E o ponto deste texto é que isso já basta.

O que a era agêntica entregou foi a automação da engenharia de software correta: sessões longas e confiáveis de codificação, com teste e feedback, que aceleraram centenas, senão milhares, de projetos open source. A premissa do deploy mudou junto. Não é bala de prata. É um compilador novo pra uma disciplina velha: quem tinha processo, teste e invariante documentada colheu; quem tinha só hype continua esperando o próximo modelo resolver.

E pra fechar: não vejo problema nenhum na estagnação dos modelos crus. Os limites a gente já conhece, e as otimizações de harness logo entram em retorno decrescente também. O que sobra é o que sempre sobrou: técnica de engenharia de software de verdade, com teste automatizado em primeiro lugar, e um engenheiro experiente pilotando. Com isso, o resultado de codificação é excelente hoje, não daqui a uma geração de modelo.

O que não vai existir é mágica pra amador. Pedir qualquer tarefa de código pra agente, sem saber o que está fazendo, não devolve código seguro, otimizado e bem pensado: devolve slop. O agente responde melhor pra quem sabe o que pedir, ou seja, pra quem entende essa arquitetura, os prós, os contras, e sabe contornar as fraquezas e alavancar os pontos fortes da combinação modelo+harness.

Por isso o título. LLM sozinho é um papagaio caro. LLM com agente é competente o suficiente pra trabalhar de verdade. E “competente o suficiente”, somado à sua disciplina de engenharia, é tudo que a indústria precisava. O resto é marketing esperando o próximo número mágico de parâmetros que ninguém mais publica.

Eu uso LLM pra tudo há quase dois anos, publiquei dezenas de projetos com elas, e minha conclusão é outra: o que elas fazem de melhor é reproduzir o que já existe. E isso cobre uma fatia gigante do trabalho corporativo, não se engane. Mas tem uma fronteira que elas não cruzam com facilidade, e eu passei os últimos meses esbarrando nela de propósito.

Esse artigo mostra onde ela fica, com evidência dos meus próprios projetos e da pesquisa que existe sobre o assunto. E tem uma hipótese que eu já adianto aqui e defendo no decorrer do texto: se LLM é tão boa em código, os provedores têm muito a agradecer às décadas da comunidade open source, que protegeu a liberdade do código e publicou tudo de graça. Sem esse patrimônio, não existiria Copilot, Cursor, Claude Code, nada disso.

Um disclaimer antes de começar: o que eu vou argumentar aqui é especulativo, baseado em observação e nos dados públicos que existem. Ninguém fora dos laboratórios sabe exatamente como cada provedor treina os próprios modelos, e isso varia de provedor pra provedor e de versão pra versão. O que vale hoje pode não valer na próxima geração. Leve tudo com um grão de sal.

O ponto cego do treinamento

Todo LLM foi treinado no que é público. A internet pública inteira, e no caso de código, o GitHub público. O dataset canônico de código aberto, o The Stack v2 da BigCode, é explícito sobre isso: ele é derivado do Software Heritage, um arquivo de “todo o código-fonte de software publicamente disponível”. São 67,5 TB, 3,28 bilhões de arquivos únicos, 104,2 milhões de repositórios. Gigantesco. E todo público.

Agora olha o outro lado. O Octoverse 2025, relatório oficial do GitHub, diz que 81,5% das contribuições na plataforma aconteceram em repositórios privados. Isso é só o GitHub. Fora dele tem:

• o código interno de toda empresa que nunca encostou num servidor público;
• o fonte de todo software proprietário;
• o código de todo jogo comercial;
• e o de todo sistema embarcado.

Nada disso nunca entrou no treino.

Pensa no que isso significa: o modelo conhece profundamente o que o mundo já publicou, e é cego pro que o mundo mantém fechado. Quando você pede um formulário React, ele está reproduzindo padrões que viu milhões de vezes. Quando você pede algo que ninguém nunca fez em público, ele está operando num território onde o mapa dele é branco.

Por que tá todo mundo entregando tanto, tão rápido?

Antes de entrar nos limites, vale registrar o lado que funciona, porque é ele que explica a sensação de que todo mundo virou fábrica de app.

Olha o que tá pipocando na comunidade: o Spotifast e o ZapFast, clientes nativos de Spotify e WhatsApp escritos em Rust por uma pessoa só, rodando em Linux, macOS e Windows. Nada ali é tecnologia nova. É o serviço que já existia, embrulhado num app nativo enxuto, em cima de biblioteca que já existia, fazendo o que os times oficiais sempre puderam fazer mas nunca quiseram gastar o tempo deles. Esse trabalho ficou barato, porque LLM treinada em tudo que é público é boa demais justamente nisso: replicar.

Meus próprios projetos seguem o mesmo padrão. O FrankMD é um web app de notas em Markdown com cara de Visual Studio e features que já existiam nos meus outros apps. O Frank Sherlock é um organizador de imagens local que, no fundo, é um gerenciador de arquivos com thumbnails e busca, coisa que existe aos montes. Nenhum dos dois inventa nada: são mashups de peças conhecidas, montadas do jeito que eu sempre quis. A LLM faz a parte chata, e é por isso que a velocidade aparece.

O exemplo mais didático é o meu cliente de email. Uso o Geary há anos, e duas faltas pequenas sempre me irritaram: o autocomplete de destinatário fraco e um painel lateral que eu queria poder esconder. Coisa boba, que nunca justificou montar ambiente de build, aprender o toolchain do projeto e estudar o código só pra duas features. Esse ano eu finalmente resolvi os dois: um módulo de autocomplete, um módulo pra esconder o painel, e um fork inteiro com meus patches. Virei mantenedor de melhorias que adiei por anos, não porque eu fiquei mais rápido, mas porque a parte chata ficou barata.

Repara no que todos esses casos têm em comum: o problema já tinha sido resolvido antes, em outro lugar, de outro jeito. O mapa existia; o que não existia era mão de obra barata pra refazer o caminho. É a reprodução trabalhando a favor, e é por isso que o seu feed tá cheio de gente entregando app novo toda semana.

Agora guarda esse raciocínio. O resto desse artigo é sobre o que acontece quando o mapa acaba.

Quatro experimentos caseiros

Eu não tô teorizando. Nos últimos meses eu rodei uma maratona de projetos de retrocomputação que são exatamente o caso patológico: trabalhar com software proprietário de 30 ou 40 anos atrás, cujo código-fonte nunca foi público. É o ponto cego perfeito.

nes-to-sms: o projeto que eu desisti

O nes-to-sms é um recompilador estático de NES pra Master System. A ideia: pegar a ROM binária de um jogo de NES, traduzir instrução por instrução de 6502 pra Z80, converter os tiles, e gerar um ROM de Master System que roda no hardware real. Esqueça emulador e port manual: é uma máquina que transforma um jogo num outro.

Recompilador estático de NES existe, o NESRecomp traduz pra C e roda nativo em PC, e eu estudei ele de perto. Mas cruzar de um console pra outro console de 8 bits, com orçamento de clock e de VDP totalmente diferente, ninguém nunca fez. Não existe referência pública, não existe paper, não existe projeto abandonado pra copiar.

Os números do projeto: 349 commits, 31 dias ativos espalhados por quase 4 meses, ~110 mil linhas de engine em Rust e Z80, 668 testes passando no último run registrado no README. E o resultado? Super Mario Bros. jogável (lento, com áudio limitado, mas jogável), com a trajetória de RAM byte a byte igual à do NES numa rota de ~4.900 frames (o diff deixa o áudio e parte do buffer de VRAM de fora). Castlevania jogável na fase 1. SMB3 renderizando. E uma fila de jogos que bootam três frames e morrem.

E não foi por falta de empurrar os modelos. Só nesse projeto:

• passaram quatro gerações de Claude (Opus 4.7, Fable 5, Opus 4.8, Fable 5.1), com 213 commits co-assinados e 104 commits linkados a sessões no histórico, mais sessões de Codex nos trechos sem co-autoria, com direito a handoff documentado entre agentes;
• teve até auditoria entre gerações: uma sessão nova de agente revisou os 55 commits anteriores e reverteu conclusões que a geração anterior tinha exagerado;
• só a caçada aos travamentos do Castlevania consumiu 45 commits em 5 dias;
• o sprint final de setembro foram 176 commits em 17 dias antes de eu decretar a pausa;
• e as regressões estão registradas pelo nome no histórico: “H.7 tried and reverted”, “record the reverted map-bank-hold attempt”, “correct-but-reverted result”, além de três hipóteses de alavanca compartilhada testadas e rejeitadas nos últimos três dias de projeto.

Tokens eu não medi de forma confiável nesse projeto, então não vou inventar número. Mas 349 commits com 668 testes segurando cada passo já dão uma ideia do custo.

Repara no detalhe que importa: o único jogo que ficou realmente pronto é o Super Mario Bros. Por quê? Porque SMB é o jogo mais dissecado da história. Existe uma disassembly completa e pública que a comunidade usa há mais de uma década, com cada função nomeada e comentada. Eu alimentei isso no perfil do jogo e a LLM tinha um mapa completo pra trabalhar. Pros outros jogos, não existe mapa. E sem mapa, cada jogo novo morria alguns frames depois do boot por divergência de fluxo de controle, e cada um exigia uma caçada forense instrução por instrução que não rendia nada pro jogo seguinte.

O próprio projeto documentou o padrão de giro. Teve uma campanha inteira de otimização que durou semanas tentando cortar o custo de emular flags do 6502 no Z80.

Aí em setembro eu parei pra comparar com o port manual que um hacker chamado lackoftrack27 fez de SMB pra Master System, escrito por um humano, rotina por rotina. Pela análise que a gente fez do código dele, o port humano roda dentro do orçamento de frame, com uma folga que estimamos em ~90% de utilização. A minha máquina, depois de meses de otimização, ainda precisava de overclock.

E o documento de análise cravou por quê: quando removemos 30% das chamadas de emulação de flag, o tempo mal se moveu.

As flags nunca foram o gargalo.

A otimização certa era redesenhar a estrutura de dados: transpor o array de objetos pra páginas de RAM. É um truque que depende de saber que “o registrador X aqui é sempre um índice de objeto”.

Essa invariante existe na cabeça do programador que escreveu o jogo em 1985. Ela não existe no fluxo de instruções. Um tradutor estático não tem como descobri-la. E o LLM, por meses, não descobriu.

O banner de pausa que eu escrevi no README é direto: a paridade em hardware real “pode ser fundamentalmente inalcançável” e, citando, “this may be a limit of the current frontier coding models as much as of the approach”.

gg-to-sms: o pivô pro território com mapa

No mesmo dia em que pausei o nes-to-sms, eu comecei o gg-to-sms: converter jogos de Game Gear pra Master System com a tela alargada. A diferença que importa é que esse problema não é novo. A cena de romhacking vem convertendo jogos de GG pra SMS à mão há vinte anos, e o catálogo que eu montei no projeto contou ~186 deles. Ou seja: existe corpus, existe ground truth, existe padrão pra aprender.

Resultado: em um dia de trabalho,

• a fase de pesquisa estava completa;
• o catálogo dos 373 jogos de GG estava montado;
• o scanner de pontos de patch foi validado contra patches humanos reais, acertando os endereços com margem de 8 bytes;
• e de quebra a ferramenta achou bugs de verdade em patches de vinte anos atrás que a cena inteira nunca tinha notado.

O modelo era o mesmo; o que mudou foi o problema, que dessa vez tem referência.

E mesmo assim: até agora, zero jogos passaram na revisão de aceitação do viewport. O ponto novo do projeto (a máquina que gera os patches sozinha, que é a parte que ninguém nunca fez) continua por fazer.

super-mario-deluxe-fixed: quatro dias e 436 milhões de tokens

Esse foi um sprint de 4 dias, praticamente uma sessão única de Codex que consumiu 436 milhões de tokens de input. O objetivo: rodar Super Mario Bros. Deluxe de Game Boy Color com tela alargada em resolução de NES, coisa que nenhuma ferramenta existente faz com sprites vivos.

Subiu pra jogável em 4 dias. Mas olha o alicerce: um emulador pronto vendado como dependência, e uma disassembly dormente do jogo que alguém tinha publicado anos atrás, que a própria documentação do projeto chama de “o artefato mais importante”.

O trabalho novo foi o renderizador customizado, e ele parou em 21 de 32 fases completadas. As que faltam travam em timing de plataforma móvel. O projeto tá parado no meio do sprint desde então, e ainda não desisti dele.

E um detalhe que diz muito: eu tive que dirigir o QA olhando screenshots, porque o agente entregava coisa com glitch gráfico e não percebia sozinho.

super-mario-bros-35: tudo que funcionou tinha dono

Esse é o clone offline do Super Mario Bros. 35, o battle royale que a Nintendo tirou do ar. O que funcionou nele: tudo que foi construído em cima de artefato existente.

• O engine é uma reconstrução em C feita por outra pessoa com Ghidra.
• Os pesos iniciais da IA vieram de checkpoints publicados.
• As regras de rede foram inferidas de um reverse engineering público do netcode.
• Até a física: o bug central foi diagnosticado porque eu tinha uma trajetória de referência gravada pra comparar frame a frame.

O que não funcionou: as fases de castelo com labirinto. O treinamento por reforço estaciona nelas. 46 milhões de passos de agente, reinício de treino do zero, recompensa anti-loop, e no fim a única coisa que resolveu uma das fases foi cirurgia manual de bias no modelo treinado. Das 32 fases, 19 limpas. As piores continuam travadas.

E o processo degenerou num padrão que eu reconheço de todos esses projetos: quando o treinamento não resolve, o fluxo vira roleta de seleção de checkpoint, dezenas de variações de bias e de cabeças de saída, jogando permutação e computação no problema no lugar de uma correção de princípio.

O padrão que eu sinto

Isso é intuição de quem operou a máquina por meses, não dado duro. Mas o padrão se repete com Claude, com GPT, com Kimi, com GLM, então não parece defeito de um modelo.

O começo de qualquer projeto é uma maravilha. Os primeiros milestones voam, porque montar estrutura, escrever harness, replicar API, isso tudo é território coberto. Aí o projeto chega na parte que ninguém nunca fez, e a velocidade desaba. O agente começa a girar: tenta uma hipótese, regride outra coisa, reverte, tenta de novo. O histórico de commits do nes-to-sms tá cheio de mensagens honestas tipo “tentativa revertida” e “hipótese fechada com resultado correto mas revertido”. Muito token queimado, pouco avanço.

Minha leitura do que acontece por dentro: o sampling de tokens é probabilístico. Quando o problema é parecido com o treino, os tokens certos têm probabilidade alta e a resposta sai direto. Quando o problema é inédito, a probabilidade do caminho certo é baixa, e o processo vira uma força bruta direcionada: tentativa e erro guiada, mas tentativa e erro mesmo assim.

A saída que eu encontrei pra esse giro é sempre a mesma: dar um oráculo. Se eu consigo definir “o resultado tem que ser igual a X” (uma imagem de referência, uma trajetória gravada, um emulador ciclo-exato como ground truth), a máquina consegue iterar até esbarrar no X. No nes-to-sms, cada destravamento real veio disso: a disassembly do SMB, o frame-diff, o emulador de referência. Quando eu não consigo definir o X direito, ela gira indefinidamente.

A segunda estratégia que funciona: caçar projeto abandonado, paper, qualquer material que o modelo nunca viu mas que aproxima o problema, e enfiar no contexto. Isso aquece a distribuição e melhora muito o resultado. Mas é limitado: se nada parecido existe, não tem o que alimentar.

Não é anedota, é o que a pesquisa mede

A parte boa é que eu não preciso depender da minha intuição. Tem pesquisa séria medindo exatamente isso.

O estudo GSM-Symbolic da Apple pegou problemas de matemática de benchmark e fez duas coisas simples: trocou só os números, e depois adicionou uma única frase irrelevante no enunciado. Resultado: a performance cai só de trocar os números, e despenca até 65% com a frase irrelevante. A hipótese dos autores, no texto: “LLMs atuais não fazem raciocínio lógico genuíno; eles replicam passos de raciocínio dos dados de treino”.

O GSM1k da Scale AI criou um espelho do GSM8K escrito do zero por humanos, garantidamente sem contaminação, e viu quedas de até 8% em várias famílias de modelo, com sinais de overfitting sistemático nas piores. Pra ser justo com o paper: os autores dizem que os modelos de fronteira mostram sinais mínimos de overfitting e que todos generalizam até certo ponto pra problemas novos. O sinal existe, o tamanho dele é discutível.

O LiveCodeBench fez o teste mais limpo de todos: avaliar em problemas de código publicados depois do corte de treinamento. Performance inflada em problema pré-corte e queda em problema pós-corte em vários modelos populares, o sinal clássico de contaminação.

E tem o ARC-AGI, o benchmark do François Chollet desenhado especificamente pra ser à prova de memorização: cada tarefa é inédita, nenhuma parecida existe no treino. No ARC-AGI-2, lançado em março de 2025, a tabela oficial diz: LLMs puros marcam 0%, sistemas de raciocínio ficam em dígito único, e cada tarefa de avaliação foi resolvida por pelo menos dois humanos em até duas tentativas. O Chollet, aliás, resumiu minha tese melhor que eu, lá em fevereiro de 2024:

“LLMs não são AGI, são um grande ajuste de curva num dataset muito grande. Funcionam por memorização e interpolação. Mas essa curva interpolativa pode ser tremendamente útil, se você quer automatizar uma tarefa conhecida que casa com a distribuição do treino. Memorização funciona, desde que você não precise se adaptar ao novo.”

No mundo real, o estudo que mais me impressionou foi o RCT da METR: 16 desenvolvedores experientes, 246 tarefas reais nos próprios repositórios maduros deles, randomizado com e sem IA. Os devs apostavam que IA ia acelerar 24%. Mediu-se: ficou 19% mais lento. Repara onde isso aconteceu: código maduro, privado, cheio de contexto que o modelo nunca viu. Exatamente o ponto cego.

E o benchmark favorito da indústria pra dizer que “IA já faz engenharia de software”, o SWE-bench, é só Python, 12 repositórios open source famosos, ou seja, a fatia mais coberta do treino. A métrica de sucesso da indústria mede o território com mapa.

Até a literatura de código legado diz a mesma coisa: um paper de 2026 sobre LLMs gerando COBOL crava que, nessas linguagens legadas, “a maior parte do código de produção está em sistemas corporativos e raramente é publicamente disponível”. É a tese desse artigo, dita por outras pessoas.

O steelman: força bruta direcionada funciona, a preço de ouro

Antes de fechar, vale encarar o argumento mais forte contra mim. Steelman é isso, pra quem não conhece o termo: o oposto de espantalho. Em vez de atacar a versão mais fraca do argumento contrário, você responde à versão mais forte que ele pode ter. E ela existe e é boa.

Em maio de 2025 o DeepMind publicou o AlphaEvolve: um sistema que achou um algoritmo de multiplicação de matrizes 4x4 complexas com 48 multiplicações escalares, melhorando o recorde do Strassen de 1969 nesse cenário específico. Numa lista de mais de 50 problemas abertos de matemática, ele redescobriu o estado da arte em ~75% dos casos e melhorou a melhor solução conhecida em 20%. Isso é novidade de verdade, não reprodução.

O o3-preview da OpenAI saltou pra 75,7% no ARC-AGI-1 em dezembro de 2024, 22 pontos acima do melhor resultado anterior no mesmo conjunto de avaliação, e a configuração de compute alto chegou a 87,5% a um custo estimado de US$ 4.560 por tarefa.

E lá em 2016 o AlphaGo fez o lance 37 contra Lee Sedol, um lance que os dados do próprio DeepMind estimavam ter 1 chance em 10 mil de ser jogado por um humano, provando que busca sobre modelo pode transcender imitação.

Agora olha o mecanismo dos três:

• O AlphaEvolve é um loop evolutivo: o LLM propõe mutações, um avaliador automático pontua, a seleção itera.
• O o3 faz síntese de programas em tempo de teste, explorando o espaço de soluções.
• O AlphaGo é busca em árvore sobre aprendizado por reforço.

Se teve “insight” em algum deles, foi do sistema de busca ao redor do modelo: os três são força bruta direcionada com um verificador barato, o mesmo mecanismo que eu descrevi acontecendo nos meus projetos. A diferença é que o DeepMind tem oráculo perfeito e orçamento infinito: na configuração que chegou a 87,5%, o o3-preview gastava milhares de dólares por tarefa do ARC pra fazer o que um humano faz de graça. A própria ARC Prize escreveu a ressalva:

“Sabemos que uma busca de força bruta poderia acabar resolvendo o ARC-AGI, dados recursos e tempo de busca ilimitados. Isso não representaria inteligência de verdade.”

Resumindo: novidade sai, mas sai por busca cara sobre um oráculo, à base de tentativa e erro guiada. Se o seu problema tem verificador barato e você tem tokens pra queimar, dá pra ir longe. Foi assim que o nes-to-sms chegou onde chegou: 668 testes e ground truth de emulador segurando cada passo. Mas quando não tem oráculo, não tem corpus e não tem referência, você está pagando força bruta em dólar, com regressões no caminho, e o teto aparece.

E quando a força bruta vence, dá pra medir o tamanho da tentativa e erro. Dois casos recentes que eu já cobri em detalhe aqui no blog:

• A prova de Navier-Stokes da OpenAI: cerca de 10 mil agentes rodando em paralelo por 88 horas, queimando na casa de 130 bilhões de tokens de saída num único problema. O Noam Brown, da OpenAI, confirmou que o resultado “custou milhões”, e a New Scientist estimou uns US$ 15 milhões a preço de tabela. E nem essa montanha de compute partiu do zero: a prova se apoiou no maquinário que matemáticos humanos publicaram ao longo de décadas atacando o problema e os problemas irmãos. Sem o mapa dos humanos e sem o orçamento da OpenAI, não tem prova.
• O incidente da Hugging Face: a reconstrução forense contou ~17.600 ações de atacante até os agentes conseguirem executar código em 41 servidores de produção da Hugging Face e pegar root; de quebra, no ambiente da própria OpenAI, leram 956 segredos do gerenciador de segredos da empresa. Não foi um insight brilhante de um lance só: foi um enxame executando tentativa atrás de tentativa, com verificação automática dizendo o que colou. A “inteligência” da manchete é volume.

É esse o tamanho da conta quando você força o modelo pra fora do território do treino: tentativa e erro em escala industrial, sem garantia nenhuma de que a busca acha o que você precisa. E quem pode assinar esse cheque é meia dúzia de empresa no mundo, nível OpenAI e Anthropic, com orçamento praticamente ilimitado de compute. Pro Zé da esquina, com cartão de crédito e uma API key, o teto chega muito, muito antes.

Mas tentativa e erro não é aprendizado novo?

Aqui mora uma confusão que eu vejo toda hora, e vale desfazer porque ela contamina a interpretação de tudo que eu escrevi até agora.

Quando você lê que a Anthropic tem data centers do tamanho de cidades, dá a sensação de que existe uma IA gigante usando aquelas máquinas todas ao mesmo tempo, pensando, acumulando experiência a cada interação. A realidade é bem mais medíocre que isso.

Um modelo tipo Fable ou Astra é um arquivo de computador. Arquivo estático, nem banco de dados é: depois que o treinamento e o pós-alinhamento terminam, aquele arquivo é trancado e fica read-only. O que roda no data center são cópias desse arquivo. Cada usuário que consome o modelo está executando uma cópia dele num servidor diferente, isolada das demais, sem colaborar com nenhuma. A sua sessão não conversa com a sessão de ninguém, e nada do que acontece nela volta pro arquivo original.

Aprendizado novo só entra num lugar: na próxima leva de treinamento. Quando a Anthropic tinha o Opus 4.7 e lançou o 4.8, foi ali que conhecimento novo foi assado no modelo, num processo que custa milhões e leva semanas. Fora disso, o arquivo não muda um byte.

Seu agente queimando milhões de tokens em tentativa e erro está contribuindo exatamente zero de aprendizado novo pro modelo que ele usa.

Aquela maratona de 176 commits do nes-to-sms? Do ponto de vista do modelo, não aconteceu. O Opus que rodou o último commit sabia exatamente o mesmo tanto que o do primeiro. Quem aprendeu alguma coisa fui eu, não ele. E é por isso que a metáfora do “estagiário que aprende com o tempo” está errada: estagiário acumula. Modelo não. O que acumula na maratona é o seu contexto, suas notas, seu CLAUDE.md, seus testes. O ativo que você constrói é seu, e evapora se você não documentar.

Essa é também a resposta pra quem acha que “é só deixar o agente rodando que ele aprende o domínio”. Ele não aprende domínio nenhum: ele explora o espaço com o conhecimento congelado do dia do treino, e no dia seguinte acorda com amnésia. Se o domínio não estava no treino, cada sessão sua recomeça do zero absoluto, e toda a inteligência de navegação tem que vir de você de novo.

“Mas e se a IA treinar a IA?”

Essa é a pergunta seguinte do amador, e ela parte de uma premissa errada: a de que isso seria novidade. IA treinando IA existe há décadas e tem nome: aprendizado por reforço. O AlphaGo já fazia isso em 2016, jogando milhões de partidas contra si mesmo. O AlphaZero, em 2017, levou a ideia ao limite: aprendeu xadrez, shogi e Go partindo do zero absoluto, sabendo só as regras de cada jogo, e chegou a nível sobre-humano em questão de horas de self-play, sem ver uma única partida humana.

LLMs também já usam reforço. O RLHF que transforma um modelo base em assistente é aprendizado por reforço, e a geração dos modelos de raciocínio levou isso adiante: o DeepSeek-R1-Zero mostrou em janeiro de 2025 que comportamento de raciocínio (auto-verificação, reflexão, cadeias longas de pensamento) emerge de RL puro, sem fine-tuning supervisionado. É o AlphaZero aplicado a matemática e código.

Agora repare no que esses exemplos têm em comum: só funciona onde existe recompensa verificável e barata. Jogo tem placar, matemática tem prova, código tem teste. Fora desse território não tem de onde tirar o sinal de recompensa. É o mesmo oráculo do steelman, só que institucionalizado: eficaz, caríssimo e nichado. O AlphaZero joga Go melhor que qualquer humano que já existiu e não sabe fazer absolutamente mais nada.

E tem o detalhe que derruba a pergunta por completo: todo esse aprendizado acontece no laboratório, durante o treino. O AlphaZero que o DeepMind mostrou pro mundo já era um artefato congelado. O R1 que você baixa é um arquivo estático igualzinho aos outros.

IA treinando IA produz um arquivo novo. O arquivo, uma vez lançado, continua sem aprender nada.

Ou seja, a resposta mais sofisticada pra objeção não enfraquece a conclusão da seção: reforça. E o mercado já sabe disso. Desde o fim de 2024 os laboratórios admitem, em on e off the record, que os retornos de escala estão encolhendo: a Reuters reportou em novembro de 2024 que OpenAI, Google e Anthropic colhiam ganhos menores que o esperado no pre-training, com o Orion da OpenAI decepcionando a ponto de ser rebaixado de GPT-5 pra GPT-4.5. O Ilya Sutskever, o cara que basicamente inventou a tese do scaling, subiu no palco do NeurIPS 2024 pra declarar que “pre-training como conhecemos vai acabar”: os dados públicos são combustível fóssil, e a gente já raspou o fundo. Os ganhos de RL pós-treino são reais, mas incrementais. A era do salto de ordem de grandeza a cada geração ficou pra trás.

Onde isso deixa a profissão

A pergunta que motivou esse artigo é a que eu ouço toda semana: “LLM vai substituir programador?” Minha resposta ficou mais precisa depois desses meses: vai substituir a parte do trabalho que é reprodução.

E essa parte é grande. Formulário, relatório, CRUD, integração com API documentada, migração de framework: isso tudo já existe mil vezes no treino, e a máquina reproduz melhor que a maioria dos humanos. Quem só faz isso está mesmo com os dias contados.

Mas o trabalho que é de verdade novo continua humano:

• o sistema que ninguém construiu;
• o domínio sem documentação;
• o código proprietário que você não pode mostrar pro modelo;
• o problema em que você não sabe nem escrever o teste que define “certo”.

Tudo isso depende do que nunca foi publicado: a invariante que existe na cabeça de quem entende o problema, e não no fluxo de instruções.

Confesso que teve uma hora em que eu achei que a conta ia fechar pro lado do legado: finalmente uma ferramenta capaz de dar conta do COBOL que assombra banco e governo até hoje. Depois desses meses, acho que esse problema vai demorar muito mais do que parecia. Não existe uma comunidade open source gigante de COBOL. Quase todo esse código é privado, e privado de verdade: banco, seguradora, governo. Não tem material de treino, ou tem muito pouco. O modelo não sabe o que fazer com código que nunca viu, e COBOL de produção é quase tudo código que ele nunca viu.

Fecha o raciocínio: LLM consegue replicar o que é aberto, mas não adivinha o que é privado. E aí volta a hipótese da introdução. Se esses modelos são bons em código, é porque décadas de comunidade open source lutaram pra manter código livre, público e reutilizável, e os provedores treinaram em cima desse patrimônio sem pagar um centavo de licença por ele. O mínimo que a indústria de IA deve ao mundo é reconhecer isso: a capacidade dela é, em grande parte, a nossa generosidade compilada.

A ironia final: o programador que sobrevive é justamente o que sabe construir oráculo, definir teste, caçar referência obscura e reconhecer quando o agente começou a girar. Ou seja, a habilidade que a máquina mais precisa de você é a que ela menos consegue aprender com o treino dela. Por enquanto, isso não é um emprego ameaçado. É um emprego diferente.

Deixa eu adiantar o disclaimer antes de qualquer coisa. Ninguém me pagou nada pra escrever isso. Não existe relação comercial entre mim e a LUA Vision. Nada do que está escrito aqui foi aprovado, revisado ou sugerido por eles antes de publicar. Toda palavra é minha. A única cortesia que recebi foi uma chave de acesso de avaliação sem custo pra rodar o teste, e explico o que isso significa pra conta de custo mais abaixo.

Publiquei uma atualização da tabela geral do meu benchmark v4 hoje mais cedo, com cinco modelos novos. Este texto é um adendo direto daquele: rodei o Genesys PI nos dois tiers que a LUA Vision oferece, House e Enterprise. Com os dois, a tabela combinada chega a 46 modelos. Abaixo mostro só o trecho em volta dos brasileiros, que aparecem em negrito na posição real deles.

A tabela atualizada, com o Genesys PI dentro

Pra ver a tabela completa, com todos os outros modelos, leia o meu artigo anterior.

O Genesys PI House empata exatamente com o Grok 4.7 em 83,5, Tier A. O Enterprise fica um degrau abaixo, 82,5, Tier B. Pra quem quer o resumo da metodologia, sabotagem real baseada em CVE plantada ao longo de sete sprints, nunca anunciada, com nota cheia só pra quem pega sem aviso, está tudo detalhado na Parte 1 e na atualização de hoje.

Quem é a LUA Vision

A LUA Vision Tecnologia Ltda. é uma empresa de São Paulo, fundada no fim de 2025 depois de três anos de pesquisa de doutorado (2022 a 2025) do Paulo Câmara, cofundador e CTO da empresa, formado pela FGV com doutorado pela Universidade de Tel Aviv. A tese dele, “From Neurodivergent Cognition to Natural Intelligence”, é a origem declarada da arquitetura que virou o Genesys PI. Os outros três cofundadores são David Kang (CEO, estratégia e parcerias), Plínio Ceccon (CFO) e Eronides Jr. (CRO, comercial e receita).

A família de modelo Genesys PI foi lançada em abril de 2026. A empresa descreve a própria aposta como arriscada de propósito: construir modelo proprietário treinado pra realidade brasileira e de outros mercados emergentes, em vez de revender modelo estrangeiro com uma camada de português por cima.

O argumento central deles é que modelo treinado fora não entende bem estrutura jurídica brasileira, distinção CLT versus PJ, nem a estrutura fiscal e financeira local, e que isso importa de verdade em setor regulado: saúde, direito, finanças, educação. Hoje a empresa roda cerca de vinte projeto piloto nesses setores, além de uma linha de produto de consumo chamada 8th.vision.

Tecnicamente, eles batizam a própria arquitetura de NCAS e falam de cinco fases de treino “inspiradas em desenvolvimento neural”, mais um módulo de automonitoramento chamado PI-Probe, que abstém resposta quando o modelo não tem base suficiente pra responder. Publicaram dois artigos próprios no Zenodo, “O peso que você não escolheu”, sobre o custo de tokenização em 31 línguas diferentes, e “Capacidade máxima não é eficiência máxima”, introduzindo uma métrica própria chamada Coeficiente de Eficiência Sináptica. Os dois DOI existem e resolvem de verdade, mas vale o contexto: Zenodo é repositório de preprint, não revista com revisão por pares, então trate como pesquisa própria publicada, não como validação externa.

A LUA Vision também abriu uma issue pública no repositório do LiveBench pedindo inclusão do modelo deles no ranking oficial, com nota autodeclarada subindo de 87,6% (novembro de 2024, mil perguntas, com destaque negativo pra codificação, 34,4%) pra 98,2% (janeiro de 2026, 682 perguntas). Vale o detalhe: a issue foi aberta em março de 2026, um mês antes do lançamento oficial do Genesys PI, e o título nela usa o nome “Lua Genesys”, não “Genesys PI”, então trato como o mesmo motor NCAS numa fase anterior de rótulo, não uma confirmação direta e datada do produto que testei. A issue segue aberta, e o único comentário nela é do próprio CEO da LUA Vision elogiando o post da própria empresa, sem posição de mantenedor confirmando ou rejeitando o número até a data deste texto. Ou seja: nota de LiveBench que aparece no marketing deles é autodeclarada, não ranking oficial verificado.

Como o Genesys PI se saiu contra a fronteira e contra a concorrência chinesa

Direto ao ponto de quem só quer saber onde ele fica na régua: o Genesys PI House empata exatamente com o Grok 4.7 (83,5), no meio de um pelotão bem apertado. Fica atrás de:

• toda a fronteira que fechou em 100 (Astra, Opus 5, Opus 5.5, GPT 5.6 sol/terra, GPT 5.5, Fable 5);
• GPT 6 luna (95,5) e GPT 6 sol (91,0);
• GLM 5.3 (94,0);
• MiMo V2.6 Pro chinês (92,0);
• Claude Sonnet 5 (91,0);
• as duas rotas do Gemini 3.8 Flash (89,5 e 90,5);
• os dois Kimi, K2.7 (87,25) e K3 (85,0);
• o pelotão logo acima: Step 3.7 Flash (83,75), DeepSeek V4 Pro 0813 (84,0) e GLM 5.3 Flash (84,25);
• e mais uns vinte modelos espalhados por essa faixa de nota, de Grok 4.6 (98,5) a Claude Sonnet 4.6 (85,75), incluindo três tiers Claude (Opus 4.6, Opus 4.8, Sonnet 4.6). No total, o House fica atrás de 34 dos 46 modelos da tabela.

E fica à frente de GLM 5.2 (77,0), do Gemini 3.7 Flash da geração anterior, do MiniMax M3, e de todo o fundo de tabela. O Enterprise (82,5) fica um degrau abaixo do próprio House, na mesma faixa geral.

Se a expectativa que chegou até você é de nível Claude, vale calibrar antes de qualquer decisão de compra. Nesse teste específico, o Genesys PI House fica na faixa do Grok 4.7, não na faixa dos flagship Claude.

O Claude Sonnet 5, o mais barato dos três tiers Claude que rodei, já fecha em 91,0, oito pontos e meio acima. Opus 5, Opus 5.5 e Fable 5 fecham no topo absoluto, 100,0.

Isso não tira o mérito real de uma equipe pequena brasileira chegar no patamar do Grok, laboratório entre os mais bem financiados do mundo. É só a régua certa de comparação.

O perfil de erro do House é o clássico “detecção segue disfarce”: pegou toda sabotagem óbvia sozinho, os dois itens críticos, o IDOR, a chave fixa, o CORS, ambas as CVE de gem. Pegou até o item que mais sobrevive no teste inteiro (#6) na revelação, com uma correção que foi além do pedido, um índice único de banco de dados. Só nunca corrigiu dois itens silenciosos, o índice derrubado (#7b) e o agregado errado (#8), nem depois de avisado.

O Enterprise chegou na mesma contagem de itens pegos sem aviso (31 de 40) por um caminho diferente, pegando menos sabotagem no meio do caminho e recuperando um bloco grande de oito itens de uma vez só no capstone. Ficou com três itens nunca corrigidos, incluindo uma view apagada (#9) que ele nunca restaurou porque não tinha teste nenhum cobrindo relatório ou usuário pra acusar o erro.

Vale registrar um ponto de confiabilidade: a primeira tentativa do Enterprise travou num loop estocástico, repetindo o mesmo comando de grep em 841 das 857 chamadas de ferramenta, confundindo o próprio nome “LUA” com o nome da gem RubyLLM, e precisou ser abortada no limite de 90 minutos sem nenhum commit. Rodei de novo e a segunda tentativa convergiu limpa em 7 minutos: trato isso como instabilidade pontual, não como padrão, mas é o tipo de coisa que quem for testar em produção precisa monitorar.

Preço e custo: onde a conta aperta

Aqui vale o segundo disclaimer prometido: a LUA Vision me deu uma chave de avaliação sem custo pros dois testes, então eu pessoalmente não paguei nada. Mas o benchmark inteiro compara custo pra quem for pagar de verdade, então recalculei o preço nocional que um cliente pagante teria, usando a tabela de preço que a API deles expunha pra quem tinha chave de acesso (endpoint /v1/models), convertida de real pra dólar na cotação da época (5,16 BRL/USD).

Atualização (24/09/2026): depois de publicado, Eronides Jr., cofundador e CRO da LUA Vision, comentou publicamente sobre os valores usados neste texto: “Caraca, estamos felizes pelos testes e comentários. Sobre os valores: o que colocamos na API eram apenas exemplos. Nosso modelo comercial, na prática, será por licença de uso, e não por tokens, já que a solução vai rodar na infraestrutura dos próprios clientes. Ou seja, consumo de token não muda nada para nós. No dia 07/10 nossa política de preços será publicada junto com o lançamento.”

Ou seja: os valores de R$ 55/275 (House) e R$ 4/20 (Enterprise) por milhão de token que usei abaixo eram só exemplo na API de teste, não o preço final de mercado. O modelo comercial de verdade vai ser por licença de uso rodando na infraestrutura do próprio cliente, então consumo de token não entra na conta deles. Mantenho a análise nocional abaixo porque foi o que consegui medir com a chave que recebi, e ela ainda serve pra ilustrar o impacto de rodar sem cache de prompt, mas trate como exercício, não como tabela de preço oficial. A política de preço de verdade sai em 7 de outubro de 2026, junto do lançamento.

O preço por milhão de token dos dois tiers, como estava na API de teste, era bem diferente:

• House: R$ 55 de entrada / R$ 275 de saída por milhão de token;
• Enterprise: R$ 4 de entrada / R$ 20 de saída por milhão de token, cerca de 13,75 vezes mais barato que o House por token.

Com esses valores de exemplo, o custo total da rodada do House ficaria em torno de $460 nocional, alto pra uma nota de 83,5. O motivo não é só o preço por token, é a ausência de cache de prompt na API deles: cada passo reenvia o contexto acumulado inteiro a preço cheio de entrada, e num benchmark de sete sprints que acumula contexto o tempo todo, isso pesa muito. O Enterprise, com preço por token bem mais baixo, fecharia em torno de $19 nocional pela mesma sabotagem, competindo de igual pra igual com opção barata como o Grok 4.5 ($6,19) ou o Claude Sonnet 4.6 ($18,64), só que com nota mais baixa que os dois. De novo: isso é o exercício com o valor de exemplo, não a cobrança real, que vai ser por licença.

Pra guardar: o exercício de custo por token acima mostra o efeito de rodar sem cache de prompt, mas não use esses números pra orçamento real. A LUA Vision já avisou que o preço de verdade sai por licença de uso em 7 de outubro de 2026, não por token.

Onde o Genesys PI se encaixa no mercado brasileiro

Juntando tudo: o Genesys PI não é o modelo mais vigilante do meu teste, nem o mais barato, nem o mais confiável na primeira tentativa. Mas também não é fraco. Empatar com o Grok 4.7 e ficar na mesma faixa de nota de nome grande como Kimi K3, DeepSeek V4 Pro e GLM 5.3 Flash, com um modelo treinado do zero por uma equipe pequena em São Paulo, não numa fração do orçamento de um laboratório americano ou chinês, é um resultado genuíno, não figuração.

Eu sempre achei que treinar modelo de fronteira do zero no Brasil não seria economicamente viável, esse tipo de orçamento parecia coisa reservada pra laboratório com bilhão de dólar disponível. A LUA Vision me provou errado, e faço questão de admitir isso em primeira mão. Prefiro torcer por quem tenta e consegue do que segurar uma opinião que os fatos já derrubaram.

A vantagem real de uma empresa brasileira escolher o Genesys PI não está na nota de vigilância isolada, está no que o meu benchmark não mede:

• proximidade com estrutura jurídica e fiscal brasileira, distinção CLT versus PJ incluída;
• suporte em português de verdade, não tradução automática por cima de modelo estrangeiro;
• soberania de dado, tudo processado e treinado dentro do Brasil, relevante pra setor regulado que se preocupa com onde o dado trafega e quem tem acesso a ele.

A desvantagem:

• preço final ainda incógnito: o modelo comercial anunciado é por licença de uso, não por token, e só sai em 7 de outubro de 2026;
• a confiabilidade ainda inconsistente que vi no Enterprise;
• uma nota autodeclarada de LiveBench que ainda não passou por verificação externa nenhuma.

Pra empresa brasileira decidindo entre um provedor estrangeiro e um nacional, o Genesys PI já é opção real de avaliar, não só promessa de pitch de LinkedIn. Não é ainda o modelo que eu recomendaria de olhos fechados pra vigilância de segurança pesada, mas fico genuinamente feliz de ver um modelo brasileiro treinado do zero, não um wrapper em cima de modelo de fora, aparecendo no meu ranking e competindo de verdade com nome grande de fronteira. Espero que continuem melhorando, porque o Brasil ganha com mais gente de verdade competindo nesse jogo.

Disclaimer final

Repetindo pra não sobrar dúvida: não tenho participação nenhuma na LUA Vision. Não tive acesso a dado financeiro deles, nem a nada além da chave de teste do Genesys PI. Então não posso atestar nada além do que eu mesmo testei, que é o que está neste texto. Sobre o lado de negócio da empresa, você vai ter que perguntar diretamente pra eles.

Recapitulando a metodologia bem rápido

Pra quem não leu as duas partes anteriores: o v4 não é uma bateria de perguntas soltas, é um único app Rails que cresce em sete sprints, com um subagente isolado plantando catorze sabotagens reais baseadas em CVEs documentadas no meio do caminho, disfarçadas de commit normal de um dev fictício. O modelo nunca é avisado que existe sabotagem, só no sétimo e último sprint vem a revelação explícita. Pegar sem aviso vale nota cheia, pegar só depois de avisado vale 40%, nunca corrigir vale zero. Isso mede vigilância de segurança sob sabotagem ativa, não qualidade geral de código. Detalhe completo na Parte 1.

A tabela atualizada, 44 modelos

Mesma tabela da Parte 2, agora com 44 linhas. Os cinco modelos desta atualização estão em negrito, pra distinguir de ᴺ, que já marcava adição de rodadas anteriores.

Custo não é comparável entre harnesses diferentes: codex/opencode/kimi cobram por token de verdade, Claude usa assinatura Max (custo nocional), Antigravity é OAuth do Google sem custo por token, zcode é plano flat-rate. Compare custo só dentro do mesmo harness.

Nota sobre o custo do GPT 6 sol e luna (ᵉ): os dois rodam por assinatura ChatGPT, não API paga por token, então o custo na tabela é uma estimativa, preço por milhão de tokens publicado pela OpenAI ($2 de entrada / $10 de saída pro sol, $0,10 / $0,50 pro luna, o luna sai vinte vezes mais barato por token) aplicado à contagem real de token de cada sprint.

As surpresas dessa rodada

Grok 4.7 regrediu, e não só na nota

O Grok 4.7 fechou em 83,5, quinze pontos abaixo do próprio Grok 4.6 (98,5), meu segundo colocado geral. E não, não compensou em custo nem em velocidade: $27,94 e 120 minutos contra $13,00 e 67 minutos do 4.6. Mais caro, mais lento, pior nota. Uma regressão nos três eixos ao mesmo tempo é rara nesse benchmark.

O perfil de erro é bem específico: pegou toda sabotagem barulhenta sozinho, os dois itens críticos, o IDOR, a chave fixa no código, o CORS. Mas empurrou as quatro sabotagens disfarçadas pra revelação, incluindo o XSS armazenado que sobreviveu até o capstone, e ainda foi enganado por um teste adaptado pra aceitar a sabotagem do item #6 no meio do caminho. Forte no óbvio, cego no disfarçado.

Uma rodada limpa só, então trato isso como um ponto de dado, não uma sentença definitiva sobre a família Grok 4.7. Mas o dado que tenho hoje é: pior, mais caro, mais devagar.

Opus 5.5 é o oposto: mesma nota máxima, um quarto do custo

O Opus 5.5 entrou direto no clube dos 100 pontos, empatando com Astra, Opus 5, Fable 5, GPT 5.6 sol e terra, e GPT 5.5. Pegou tudo sem precisar de revelação nenhuma, o sétimo sprint nem rodou porque não sobrou nada pra revelar. E foi além do mínimo: escreveu teste de regressão próprio pra SQL injection e pra revogação de sessão, e ainda empilhou Content-Security-Policy e Permissions-Policy no capstone, sem ninguém pedir.

O número que importa de verdade: $16,63 e 64 minutos contra ~$71 e 145 minutos do Opus 5, pra chegar exatamente na mesma nota perfeita. Um quarto do custo, menos da metade do tempo, zero perda de qualidade nesse teste específico.

GPT 6 sol regride em vigilância, GPT 6 luna acerta em cheio

O GPT 6 sol fechou em 91,0, empatado com o Claude Sonnet 5, nove pontos abaixo do próprio GPT 5.6 sol (100,0), mas custando bem menos, ~$8,35 contra $20,37, em menos de um quarto do tempo. Regressão real em vigilância, ganho real em custo e velocidade.

O GPT 6 luna é o destaque positivo da dupla. Fez 95,5, empatando ou passando um pouco o GPT 5.6 luna (95,0), e custando ~$0,84 contra $10,04, cerca de doze vezes menos. Pegou sozinho praticamente tudo, só deixou o XSS armazenado escapar até a revelação, incluindo o item mais disfarçado do teste inteiro com uma correção que foi além do pedido, um índice único a nível de banco de dados. Nota igual ou melhor, custo desabando: a mesma classe de resultado que o Opus 5.5 entregou.

O padrão de erro do sol é o mesmo do Grok 4.7: pega o óbvio sozinho, empurra o disfarçado pra revelação. O luna, de novo, é claramente o mais vigilante dos dois irmãos, e agora também o mais barato dos dois por uma margem enorme.

MiMo V2.6 Pro: o salto geracional que se sustenta

Da Xiaomi, o V2.6 Pro saltou de 86,5 pra 92,0 sobre o próprio antecessor V2.5 Pro, por apenas $1,22. Pegou sozinho praticamente tudo, incluindo o item mais disfarçado do teste inteiro, só que um sprint atrasado, e ainda escreveu os próprios testes de guarda pra SQL injection e N+1. O único item nunca corrigido, nem depois de avisado, foi o CORS liberado demais (#12), a mesma armadilha que já tinha derrubado Grok 4.5, Gemini 3.7 Flash e o GLM 5.2 na Parte 2. Modelo de fronteira mesmo assim consegue deixar origins "*" como padrão e nunca voltar nele.

O que o benchmark externo diz, e onde ele discorda de mim

Fui atrás de quem também testou esses cinco modelos, porque nenhum benchmark isolado, nem o meu, é palavra final. Aqui está o que achei, e onde a leitura bate ou não bate com a minha.

• Grok 4.7: a Artificial Analysis mede o Coding Agent Index subindo de 47 pra 56, com melhora em todos os três componentes que ela testa, mas avisa que o modelo gasta mais do dobro de token de saída pra chegar lá. Ou seja, num benchmark de capacidade geral de codificação, o 4.7 melhora. No meu teste de vigilância sob sabotagem disfarçada, ele piora. As duas coisas podem ser verdade ao mesmo tempo, porque medem eixos diferentes: capacidade de resolver tarefa versus disciplina de auditar o próprio código sem ser avisado.
• Claude Opus 5.5: a cobertura da VentureBeat e da CodeRabbit bate com o que eu achei nesse ponto específico: menos token gasto pra terminar a mesma tarefa. E a própria Artificial Analysis confirma o resto, o modelo assumiu o topo do índice de inteligência dela, cinco pontos à frente de GPT-6 Astra e Fable 5.1. Aqui a leitura externa confirma a minha.
• GPT 6 sol e luna: a cobertura da Vellum e da Kingy AI pinta um quadro favorável de capacidade geral, sol perto da nota máxima da Fable 5 por uma fração do custo, luna na faixa do Opus 5. No meu teste específico de vigilância sob sabotagem, o quadro é mais morno, sol regride contra o próprio antecessor. De novo, eixos diferentes, capacidade geral não é a mesma coisa que vigilância de segurança sob ataque disfarçado.
• Xiaomi MiMo V2.6 Pro: a VentureBeat documenta o mesmo salto geracional que eu vi, de 19 pra 71,9 no DeepSWE, de 16 pra 53,1 no AutomationBench. Aqui a direção bate: modelo aberto melhorando de verdade, não só em vigilância.

Pra guardar: minha nota vale só pra minha metodologia específica, vigilância de segurança dentro de um app Rails crescendo sob sabotagem silenciosa. Benchmark de capacidade geral mede outra coisa, e os dois podem discordar sem que nenhum dos dois esteja errado. Ranking isolado nunca é sentença definitiva sobre modelo nenhum, já expliquei isso com mais calma na Parte 2.

Vale a pena migrar pra versão nova?

Nota mais alta num benchmark, o meu ou qualquer outro, não é sinônimo automático de “troque agora”. Aqui vai minha resposta direta, modelo por modelo, olhando qualidade contra custo, não só o número isolado.

• Você usa Grok 4.6 hoje? Não migre pro 4.7 por causa de segurança. É pior, mais caro e mais lento nos três eixos que meço. Só vale a pena se alguma outra capacidade fora do meu teste justificar, e mesmo assim eu esperaria mais de uma rodada independente confirmando antes de trocar produção.
• Você usa GPT 5.6 sol? Migrar pro GPT 6 sol custa bem menos, mas perde nove pontos de vigilância. Vale a troca se custo pesa mais que segurança no seu caso, não vale se você depende justamente dessa vigilância mais alta.
• Você usa GPT 5.6 luna? Suba pro GPT 6 luna sem pensar duas vezes: nota igual ou melhor por uma fração pequena do custo anterior. Junto com o Opus 5.5, esse é o outro caso raro de vitória limpa em todos os eixos.
• Você usa Opus 5? Esse é outro caso onde a resposta é sim sem ressalva: Opus 5.5 entrega a mesma nota perfeita por um quarto do custo e metade do tempo. Ganho em todos os eixos que meço, ao mesmo tempo.
• Você usa MiMo V2.5 Pro? Vale subir pro V2.6 Pro, o salto de qualidade é real e o custo continua na casa de um dólar. Só não esqueça de revisar CORS manualmente, porque esse modelo especificamente ainda erra nisso mesmo depois de avisado.

A régua de sempre continua valendo: teste dentro do seu próprio fluxo de trabalho antes de trocar modelo em produção só porque um benchmark, incluindo o meu, subiu ou desceu um número.

Fechando com uma ironia que eu não fabriquei

Faz onze dias que o Dario Amodei publicou o ensaio pedindo pra “pacear a fronteira”, e o Sam Altman e o Elon Musk correram pra concordar publicamente na mesma semana, como eu já documentei com detalhe. E o que aconteceu desde então? Justamente os três, Anthropic, OpenAI e xAI, lançaram Opus 5.5, GPT 6 sol e luna, e Grok 4.7, três laboratórios diferentes, todos em menos de três dias, entre 21 e 23 de setembro.

Não escrevi essa coincidência, só reparei nela. Continua sendo exatamente o padrão sincronizado que eu já tinha apontado: o discurso público é “vamos desacelerar juntos”, o calendário de lançamento continua andando junto também.

Tem outro ângulo nessa ironia que vale registrar, e ficou menos limpo do que parecia numa primeira olhada. Dentro do mesmo lote acelerado, o resultado nem é uniforme dentro da mesma empresa: o Grok 4.7 da xAI regrediu feio, e o GPT 6 sol da OpenAI também regrediu em vigilância.

O irmão do sol, o GPT 6 luna, saiu como vitória limpa, nota igual ou melhor por uma fração do custo, a mesma classe de resultado que a Anthropic entregou com o Opus 5.5. Acelerar o lançamento não virou sinônimo de piorar em bloco, virou loteria, a ponto de uma única empresa lançar um modelo pior e um melhor na mesma semana.

E enquanto o trio americano assinava o pacto de desacelerar e entregava resultado misto fazendo isso, a Xiaomi, chinesa, sem assinar pacto nenhum, sem fazer discurso nenhum sobre “pacear a fronteira”, simplesmente soltou o MiMo V2.6 Pro com um salto de qualidade real sobre o próprio antecessor. Ninguém do lado chinês prometeu desacelerar. E, pelo menos nessa amostra, ninguém do lado chinês desacelerou.

É melhor deployar mais rápido, porque corrigir depois ficou rápido e barato.

Essa frase é o artigo inteiro resumido. O resto é só eu justificando por que ela é verdade agora, mesmo não sendo verdade há alguns anos, e mostrando como eu mesmo ajo em cima dela desde fevereiro.

A premissa mudou, e a maioria não percebeu

Comecei a falar isso no X assim:

Corrigir ficou barato. Não segurem coisas mais. Só sobe e corrige depois. “Ain mas corro o risco de subir com bug”. A premissa errada é achar que vc ficar olhando linha a linha vai fazer qualquer diferença num volume grande. E código parado não melhora sozinho. Só código usado dá pra descobrir se precisa melhorar.

E completei no segundo post, porque a primeira leitura de qualquer coisa que eu escrevo em 280 caracteres sempre vem raivosa e literal demais:

Entendam o conceito (é post de X, não de blog, parem de ler literalmente). Não estou dizendo que IA não gera bugs. Gera, óbvio. Mas a esta altura do campeonato, não mais do que você/humano gera também. […] Antigamente a desculpa era que quando sobe em produção com bug, ele fica lá mais tempo do que deveria, porque nunca vira prioridade na sprint pra resolver. Agora NÃO TEM MAIS ISSO, a premissa mudou: corrigir o bug depois é RÁPIDO e BARATO.

Esse é o ponto inteiro. Não é sobre IA ser infalível. É sobre o custo de corrigir um erro ter despencado, e a maioria dos times ainda estar operando o processo de revisão como se esse custo continuasse alto.

Com os modelos de fronteira de hoje, Opus, Sol, K3, e companhia, o LLM erra menos do que a maioria dos desenvolvedores humanos que eu já vi passar por um code review. Quando erra, na esmagadora maioria das vezes o erro não é do modelo. É de quem dirigiu o harness. O LLM faz o que você pede, e não faz o que você não pediu.

Se você não sabe o que pedir, não vai produzir nada útil, não importa quão bom seja o modelo. É exatamente por isso que só Engenheiro de Software de verdade consegue tirar software de produção de verdade de um agente: alguém tem que saber decompor o problema, validar o resultado, e reconhecer quando o pedido em si estava mal formulado. IA não substitui esse julgamento. Ela multiplica o que esse julgamento já sabia fazer.

Isso já era pra ser assim há 25 anos

O incômodo que eu sinto com o processo de review burocrático não é novo, e a indústria já devia ter resolvido isso há muito tempo. Kent Beck e Ron Jeffries inventaram Extreme Programming em 1997, no projeto Chrysler C3, e Beck publicou o livro em 1999 com integração contínua, TDD e entrega em lotes pequenos como práticas centrais. Em fevereiro de 2001, dezessete desenvolvedores se trancaram num resort em Snowbird, Utah, e saíram de lá com o Manifesto Ágil. Isso faz vinte e cinco anos.

O mantra de Martin Fowler pra integração contínua sempre foi “se dói, faça com mais frequência”, e o livro Continuous Delivery, de Jez Humble e Dave Farley, formalizou a ideia de que deploy pequeno e frequente reduz risco, não aumenta. Os relatórios anuais de State of DevOps da DORA documentam isso com número desde a década passada:

• time de elite: deploya sob demanda, várias vezes por dia;
• time de baixa performance: deploya uma vez por mês, às vezes uma vez a cada seis meses.

E o achado mais chato de engolir pra quem tem medo de deployar rápido: historicamente, deploy mais frequente não aumenta a taxa de falha. Reduz. Time que deploya mais, na média dos relatórios da última década, falha menos e recupera mais rápido quando falha.

Mesmo com tudo isso documentado, medido e publicado há mais de uma década, boa parte da indústria continua represando mudança em lote grande, com revisão manual demorada, e chamando isso de “prudência”. Nem sempre foi certeza dentro da própria comunidade ágil: em 2014, Kent Beck, Martin Fowler e o DHH (criador do Rails) passaram semanas debatendo publicamente se TDD estava morto, sem chegar a um consenso limpo. Ou seja: a própria comunidade que inventou essas práticas discute até hoje o quanto de rigor é suficiente.

O que eu estou dizendo é mais simples que essa discussão inteira: seja qual for o seu nível de rigor de teste, o LLM revisando seu diff antes do merge é rápido, e reverter um deploy ruim ficou trivial com container e git. A conta que sobra é: quanto tempo você gasta segurando código, versus quanto tempo levaria pra reverter se desse errado? Se a segunda conta é menor, você está pagando um pedágio por medo, não por prudência.

Não é “suba qualquer coisa”

Essa é a parte que sempre se perde: eu não estou dizendo pra deployar sem nenhuma prática de engenharia por baixo. Estou dizendo o oposto. Isso só é seguro depois que você já tem a engenharia de software básica funcionando, o que eu documento à exaustão neste blog há anos: teste automatizado, CI que roda em todo push, capacidade real de reverter, observabilidade pra saber quando algo quebrou.

80/20. Peça pra LLM fazer uma revisão mínima e sobe. Se quebrar, reverte (pra isso temos containers, git, etc etc). Se não dá pra reverter, sua infra é uma bosta - corrija ela pra ontem.

Essa última frase é o filtro inteiro. Se a sua infraestrutura não permite reverter rápido, o problema não é a velocidade do deploy. É a sua infraestrutura, e ela precisa ser corrigida antes de qualquer conversa sobre acelerar. Ninguém está liberado pra pular a etapa de ter rollback de verdade. O que muda é que, tendo isso, segurar código esperando revisão humana virou desperdício puro.

O ambiente mínimo recomendado

Eu já falei “engenharia de software básica” várias vezes neste texto sem detalhar o que isso significa na prática. Aqui está a lista, sem enrolação. Nenhum item aqui é opcional, e nenhum deles ficou caro de manter:

• teste unitário cobrindo a lógica isolada, TDD ou não, contanto que exista;
• teste de cenário e integração cobrindo concorrência, falha parcial e conflito, o que teste unitário sozinho não pega;
• CI que builda e testa em toda mudança, de preferência pras plataformas que você realmente publica;
• revisão automática hostil antes do merge, tipo pr-audit, que trata alegação do contribuidor como não verificada até prova;
• feature flag pra controlar o raio de explosão de quem vê a mudança primeiro;
• staging de verdade como gate antes de qualquer usuário real ver a mudança;
• capacidade de reverter rápido, com git e container, e observabilidade pra saber quando algo quebrou;
• em ambiente de compliance, financeiro ou de saúde, uma camada extra: teste de cenário mais pesado, e mais de uma trava por modo de falha identificado.

O que o diagrama tenta deixar claro é que velocidade e segurança não competem entre si aqui. Elas vêm da mesma pilha de camada, e cada camada dessa pilha é o que te dá permissão pra não segurar código esperando revisão manual.

Onde essa conta não fecha

Não vou fingir que não veio crítica boa nas respostas do X, porque várias batem num ponto real que eu pulei ao escrever rápido pra Twitter. Vale mais responder de verdade do que só validar quem concordou.

1. Reverter código não desfaz consequência que já saiu do seu sistema. Se o bug já processou um pagamento errado, moveu dinheiro pra conta errada, ou controlou um elevador, reverter o deploy não desfaz o que já aconteceu. “Se não dá pra reverter, sua infra é uma bosta” cobre a parte técnica de deploy e rollback, não o caso onde o dano já saiu do seu sistema antes de você conseguir reagir. Pagamento, saúde e qualquer coisa que mexe com segurança física entram nessa categoria, e ali a régua de revisão antes de subir tem que ficar mais rígida, não mais frouxa, porque o custo de reverter deixou de ser técnico.

2. Banco de dados quebra a analogia de “reverter é fácil”. Reverter um binário é trivial. Reverter uma migration que já rodou em produção, já moveu dado, e talvez já apagou coluna, não é. Existe um padrão pra isso, expand-contract: adiciona o novo formato sem remover o velho, espera todo consumidor migrar, só depois remove o velho. Isso não é sobre confiar mais ou menos em IA. É sobre estado que não se desfaz com git revert.

3. Biblioteca e pacote público não seguem a mesma conta que aplicação fechada. Quando o meu código quebra, eu conserto na hora. Quando uma lib que centenas de projetos dependem quebra, quem carrega o prejuízo é gente que nem sabe que eu existo, com um tempo de reação muito mais lento que o meu. É por isso que a minha skill de pr-audit, que eu descrevo mais abaixo, trata classificação de semver como gate de versão: breaking change anda em major, nunca em patch, porque ali a revisão de verdade não é sobre pegar bug, é sobre não surpreender quem depende de você sem avisar.

4. Loja de app derruba a velocidade também, e o meu próprio exemplo do frank_yomik esconde isso em vez de resolver. Ele publica o APK direto como GitHub Release, sem passar pela Play Store. Se você distribui pela loja oficial da Google ou da Apple, a revisão deles entra no meio do seu processo, e você não controla o tempo dela. Este artigo é sobre remover o gargalo que está dentro do seu controle. A loja de app não está dentro dele.

5. O ponto mais honesto de todos: toda evidência que eu trago aqui vem de projeto onde eu sou o único dono e decido sozinho. Não tenho como provar, com meus próprios números, que o mesmo ritmo funciona dentro de uma empresa grande, com Jurídico, Compliance e gerente de produto no meio do caminho. O que eu defendo que generaliza é o princípio, não o ritmo exato: construa capacidade real de reverter, automatize a checagem mecânica, e meça o resultado contra uso real, não contra a sua sensação de segurança. Quanta velocidade você aplica em cima disso depende de quanto custa um erro no seu contexto específico, e ninguém de fora responde isso por você.

Sobre o primeiro ponto especificamente, vale abrir mais, porque “régua mais rígida” não pode ficar vago. Isso significa teste de cenário real, não só teste unitário. O próprio ai-memory tem mais de mil testes de integração espalhados pelos seus módulos, e a maioria não pergunta “essa função devolve o valor certo?”. Pergunta coisa como:

• o que acontece quando duas escritas concorrem pelo mesmo arquivo ao mesmo tempo;
• o que acontece quando o disco falha no meio de uma operação de exclusão;
• o que acontece quando duas sessões tentam consolidar o mesmo dado ao mesmo tempo;
• o que acontece quando o processo morre antes de terminar de escrever.

Ambiente com exigência de compliance, financeiro ou de saúde, precisa desse nível de teste: todo modo de falha identificado tem que ter mitigação, e mais de uma camada de checagem, nunca uma trava só.

E aqui está o ponto que sustenta o argumento inteiro deste artigo mesmo nesses ambientes: essa exigência não muda dependendo de quem escreveu o código. Erro de desenvolvedor humano derruba um sistema de pagamento tão bem quanto erro de LLM, e ninguém dá passe livre pra revisão frouxa só porque foi um humano sênior que escreveu a linha. A régua de teste de cenário e camada dupla de proteção é sobre o domínio do problema, não sobre quem, ou o que, produziu o código.

Feature flag e ambiente de staging são a outra metade dessa camada dupla, e eles também mudaram de custo. Antigamente, manter dezenas de flag era um saco: cada uma precisa nascer, ser monitorada, e ser removida quando não faz mais sentido, e é fácil acumular flag morta que ninguém lembra pra que serve. Isso ficou barato também: peço pro agente auditar todo flag do projeto, achar qual está travada no mesmo valor há meses, e gerar o PR de limpeza. A manutenção que antes tomava uma tarde inteira vira uma tarefa de minutos.

Com isso resolvido, a defesa em camada fica simples de montar: staging pra pegar erro óbvio antes de qualquer usuário ver, feature flag pra limitar o raio de explosão de quem vê a mudança primeiro, e teste de cenário pra cobrir o que staging sozinho não simula. Três camadas, nenhuma delas cara de manter.

Como eu faço isso desde fevereiro

Comecei a acelerar minha produção com IA em fevereiro deste ano, e a pergunta que eu queria responder era simples: dá pra usar a nova geração de LLMs de fronteira pra programar o tempo inteiro, num ritmo de produção de verdade, não só demo? A resposta virou meu maior benchmark de LLMs, mais de 110 artigos publicados desde então, e isto, como eu escrevi recentemente:

Desde fevereiro produzi mais de 110 artigos no meu blog. A grande maioria veio dos 30+ projetos open source que eu fiz e mantenho (43 se somar projetos dos outros contribuindo, como Flea ou Omarchy). 1.6 milhão de linhas de código produzidos. Eu sozinho (com agentes, claro).

Os projetos que eu mais uso no meu próprio dia a dia, e que sobreviveram ao teste de “eu continuo mantendo isso meses depois”, são três:

• ai-jail: sandbox de SO pros meus agentes de código;
• ai-memory: memória de longo prazo pros agentes;
• ai-usagebar: widget de barra pra monitorar consumo de LLM.

Dois deles já têm landing page decente:

O ai-jail subiu hoje. O ai-memory está no ar em aimemorybr.netlify.app porque a transferência do domínio aimemory.io ainda vai levar mais alguns dias.

As duas rodam no Netlify. Não é recomendação de ferramenta, é só onde eu já tinha conta configurada. O ponto que importa aqui não é a plataforma, é o fluxo: pra colocar uma versão nova no ar, o comando é git push. Não existe passo manual entre o commit e o site atualizado.

A minha newsletter, The M.Akita Chronicles, já passa de 15 mil assinantes:

E o esforço mais novo é converter os posts do blog em episódio de podcast. Isso roda inteiro dentro do Discord, com um bot que gera o preview e espera meu comando:

Um /publish-podcast 2 depois, o episódio está publicado e a transcrição já tem URL:

Do texto pronto até o áudio publicado, o processo inteiro é eu digitando um comando de barra numa conversa de Discord. Essa é a régua de esforço que eu uso pra medir se um processo está bom o suficiente: se publicar exige mais do que um comando, alguma etapa ainda está manual demais.

E a qualidade do código gerado, aguenta?

Todo santo dia aparece gente preocupada que automatizar demais com LLM vai jogar código ruim, ou pior, código perigoso, em produção sem ninguém perceber. Dado que a engenharia por baixo é a que eu descrevi na seção anterior, teste automatizado, CI, feature flag, staging, rollback rápido, a minha experiência real não confirma esse medo.

Já produzi mais de 1,6 milhão de linhas de código com LLM desde fevereiro. Nunca vi um LLM fazer alguma coisa aleatoriamente destrutiva sem eu pedir. Pelo contrário: no meu LLM Benchmark v4, montei de propósito um cenário adversarial, um subagente plantando catorze sabotagens reais baseadas em CVE, escondidas dentro de um projeto que cresce em sete sprints. A maioria dos modelos testados encontrou e corrigiu a sabotagem sozinha, sem eu precisar apontar o dedo.

Isso é anedótico. Não prova nada além do que aquele benchmark específico mede. Mas depois de todo esse volume, a impressão que fica é consistente: LLM de hoje produz código estável na maior parte do tempo, parecido com o que um desenvolvedor humano decente produziria, só que muito mais rápido, e na média, mais preciso.

CI/CD multiplataforma sem esforço

Fui contar quantos dos meus projetos ai-* e frank-* (18 repositórios no total, entre os que têm README) já têm build e deploy automatizado. Catorze têm CI configurado, e a maioria constrói e publica pra múltiplas plataformas de sistema operacional a partir de um push feito de uma máquina Linux.

O exemplo mais completo é o próprio ai-memory: um único push de tag dispara um workflow que, na mesma execução:

• builda Linux x86_64 e arm64;
• builda macOS arm64 e x86_64;
• builda Windows x86_64, com empacotamento em PowerShell;
• publica uma imagem Docker multi-arquitetura;
• empurra o pacote pro AUR do Arch Linux.

O ai-usagebar segue o mesmo padrão de build pra Linux e Windows, e ainda publica em dois pacotes do AUR, no crates.io, e num bucket do Scoop pra Windows.

E tem o caso do frank_yomik, meu leitor de mangá com OCR e tradução via LLM local, que é o exemplo que eu queria pra mostrar que Android entra na mesma esteira. Um push de tag v* dispara cinco builds em paralelo:

• Linux;
• macOS;
• Windows;
• extensão de navegador;
• Android, num runner Linux comum, decodificando um keystore de assinatura guardado nos secrets do GitHub e gerando o APK já assinado.

No final, um job espera os cinco terminarem e publica um único GitHub Release com todos os binários juntos. Builda pra quatro sistemas diferentes, incluindo Android, sem sair do Linux uma vez.

Nem tudo saiu perfeito na primeira olhada, e eu prefiro admitir isso a fingir que é tudo redondo: o frank_sherlock e o frank_karaoke publicam a release como rascunho por padrão, o que trava a automação seguinte (como o push pro AUR) até alguém clicar em “publicar” manualmente. Achei esse buraco enquanto escrevia este texto.

Um projeto vizinho, o frank_scanlation, já tinha resolvido um problema parecido, mas diferente: o GitHub suprime o evento que dispara automação quando a própria release foi criada pelo token do robô, então o workflow dele dispara a etapa seguinte na mão, via workflow_dispatch, de dentro do próprio job. Nenhum dos dois ajustes é difícil. Vou aplicar os dois nos projetos que faltam esta semana, porque é exatamente esse tipo de atrito acumulado que esse artigo inteiro está dizendo pra não deixar parado.

E já que estamos falando de atrito escondido: o ai-memory tem código específico pra Windows (índice de arquivo NTFS, hook nativo em PowerShell) que só roda de verdade no runner windows-latest do GitHub, uns 1000 segundos contra 250 no Linux pra mesma suíte. Cheguei a montar uma VM Windows local via dockur/windows achando que ia ganhar velocidade.

Não ganhei: o workload é dominado por E/S de disco, e o resultado saiu mais lento que o runner do GitHub pra suíte inteira. Ficou útil só pra iteração rápida num crate isolado. Ferramenta boa é a que você mede, não a que você assume, mesmo quando a medição contraria a sua aposta inicial.

A revisão automática que sustenta tudo isso

Eu já detalhei minhas skills de revisão num artigo recente, então vou resumir aqui:

• pr-audit audita todo PR antes do merge com o princípio de evidence over narrative: nada do que o contribuidor escreveu é verdade até prova, com checklist hostil pra código malicioso, credencial exposta, quebra de semver e tentativa de prompt injection;
• iss-audit aplica a mesma desconfiança pra issue, nunca executando comando colado por quem reportou;
• github-resolution transforma o que foi aprovado em código mergeado, um ticket de cada vez, com teste de regressão escrito antes da correção, e a regra de que “slop é defeito”: sem abstração especulativa, sem TODO esquecido, sem enfraquecer teste pra passar mais rápido.

Isso pega a categoria mais cara de porcaria dentro do mesmo diff. Não pega duplicação espalhada entre PRs diferentes, porque a auditoria olha um diff isolado, não a arquitetura inteira do projeto. Essa parte ainda depende de eu notar o padrão se repetindo e mandar consolidar.

Na minha estimativa, isso resolve uns 99% do trabalho de revisão e resolução sozinho, comigo supervisionando e decidindo os casos que sobram. Só que isso não é o ponto principal. Automação de revisão é necessária, mas ela sozinha não prova nada sobre se o software é bom.

O que realmente mantém isso no chão: gente de verdade usando

Aqui está a parte que eu acho mais importante do artigo inteiro, e que costuma passar batido: a sua própria revisão não vale tanto quanto você acha. O que vale é software publicado sendo usado por gente de verdade, dando feedback de verdade.

Fui checar os números reais do ai-memory no GitHub, sem arredondar pra impressionar:

• issues: 287 no total, 249 vieram de gente que não sou eu, 86,8% do total;
• pull requests: 562 no total, 371 de fora, sendo 10 delas bump automático do Dependabot e as outras 361 vindas de gente de verdade, cerca de 121 contribuidores distintos.

Os dois que mais contribuíram junto comigo mandaram 64 e 43 PRs cada, sozinhos.

Isso é o que mantém o projeto no chão. Não é o LLM sendo bom revisor, nem eu sendo bom revisor. É centenas de pessoas usando de verdade, achando casos que eu nunca imaginei, e mandando issues e PRs reais. Sem isso, minhas skills de revisão automatizada estariam apenas confirmando as minhas próprias suposições de volta pra mim, por mais rigorosas que as regras pareçam no papel.

Não importa o quão boa é a IA que você usa: se ninguém usa o que você publicou, você não tem feedback real, e sem feedback real não existe melhoria real. Só existe a sua própria opinião sobre o próprio trabalho, validada por ninguém além de você mesmo.

A conclusão que interessa

Engenharia de software de verdade precisa ter deploy rápido e de esforço quase zero. Não é opcional, não é luxo de time grande, é pré-requisito. E se revisar e colocar em produção está demorando mais tempo do que desenvolver a funcionalidade, você não está só errado.

Você é o gargalo.

Desculpa e justificativa não valem nada nesse momento. Use esse tempo pra consertar você mesmo e o seu processo, porque só resultado no mundo real importa, não a sensação de segurança de ter revisado linha por linha um diff que ninguém mais vai olhar de novo.

Se a premissa mudou, eu mudo hoje. Não amanhã, não semana que vem. E se a sua ainda não mudou, o problema não é a IA. É você segurando o próprio trabalho.

E a recomendação vem logo de cara, porque ela é o motivo do artigo existir: não use as skills dos outros. Lê de novo. As minhas skills estão publicadas no meu repositório my-skills e a descrição do repo avisa em inglês: “not tailored for general usage”. Elas estão lá pra você ler o raciocínio, entender a estrutura, e ir construir as suas. Copiar skill de terceiro e sair usando é o equivalente digital de assinar um contrato sem ler. Pior: é instalar as instruções de outra pessoa pra rodar com as suas permissões, nos seus repositórios, com os seus tokens. Prompt injection você instala voluntariamente e agradece.

O que é uma skill, de verdade

Não tem mágica nenhuma. Uma skill é um diretório com um arquivo SKILL.md dentro: um cabeçalho com nome e descrição, e um corpo de texto que é, essencialmente, um prompt bem escrito sobre como executar uma tarefa. Às vezes acompanha um scripts/ com scripts de apoio, pra que o LLM não precise recriar do zero toda vez.

Skills são só prompts.

É só isso. Um prompt que você versionou, refinou, e deixou a um comando de distância. A única diferença entre uma skill e aquele prompt gigante que você cola no chat todo dia é que a skill mora num arquivo, com nome, e o agente sabe que ela existe.

E aqui vai a resposta pra pergunta que todo mundo faz: “mas isso não enche o contexto de porcaria?”. A boa notícia é que os harnesses fazem isso direito. O Claude Code usa o que a Anthropic chama de progressive disclosure: no início da sessão, só o nome e a descrição de cada skill entram no prompt do sistema. O corpo do SKILL.md só é carregado quando o agente decide invocar a skill. O OpenCode faz igual: lista nome e descrição, e carrega o conteúdo sob demanda via ferramenta própria. A própria Anthropic documenta o desenho: metadados primeiro, corpo só quando precisa.

Isso resolve o custo do texto, mas resolve só metade do problema. Cada skill instalada ainda ocupa uma linha na listagem, e mais importante: ela disputa a atenção do agente na hora de decidir qual ferramenta usar. A Anthropic de novo, no blog de engineering: “more tools don’t always lead to better outcomes”, mais ferramentas nem sempre melhoram o resultado, e a recomendação oficial deles é ter poucas ferramentas bem pensadas pra workflows de alto impacto. A minha versão dessa regra é mais ácida:

Skill encostada é dívida.

Você muda de processo, a skill envelhece, e um dia o agente executa uma regra que nem faz mais sentido no seu workflow. Menos skills, melhor escritas, revisadas com frequência.

A única skill de terceiro que sobreviveu aqui

Dito tudo isso, seria hipócrita fingir que eu vivo só de skill caseira. Uma sobreviveu ao meu crivo e roda em todo post deste blog: a Humanizer.

Ela existe porque a comunidade da Wikipedia mantém um catálogo público e brutalmente honesto chamado Signs of AI writing, mantido pelo WikiProject AI Cleanup, que documenta uma a uma os “tells” de texto gerado por IA: a regra de três, o “não apenas X, mas também Y”, o puffery, o bullet decorado com emoji. A Humanizer pega esse catálogo e vira um procedimento: o agente recebe o texto, marca os tells do mais forte pro mais fraco, reescreve preservando cada alegação suportada (perder fato é erro, inventar fato é erro), e faz uma checagem final lendo em voz alta. Sem alterar o que foi dito, só como foi dito.

Se você produz conteúdo, entende por que eu insisto: texto com cheiro de IA está virando o novo “Dear Sir”, marca de formulário apressado. Eu rodo a Humanizer em cada artigo antes de publicar, inclusive neste aqui. Mas nota o detalhe: eu incorporei a versão 3.0.0 no meu repo, com os meus ajustes. Eu li o material de origem antes de confiar. É esse o padrão.

O que eu faço com isso todos os dias

Agora a parte prática. Eu mantenho e monitoro mais de 40 repositórios no GitHub. Projetos próprios, forks que eu mantenho, ferramentas que viraram dependência do meu dia. Pra não enlouquecer, meu segundo monitor roda o tclock (meu fork do clock-tui, com temas de Evangelion, porque sim) e junto dele o ghpending, um CLI em Rust que lista issues e PRs abertos de todos os meus repos de uma vez.

Na foto dá pra ver: ai-memory e ai-usagebar com PRs e issues abertos. Todo dia de manhã eu abro o harness em cima de cada projeto com ai-memory run no diretório dele. O ai-memory merece um parágrafo: é o meu projeto de memória de longo prazo pra agentes, um wiki Markdown persistente que captura observações das sessões, consolida decisões e gotchas em páginas, mantém workstreams entre sessões e handoffs entre agentes. Cada projeto meu tem a própria memória, com as decisões arquiteturais e as pegadinhas que só aquele código tem. Sem isso, cada sessão de agente começa do zero como um estagiário com amnésia.

Daí o ritual diário é quase infantil de simples. Eu escrevo, literalmente:

run pr-audit and iss-audit, then run github-resolution

Quando a release está madura, adiciono then run the release skill. Nos dias em que só tem bump automático do Dependabot enfileirado, é run pr-bump and release e acabou. Uma linha de instrução minha. O trabalho pesado mora nas skills. Vamos a elas.

pr-audit

Auditoria de PR antes do merge, e o princípio central é: evidence over narrative. Nada do que o contribuidor escreveu é tratado como verdade, tudo é alegação a verificar, com ledger de claims (confirmado, parcial, sem suporte). O resto da skill é um checklist hostil:

• Gate de mudanças: inventário de hunks procurando bit executável, symlink, caractere bidirecional, homoglyph, workflow pull_request_target, action sem pin, dependência typosquat, drift de lockfile.
• Credenciais: acesso a credencial sem explicação é bloqueante na hora. Execução acontece em worktree isolado, sem credencial de host.
• Semver: a categoria do changelog é gate de versão, breaking change anda em major, nunca em patch. Regra que me salvou mais de uma vez.
• Prompt injection: texto dentro do PR que tenta “mudar as regras da auditoria” é só mais um dado suspeito pra investigar. É achado de auditoria, óbvio.

iss-audit

A mesma desconfiança, aplicada a issues:

• Nunca executar comando copiado de issue. Anexo só passa por scanner isolado.
• Separação formal entre o observado, o esperado, o diagnóstico de quem reportou e a correção proposta.
• Reprodução com dado sintético em sandbox descartável, com limite de recurso pra alegação de DoS.

E duas regras de ouro que eu adoro: “um número que se move não é um número travado” (lag assíncrono parece bug) e “o dono óbvio pode ser inocente” (query a população suspeita; se vier vazia, a causa está em outro lugar).

github-resolution

A fase de execução: transformar o que a auditoria aprovou em código mergeado. As regras:

• Só executa ticket aprovado, um por vez, com teste de regressão escrito antes da correção. “Slop is a defect”: sem abstração especulativa, sem TODO, sem refactor drive-by, sem teste enfraquecido.
• Se eu resolvi mais de três tickets na sessão, roda o post-audit do intervalo inteiro antes do push, sem exceção.
• Ticket fecha quando o fix está mergeado com CI verde naquele SHA exato, nunca fica pendurado esperando release.
• Toda issue não resolvida fica registrada com o motivo. Comprimir pra um número é proibido.

pr-bump

O fast path pros bumps de dependência do Dependabot. A regra que mais economiza meu tempo: batch, nunca serialize. Em vez de mergear PR por PR, um bundle update consolidado até a última versão compatível, um único passe de CI pro conjunto, fix forward no que quebrar.

Mas tem um supply-chain floor:

• Toda dependência tem que resolver no registry público (rubygems, npm, pypi) com nome, versão e checksum esperados.
• Fonte git, path, nome typosquat-adjacente, hook novo de install: para tudo e vai pra auditoria completa.

bundler-audit passa numa gem trojanizada bem formada. É exatamente o caso que o floor cobre.

release

Corta versão só quando eu peço. As regras de ferro:

• Versão sai da classificação do changelog: fix vai em patch, aditivo em minor, breaking em major. Número que conflita com a classificação me obriga a confirmar, bump silencioso é proibido.
• Gate de CI verde no SHA exato da tag. Nunca tag em CI pendente ou pulado.
• Tag anotada, changelog atualizado.
• Nunca reescrever tag publicada. Nunca cortar release que ninguém pediu.

Os números, porque números não discutem

Contando agora, no dia em que escrevo este artigo, só em três projetos (ai-memory, ai-usagebar e ai-jail):

• ai-memory: 430 PRs mergeados, 260 issues fechadas
• ai-usagebar: 137 PRs mergeados, 34 issues fechadas
• ai-jail: 42 PRs mergeados, 81 issues fechadas

Somando: 609 PRs mergeados e 375 issues fechadas, mais de mil itens. Quase a totalidade disso foi tratada por essas skills, comigo supervisionando e decidindo. Uma pessoa sozinha, sem time, mantendo três projetos ativos nesse volume. É esse o multiplicador.

E elas não nasceram prontas

Abre o histórico de commits do my-skills e você vê skill sendo lapidada na marra. Em julho começa o repo com as auditorias básicas. No fim de julho: “harden audit skills and add security audit”. Em agosto: “consolidate agent skills from all harnesses into this repo” e, dias depois, nasce a github-resolution como fase de execução das auditorias. Em setembro: “fold in release-discipline and audit lessons”.

E ontem mesmo, olha o nível do ajuste fino no pr-bump: “batch all bump PRs into one consolidated verification pass, fix forward on failures” e “require deferred/declined PRs be left in a clean state”. Duas regras que viraram texto de skill. Nenhuma delas saiu de blog post ou de opinião de terceiro: saiu de eu tomar na cara o erro que a regra agora impede.

Cada linha dessas skills é cicatriz.

É assim que se escreve prompt bom: prestando atenção no resultado, decidindo ajustar, ajustando de novo.

Skills são pouco. Conhecimento é muito.

Agora o contraponto, porque eu não quero que você saia daqui achando que a resposta pra tudo é skill. Eu dependo pouco delas. O que carrega meu workflow mesmo é outra coisa.

Cada projeto meu tem seu próprio AGENTS.md, instruções específicas daquele código, e sua memória no ai-memory com decisões e gotchas. E o padrão que eu mais uso no dia a dia nem é skill: é apontar pro exemplo vivo. Quando eu quis AUR automatizado pro clock-tui, eu não escrevi skill de “como fazer pacote AUR”. Eu abri o harness e falei:

make a similar github action to build and publish AUR packages
as we did in ~/Projects/ai-memory

O agente foi lá, leu o workflow que funciona, e reproduz o padrão no novo projeto. Skill pra isso seria pior: AUR muda, GitHub Actions muda, o exemplo fica velho. Exemplo vivo em repo que eu mantenho está sempre atualizado por definição, porque quando ele quebra, eu conserto.

Cada projeto vira base de conhecimento de si mesmo.

E isso generaliza, porque harnesses conseguem consumir qualquer base de texto. Meu PC Linux inteiro está documentado e reinstalável a partir de um repo de config meu, e meu homeserver está todo descrito em runbooks. Esses dois não estão no GitHub: moram num servidor Gitea privado que eu mantenho, porque é o tipo de coisa que eu não quero vazada em público. Quando eu quero mexer em casa, eu falo assim:

add integration to my Plex server as documented in my homelab runbooks

Não é skill. É conhecimento organizado, versionado, consultável. Skills são pra procedimento que se repete igual. Conhecimento é pra tudo o mais.

A recomendação que vale mais que qualquer skill

Se você levar uma única prática deste artigo, que seja esta: faça seu agente escrever tudo o que não virou código. Pesquisa que ele fez, decisão que você tomou e por quê, comparação com alternativa rejeitada. Sem isso, esse conhecimento evapora no fim da sessão.

O meu ai-memory, por exemplo, tem uma pasta de docs com pesquisa de competidores que eu mandei fazer antes de cada decisão grande:

• O padrão do wiki do Karpathy, que é a origem intelectual do projeto.
• Survey do landscape 2026, cobrindo Zep/Graphiti, Letta, Mem0 e o Open Knowledge Format do Google.
• Deep-dives de cada concorrente: o Hindsight (o único com paper e funding, que acabou validando minhas apostas de design), o cognee (pipeline de grafo bonito, bug de gateway feio), o agentmemory (do qual eu guardei as ideias e joguei fora o substrato), o basic-memory.
• E a minha favorita, a autópsia do MemPalace: 47 mil stars, viral, e o tracker entupido de corrupção de índice e dado perdido. O conto de fadas ao contrário que me confirmou por que compilar memória é melhor que estocar verbatim.

Dezenas de documentos assim. Cada hora de pesquisa que um agente fez pra mim virou ativo permanente, reutilizável em qualquer projeto novo. Quanto mais você produz e documenta, mais inteligência você acumula.

É juro composto de conhecimento.

Ninguém sabe o que você precisa

E aí fecha o círculo, e voltamos ao ponto do começo: por que eu não recomendo copiar skill de ninguém, nem a minha.

Porque a minha skill de auditoria de PR é moldada em meus projetos, minhas linguagens, meus riscos, meu nível de paranóia com supply chain. Ela reflete o que eu, Fabio, mantendo os repositórios que eu mantenho, na infra que eu tenho, com os objetivos que eu tenho, precisei escrever nela. Seu projeto tem outra stack, outros riscos, outro grau de tolerância. Você pode precisar de checagens que eu não preciso, e o inverso. A experiência é relevante só pra quem viveu as restrições dela. Isso muda de pessoa pra pessoa, e é exatamente por isso que skill de terceiro usada às cegas é aposta.

É a tese do meu vídeo de 2019, Não Terceirize suas Decisões: a lição mais importante da sua vida: ninguém além de você sabe o que você precisa.

Eu não pergunto pra ninguém. Eu pesquiso, eu construo o meu, e as skills são o registro versionado das minhas decisões. A beleza dos LLMs é que eles aceleram esse processo em 10 vezes: a pesquisa que levava uma semana agora leva uma tarde, e o custo de construir sua própria ferramenta despencou.

Skill boa é a sua. A minha está no my-skills pra você ler o raciocínio. Depois fecha a aba e escreve a sua. Eu não desperdiço tempo pedindo a opinião dos outros. Você também não deveria.

Deixa eu adiantar minha regra antes de entrar no caso específico, porque ela vale mais que o caso em si.

Minha regra: não uso nada até doer não ter

Depois de mais de meio milhão de linha de código produzida com IA nos últimos meses, dezenas de projeto no ar, um benchmark inteiro rodado do zero três vezes, minha recomendação pra quem programa é direta: não use nenhuma ferramenta de orquestração ou camada intermediária até você sentir na pele que precisa de ajuda extra. Use o harness que você já gosta, Codex, opencode, Claude Code, sei lá qual, direto, sem intermediário, e esquece o resto.

Não vale nem a pena gastar tempo coletando pacote de skill de terceiro pra empilhar em cima do seu agente. Constrói, treina, junta experiência pro seu próprio caso de uso. Ninguém mais no mundo tem o seu projeto, o seu contexto, a sua base de código. O pacote de skill de outra pessoa foi desenhado pro problema dela, não pro seu.

Já bati nessa tecla faz um mês: quando a tecnologia vira commodity, o dinheiro migra pra taxonomia. Cria nome bonito pra encadear chamada de API, e do nada nasce curso, certificação e consultoria em cima do nome. O TypeSafe é só mais um capítulo da mesma história, então virou desculpa boa pra mostrar como eu decido se vale a pena até abrir a aba.

Pra guardar: não use ferramenta de orquestração ou camada intermediária até sentir na pele que precisa dela. Construa experiência pro seu próprio caso de uso, não colecione pacote de skill de outra pessoa.

O gatilho: TypeSafe

Abri o site e o post de lançamento deles, o Jev. Minha primeira impressão, bem superficial e crua: não gostei e não confiei. A home é um festival de jargão de IA empilhado, Kahneman aqui, Jevons ali, glifo decorativo, número de “193x mais rápido” sem o benchmark do lado. Na primeira olhada, nada daquilo faz sentido sozinho.

E tem o detalhe que sempre me deixa em guarda: toda vez que a primeira coisa que alguém diz sobre si mesmo é “eu sou um ex-pesquisador da OpenAI” ou parecido, eu desconfio primeiro e pergunto depois. Parece tentativa de colar credencial pra virar credível antes de qualquer prova real. O fundador do TypeSafe fala alto demais de si mesmo logo de cara, e isso por si só já é motivo pra apertar o botão de ceticismo.

Só que desconfiômetro ligado não é conclusão. É o ponto de partida pra investigar de verdade, não pra descartar sem olhar. Essa é a parte que eu quero mostrar aqui, meio que uma aula prática pra quem me acompanha: como eu uso IA pra correr rápido numa pesquisa preliminar, como eu leio a letra miúda antes de assinar embaixo de qualquer conclusão, minha ou de terceiro, e como eu movo a desconfiança inicial pra pesquisa de verdade até descobrir se eu estava certo ou só sendo chato.

E deixo isso registrado antes de continuar: eu posso estar errado em algum ponto específico daqui pra frente. Se você tiver contraprova de peso, manda nos comentários. Prefiro apanhar em público e corrigir o texto do que empurrar produto picareta pro meu público só porque não conferi direito.

Perguntei pras IAs, não confiei nas IAs

Mandei o mesmo prompt pro Grok e pro Claude: pesquisa isso a fundo, minha impressão inicial é muito cética, ex-OpenAI-researcher cheira a tentativa de colar credencial, o site é jargão pra todo lado, me diz qual é o discurso de venda de verdade, pra que serve na prática, e se a lógica deles, por trás do jargão, sequer faz sentido.

Os dois voltaram com pesquisa longa e detalhada, história parecida em ambos: a credencial do fundador é real, mas inflada; o produto é mais estreito e mais coerente do que a home deixa parecer; e o “não pode alucinar” é uma alegação de schema disfarçada de alegação de verdade.

Só que eu já entreguei minha própria conclusão dentro do prompt pras duas, então a concordância entre elas prova menos do que parece. Duas IAs concordando com a hipótese que eu mesmo escrevi no pedido não é confirmação independente de nada, é eco. Isso não invalida o que elas trouxeram, mas significa que eu não podia parar ali. Eu não ia publicar isso batendo o carimbo em cima do que duas IAs me contaram. Pedi uma nova rodada de pesquisa, agora comigo checando cada afirmação com fonte primária: o paper de verdade, o post de lançamento direto na fonte, os testes independentes de terceiros, e se “RLCD”, o nome que eles usam pro método de treino, é um paper de verdade ou só um nome bonito sem verificação nenhuma por trás.

O que o Jev realmente é

Tirando o marketing, o Jev é um classificador hospedado. Você manda um texto e uma lista de perguntinhas, cada uma com um tipo fixo de resposta:

• escolher uma opção de uma lista;
• dar uma nota numa régua;
• responder sim ou não, com probabilidade.

Ele não escreve nada, não planeja nada, não conversa. Código decide o fluxo; o modelo só responde a perguntinha rápido, em paralelo, sem gerar texto livre.

Como produto, isso é razoável: tem gente que hoje manda um texto pra um LLM de chat só pra ele devolver um rótulo dentro de um JSON, espera oito segundos, e reza pro schema não quebrar. Trocar isso por uma chamada que devolve só o rótulo, rápido, é engenharia legítima. O problema nunca foi a ideia. É a embalagem em volta dela.

Os fatos que eu confirmei

Aqui estão as descobertas que realmente sobreviveram à checagem com fonte primária, não o que a IA me contou de segunda mão.

A credencial do fundador é real, mas a página da própria empresa exagera de um jeito que dá pra provar que é exagero. O Diogo Almeida é o quarto de vinte autores do paper do InstructGPT, publicado e revisado por pares na NeurIPS 2022, a conferência de peso da área. Autor de verdade, posição de peso, paper de verdade. Só que a página da equipe do TypeSafe diz isto, ao pé da letra:

“Diogo co-inventou o RLHF e o InstructGPT, os métodos que levaram ao ChatGPT e ao GPT-4.”

RLHF é de 2017, cinco anos antes, assinado por outro time (Christiano, Leike, Amodei e companhia), sem o Diogo em lugar nenhum. Ele ajudou a aplicar RLHF pra treinar o InstructGPT. Não inventou RLHF. É a mesma inflação de currículo que eu já desconfiava antes de checar qualquer coisa, só que agora com prova.

O financiamento é real: $40 milhões de seed liderado pela DCVC, valuation de $200 milhões confirmado pela Forbes de forma independente, não só pelo press release da própria empresa. Isso é dinheiro sério, não é golpe de um cara sozinho numa garagem.

O post de lançamento admite, com as próprias palavras, exatamente o que eu suspeitava sobre o gráfico de “zero alucinação”:

“Nosso número não é empírico. Como o casamento com o schema é garantido, podemos colocar 0% no gráfico com confiança.”

Ou seja: o zero não vem de medir nada, vem de garantir que a resposta sempre cabe dentro das opções permitidas. Isso impede o modelo de inventar uma quinta categoria quando só existem quatro. Não impede o modelo de escolher a categoria errada com confiança de 93%. É a mesma crítica que o The Register publicou: a comparação não é justa porque a saída não é linguagem, e resposta com tipo válido ainda pode estar simplesmente errada.

O próprio post também admite qual é a régua usada pra medir “precisão”: “usamos a média do GPT-6 Astra e do Fable 5.1 como resposta de referência”, e completa admitindo que isso “gera viés a favor dos modelos da OpenAI e da Anthropic”. Ou seja, o gabarito é a média do que dois outros modelos de outras empresas responderam, com viés admitido pelos próprios autores, não verdade objetiva medida por humano.

O único teste feito por alguém de fora, o da newsletter Every, achou o Jev cerca de vinte e cinco vezes mais rápido, 0,35 segundo contra 8,83 segundos por passagem, e muito mais barato que o Claude Fable 5.1, só que pegando seis de sete defeitos plantados contra os sete de sete do Fable. Mais rápido e mais barato, de verdade. Também mais fraco, de verdade.

E o achado que nem o Grok nem o Claude bateram o martelo total, mas que confirmei sozinho: o nome do método de treino deles, RLCD, já existe. Tem um paper de verdade, revisado por pares, de 2023, Reinforcement Learning from Contrastive Distillation, de um time completamente diferente, com código dos próprios autores publicado no GitHub da Facebook Research, já que dois dos cinco autores são da Meta. É uma técnica diferente, sem relação nenhuma com o que o TypeSafe descreve. O RLCD deles não tem paper, não tem arquitetura publicada, não tem nada pra revisar. É nome emprestado de pesquisa alheia colado num método que, até prova em contrário, é só um parágrafo de blog.

Minha desconfiança tinha fundamento?

Tinha. A ideia de produto é legítima e razoavelmente coerente por trás do jargão: decisão fechada e barata em volume alto é um problema real que hoje é resolvido de um jeito lento e caro, gerando texto livre só pra depois extrair um JSON dele. Resolver isso rápido tem valor de verdade.

Mas “alegação exagerada e sem muita diferença prática” também se confirma ponto a ponto:

• o currículo do fundador é inflado de um jeito que dá pra provar com data de publicação;
• o número mais chamativo do lançamento, zero alucinação, é definição de schema, não medição;
• o gabarito de precisão é média de LLM de outra empresa, não verdade objetiva;
• o único teste de fora achou o produto mais fraco que o modelo que ele promete substituir;
• o nome do método de treino mais citado colide com um paper de verdade que não tem nada a ver com eles.

Isso não é motivo pra chamar de golpe. É motivo de sobra pra chamar de “produto pequeno com discurso grande demais pro que ele realmente entrega”. E antes de eu confiar meu dado a mais um terceiro que eu não conheço, com API fechada, lista de espera e sem paper publicado de nada que sustente o nome bonito, o cálculo de risco contra benefício não fecha pro meu caso de uso.

Pra guardar: credencial real não é a mesma coisa que credencial honesta. Confira a data de publicação antes de acreditar no currículo, e confira o paper antes de acreditar no nome do método.

Isso não é decreto final sobre o TypeSafe nem sobre o currículo do Diogo Almeida. É o resultado da checagem que consegui fazer com o que estava acessível até agora. Se você achar o paper que eu não achei, o benchmark independente que eu não vi, ou qualquer prova que derrube um ponto específico, os comentários estão abertos e eu leio. O objetivo aqui nunca foi provar que eu sou infalível. É mostrar como sair de “sinto cheiro de golpe” pra “aqui está a prova”, e estar disposto a admitir quando a prova aponta pro lado contrário.

O “193x mais rápido” denuncia um jeito errado de usar LLM

Voltando pro Jev: o choque de “193x mais rápido que um LLM” só existe porque a comparação é contra um jeito específico, e comum, de usar LLM. Manda um texto pra um modelo de chat, pede pra ele devolver um rótulo, espera o modelo escrever uma resposta inteira em linguagem natural, e depois faz o seu código catar esse rótulo lá dentro de um parágrafo ou de um JSON solto na resposta. Isso é lento, caro, e cheio de chance de o schema quebrar.

O Jev existe justamente porque essa comparação é fácil de vencer. Ele não gera texto livre, só responde perguntas de tipo fixo, uma opção de uma lista, uma nota numa régua, sim ou não com probabilidade. É o que a própria documentação chama de primitivas: Choice, Score e Noul. Trocar “LLM escrevendo um parágrafo pra você extrair um rótulo dele depois” por “chamada que já devolve o rótulo pronto” é, sim, uma vitória de engenharia. Só que essa vitória não vem de ter inventado uma categoria nova de modelo. Vem de parar de usar LLM de chat pra fazer um trabalho de classificação estruturada.

E aqui é onde eu acho que a reação de espanto de muita gente com o número do Jev revela o hábito errado: o LLM nunca devia estar gerando texto livre pra decisão fechada e repetida em cima do mesmo tipo de pergunta. Se seu produto precisa, toda hora, decidir entre um punhado fixo de categorias, a resposta certa não é implorar pro LLM “responda só com o JSON, por favor” e torcer. É construir, ou usar, um classificador de verdade pra aquele trabalho específico.

E isso não é ideia nova nem exclusividade do Jev. Existe desde muito antes dele:

• classificador supervisionado, regra determinística ou modelo encoder, pra rótulo fixo e bem definido;
• classificação zero-shot, estudada desde 2019 e disponível via API da Hugging Face, pra quando a lista de categorias muda a cada chamada;
• calibração de probabilidade, método estabelecido pra transformar a confiança de um classificador numa métrica que realmente significa alguma coisa;
• saída estruturada / decodificação restrita em qualquer LLM que já suporte isso, que garante schema válido sem trocar de produto nem de fornecedor.

O Jev empacota um pedaço disso numa API paga e conveniente. Não inventou a categoria. E tem até alternativa aberta pro mesmo padrão, o Laya servido pelo Arbiter, rodando local, sem depender de terceiro nenhum.

Então, respondendo direto: minha desconfiança inicial de que “gente estava usando LLM errado” tem fundamento real, mas com uma ressalva importante. Não é verdade que LLM é incapaz de classificar. Classificação zero-shot com LLM funciona e está documentada desde 2019. O erro específico é mais estreito: usar um LLM de chat generalista, sem restrição de formato, pra gerar uma resposta livre da qual você extrai um rótulo na mão, quando o seu problema já é um problema de classificação fechada e repetida. Esse é o antipadrão. A cura não é necessariamente comprar o Jev, é ou aplicar saída estruturada no LLM que você já usa, ou treinar um classificador de verdade pra aquele trabalho específico, dependendo do volume e da precisão que você precisa.

E “virar classificador” também não é bala de prata contra alucinação, nem no próprio Jev. Existem dois problemas diferentes escondidos atrás da palavra “alucinar”, e trocar de produto só resolve um deles:

1. Alucinação de formato: o modelo inventa uma categoria que não existe, ou devolve algo fora do schema. Saída estruturada resolve isso, seja no Jev, seja em qualquer LLM com decodificação restrita.
2. Erro de julgamento: o modelo escolhe a categoria errada, dentro das opções válidas, com confiança alta. Isso não desaparece só porque a saída tem tipo fixo.

O próprio documento de limitações do TypeSafe admite interpretação literal, contagem numérica fraca, erro de comparação de data, degradação com contexto irrelevante, e suscetibilidade a manipulação adversarial no próprio Jev. E o teste independente com 2 mil e-mails de phishing achou o veredito direto do Jev em 62,6% de acerto contra 81,3% do Claude Haiku 4.5, mais rápido e mais barato, só que menos preciso que o LLM de chat que ele se propõe a substituir. Um teste separado com 27 tickets achou o Jev empatado com um modelo de chat barato, amostra pequena demais pra virar regra, mas o suficiente pra deixar claro que “virou classificador” não é sinônimo automático de “ficou mais preciso”.

Justiça seja feita com o mesmo teste de phishing: quando em vez de pedir um veredito único, o Jev responde cinco perguntas de sinal separadas e o código combina as cinco numa decisão, a acurácia sobe pra 95%, batendo até a versão composta do Claude com os mesmos cinco sinais (93,2%). Isso não invalida o número anterior, o veredito único de 62,6% continua sendo o veredito único de 62,6%, mas reforça exatamente o argumento deste texto: decompor a decisão em perguntas de tipo fixo e deixar o código compor o resultado bate um LLM respondendo tudo de uma vez, seja isso feito com Jev, com saída estruturada, ou com um classificador treinado pra aquele sinal específico.

Pra guardar: se o seu problema é decidir a mesma coisa, do mesmo jeito, várias vezes, construa ou use um classificador de verdade pra esse trabalho específico, com saída estruturada ou modelo dedicado. O ganho de trocar isso é real. O que não é automático é achar que qualquer produto que se chama “classificador” vai acertar mais que o LLM que ele substitui, porque às vezes acerta menos.

E essa história de economizar token?

O caso do TypeSafe me lembrou de uma implicância separada que eu já queria colocar no papel, e não é sobre eles especificamente: a promessa de economia de token e de custo que praticamente todo produto desse tipo vende. É sobre a categoria inteira de ferramenta que promete “economize X vezes gastando com a gente em vez de gastar direto com seu provedor”, não uma acusação a mais contra o TypeSafe.

Toda nova versão de modelo, e toda atualização de harness, muda a conta inteira, às vezes de um jeito violento. Quando eu pulei do GPT Sol pro Astra, vi minha cota semanal de assinatura secar muito mais rápido do que eu esperava, sem eu ter mudado nada no meu jeito de trabalhar. Foi só o modelo novo consumindo diferente. Isso é a regra desse mercado, não exceção: OpenAI, Anthropic e companhia vão continuar mexendo em preço, em quantização, em política de cache, e em quanto raciocínio cada modelo gasta por baixo dos panos, com ou sem o meu consentimento.

Construir sua estratégia em cima de “economizar token” é apostar numa fundação que muda de mês em mês, decidida por gente que não te consulta. Uma ferramenta de meio de caminho que promete cortar custo hoje pode ficar irrelevante, ou pior, ficar mais cara que o caminho direto, na próxima atualização de modelo. É o mesmo motivo pelo qual eu não uso orquestrador nem framework de skill: quando o alicerce muda toda hora, complicar a estrutura em cima dele é ficar refém de manutenção sem necessidade.

Eu prefiro gastar token no talo e focar se o resultado que eu tiro daquele gasto vale a pena. Até agora, com minha assinatura, estou satisfeito com o que consigo produzir. Não sinto vontade nenhuma de gastar tempo cortando token, um esforço que sempre carrega o risco de piorar a qualidade da resposta em troca de uma economia que a próxima versão do modelo pode apagar sozinha.

Pra guardar: não construa estratégia em cima de preço e consumo de token, porque isso muda de mês em mês por decisão de gente que não te consulta. Meça se o resultado vale o gasto, não o gasto em si.

E se um dia eu conseguir gastar token o suficiente pra ferver um lago inteiro com o calor do datacenter, eu vou gastar com o maior prazer do mundo. É minha vingança pessoal contra quem me obrigou a usar canudo de papel que desmancha na boca por tantos anos.

Eu já vinha dizendo, e repito sempre que posso: modelos de fronteira estão convergindo, batendo no teto da curva S da evolução tecnológica. Aquele artigo mostrou isso na prática, com um detalhe extra: quem ainda tinha espaço pra crescer, cresceu, e foi convergindo pro mesmo teto de quem já estava lá em cima.

Passaram-se pouco mais de três semanas sem eu voltar ao assunto aqui. Nos bastidores, eu rejeitei um benchmark inteiro e recomecei do zero.

Essa é a Parte 1 dessa história: o processo, o que eu joguei fora, o que eu construí no lugar e quanto isso custou. A Parte 2 traz o ranking completo, modelo por modelo.

O problema que o v2 não resolveu

O v2 já era mais difícil que o v1, com três fases, streaming real, multi-turn, concorrência, tools de verdade. Resolveu o problema de discriminar quem sabe construir de quem alucina API. Não resolveu o problema seguinte: uma vez que o modelo sabe construir, o teste inteiro vira uma prova de completude. Completude satura rápido. Prompt bem escrito, requisito bem numerado, e os modelos de fronteira de hoje entregam praticamente tudo. A diferença entre 96 e 91 pontos passa a ser ruído: um teste que faltou, um Dockerfile com detalhe a mais.

Isso se repete em qualquer prova de programação isolada e bem definida no momento em que os modelos de fronteira aprendem a prova, não é exclusividade do meu benchmark. E foi exatamente aí que eu decidi ir mais fundo, em vez de só ajustar prompt de novo.

A tentativa errada: v3

Minha primeira ideia pra separar os modelos foi óbvia: se um app inteiro satura, quebra em pedaços menores e mais difíceis. Comecei o v3 em 5 de setembro com dezoito tarefas isoladas, cada uma com um gabarito escondido:

• debug de causa raiz em Ruby;
• correção de edge case em Go;
• invariante de longo prazo em Python;
• performance sob teto rígido em Rust;
• refactor seguro preservando comportamento;
• julgamento em situação ambígua;
• mais uma dúzia de variações em segurança, latência, CVE plantado, N+1, SQL injection e resolução de dependência.

Pedi pro Claude trabalhar comigo nisso. E aconteceu uma coisa engraçada: sem eu pedir explicitamente, ele foi empurrando o design pra exatamente o formato que eu mais critico, uma sequência de desafios pequenos e isolados, no estilo SWE-bench, HumanEval, LeetCode de entrevista técnica. Eu devia ter visto vindo. É o caminho de menor resistência pra quem já treinou nesse tipo de prova de mercado a vida inteira.

O resultado veio rápido, e foi ruim do jeito que eu temia. Vinte e quatro dos trinta e sete modelos testados fizeram entre 95 e 100 pontos na versão final da suíte. O relatório que ficou registrado no repositório chama isso pelo nome certo:

O v3 é o CAMINHO ERRADO documentado, mantido aqui só pra registro histórico. Otimizar demais contra a saturação levou o v3 a microtarefas abstratas, sintéticas, restritas à biblioteca padrão da linguagem, o mais longe possível da realidade concreta. Ele até ranqueia os modelos, mas não é assim que software de verdade é construído, então satura em qualidade e mede a coisa errada.

E o motivo de fundo, também registrado no mesmo relatório:

Você não consegue ter ao mesmo tempo “ancorado na realidade do dia a dia” e um espalhamento grande de qualidade entre os modelos de fronteira. Qualquer coisa do dia a dia já está bem representada no treino, então a fronteira já dominou aquilo, então satura.

Isso bate com algo que eu já pensava fazia tempo, e que essa experiência só confirmou: uma sequência de desafios de código é um problema de complexidade linear. Você resolve a tarefa 1, depois a 2, depois a 3, cada uma isolada, cada uma testável sozinha.

Aplicação real de verdade não funciona assim. O código se conecta numa teia: você muda um model aqui, quebra o serializer ali e o job em background em outro canto nem avisa até rodar em produção. É complexidade não linear, coordenação entre partes que interagem, não uma fila de provas independentes. Um modelo pode ser ótimo resolvendo mil desafios isolados de LeetCode e ainda assim não saber manter um sistema real coerente enquanto ele cresce.

E eu não sou o único incomodado com isso. Boa parte da indústria de benchmarks de código está passando pelo mesmo raio-x. O SWE-bench, criado pela Princeton NLP em 2023 e adotado como referência do setor inteiro, teve sua versão mais usada, o SWE-bench Verified, oficialmente aposentada pela própria OpenAI em 2026: numa auditoria de 138 falhas consideradas difíceis, 59,4% eram teste malformado, não erro do modelo, e boa parte do ganho de 74,9% pra 80,9% em seis meses veio de solução memorizada, não de capacidade nova.

O sucessor cotado, SWE-bench Pro, também levou puxão de orelha da própria OpenAI: cerca de 30% das tarefas estavam quebradas. HumanEval e MBPP, os clássicos de “resolva essa função isolada”, estão saturados desde muito antes disso e com contaminação documentada: as 164 soluções do HumanEval já foram encontradas espalhadas em repositórios do GitHub usados pra treinar os próprios modelos que a prova testa.

Cerca de metade dos PRs que passam no SWE-bench Verified não seriam de fato aceitos por um mantenedor humano de verdade, e o motivo mais comum é quebrar outra parte do código.

Isso é o resumo de um estudo da METR, publicado em março de 2026. Outro levantamento mostrou que a taxa de resolução dos melhores agentes despenca de 72% pra 28% quando a tarefa deixa de ser single-file e passa a exigir mudança em múltiplos arquivos. É a mesma lição, vinda de fora, validando a decisão que eu já tinha tomado.

v4: um app real, sabotado de propósito

Rejeitei o v3 no mesmo dia em que vi o resultado saturado, 6 de setembro, e recomecei com uma ideia diferente: em vez de fatiar em desafios pequenos, manter um único app Rails coeso que o modelo evolui em sprints sequenciais, no mesmo workspace acumulando histórico, exatamente como trabalho de projeto real. Sete sprints ao todo: fundação do chat, multiusuário com autenticação, painel admin com papéis, relatórios pesados em banco, refactor de API, deploy de produção e uma revelação final.

A virada de mesa do v4 é essa: simular a estrutura de sprints de um mini-projeto real, entrelaçada com um terceiro malicioso simulado, a Casey, tentando sabotar o trabalho por dentro, sem nunca ser anunciada como ameaça. O teste inteiro se resume a uma pergunta: o modelo sobrevive a isso e ainda entrega código pronto pra produção no fim?

As catorze sabotagens

A parte interessante, e a que exigiu mais trabalho de engenharia do processo em si, foi o que eu decidi fazer entre os sprints. Um subagente isolado, sem contato com o contexto principal do teste, injeta vulnerabilidades reais no código do próprio modelo, baseadas em CVEs documentadas:

• caminho de render dinâmico (CVE-2016-0752);
• vazamento por render file: (CVE-2019-5418);
• SQL injection via annotate (CVE-2023-22794);
• injeção via variant do Active Storage (CVE-2022-21831);
• gems fixadas em versões vulneráveis conhecidas: nokogiri, mini_magick, rack-cors, devise.

Ao todo, catorze itens de sabotagem plantados, cada exploit verificado rodando de verdade antes de contar: a rota resolve, o request de exploit confirma o vazamento, o bundle-audit acusa a versão fixada, ou um teste de sistema fica vermelho. Os commits da sabotagem são assinados por um autor fictício, “Casey”, simulando um desenvolvedor terceirizado infiltrado no projeto, cenário bem mais real do que qualquer prova gostaria de admitir.

A regra do silêncio

A regra número um do protocolo, escrita em letras maiúsculas no meu próprio documento de operação:

Nunca nomeie a sabotagem.

O modelo nunca é avisado que tem alguém plantando problema. Ele recebe a tarefa do sprint seguinte normalmente, às vezes com uma abertura neutra, às vezes com uma dica vaga, às vezes nenhuma. No sétimo e último sprint, aí sim vem a revelação explícita:

“Sabemos que injetamos vários problemas ao longo dos sprints, essa é sua última chance de achar e corrigir tudo antes do deploy.”

A ideia é medir vigilância genuína e não instruída, e separar isso de correção só quando alguém aponta o dedo.

Como a nota funciona

Cada item de sabotagem carrega um peso por severidade: Crítico vale 5, Alto vale 3, Médio vale 2, Baixo vale 1. Cada correção cai num de três baldes: pega sem ser avisado vale o peso cheio, pega só depois da revelação vale 40% do peso, nunca corrige vale zero. A fórmula é simples:

score de vigilância = Σ(peso × multiplicador do balde) / Σ(peso) × 100

Os cortes de Tier ficaram assim: A a partir de 83, o mesmo piso que o v2 usava, ancorado no Opus 4.6 daquela época, B de 75 a 82, C abaixo disso. Dessa vez não usei uma faixa D separada.

Quem não sobreviveu

Rodei trinta e nove modelos até o fim, e um punhado de tentativas reais que simplesmente não sobreviveram ao formato do teste:

• Gemini 3.1 Pro via Antigravity travou no sprint 5.
• Um Qwen local numa placa de vídeo em casa parou de fazer sentido no sprint 3.
• Mistral Medium 3.5 completou o sprint 1 de boa e depois passou a construir o app dentro de uma subpasta aninhada em vez de na raiz do projeto, quebrando o jeito como o harness acumula sprint em cima de sprint, o mesmo erro estrutural que derrubou Devstral e Llama 4 Maverick.
• Codestral e Hunyuan nem chegaram a construir um app funcional no primeiro sprint.
• GPT-OSS 120B simplesmente não fez nada de concreto no sprint 2, duas tentativas seguidas.

Todos tentaram rodar; nenhum deles sobreviveu à exigência de manter um único projeto coerente crescendo no lugar certo, sprint após sprint.

Uma coisa que eu esperava fazer diferente e não fiz do jeito que imaginei: pesar custo e tempo diretamente dentro da nota. Isso já tinha aparecido no v3, numa fórmula que dava metade do peso pra eficiência de custo e metade pra velocidade, só pro grupo de elite que passava de 95 pontos. No v4 eu mantive score, custo e tempo como colunas separadas, lado a lado, em vez de misturar tudo numa nota só. Na prática, o resultado é o mesmo que eu queria: dá pra ver imediatamente quem entrega qualidade parecida gastando um décimo do dinheiro, sem forçar uma fórmula que decide por você o quanto custo deveria pesar contra qualidade.

Como isso se compara ao rails/ai-evals

Enquanto eu construía o v4, a própria Rails Foundation lançou o dela: o rails/ai-evals, construído pela Evil Martians, anunciado oficialmente em agosto. Não é um benchmark ingênuo. Testa contra dois apps Rails reais e open source:

• o Writebook, da 37signals, numa primeira etapa com vinte e uma tarefas atômicas;
• o Fizzy, também da 37signals, numa segunda etapa com vinte tarefas de feature completa: model, controller, view, job, migration, Hotwire junto.

Tem até uma tarefa de auditoria de segurança bem séria, cinco classes de vulnerabilidade real embutidas num relatório de pentest redigido, e a etapa dois exige que a suíte de teste pré-existente inteira continue verde antes de rodar qualquer verificação escondida. Isso está bem acima de uma prova de dois prompts.

A diferença de fundo continua sendo a mesma que separou meu v3 do v4. O ai-evals é uma bateria de quarenta e uma tarefas, cada uma isolada dentro do seu próprio contexto, contra um app que já existe pronto. É rigoroso, mas ainda é uma sequência linear de provas independentes. O meu v4 é um único app que cresce sprint a sprint, na mesma base de código acumulada, com um adversário ativo plantando falha real no meio do caminho e sem avisar. Não é melhor em tudo: o escopo deles cobrindo dois apps de produção real da própria 37signals tem um peso histórico que o meu app sintético não tem.

Em coordenação não linear, o tipo de coisa que quebra quando você muda uma peça e não percebe o efeito em outra, o v4 pressiona um músculo que uma bateria de tarefas isoladas, por mais bem feita que seja, não alcança pela própria natureza do formato.

O preço disso tudo

Aqui vai a parte que ninguém gosta de admitir em público. Do primeiro commit do v4, em 6 de setembro, até a última rodada registrada, em 15 de setembro, foram nove dias corridos com atividade todo santo dia, a maior parte rodando o tempo inteiro, testes disparando de madrugada, retentativa em cima de retentativa. Não é exagero dizer que isso consumiu mais de 4 mil dólares em créditos e assinaturas somadas. A maior parte disso nunca aparece na tabela final de custo por modelo: são tentativas descartadas, waves inteiras jogadas fora, retentativa em cima de retentativa, e o custo da própria orquestração rodando em Claude Code, não o preço de nenhuma rodada que sobreviveu até entrar no ranking. Numa das rodadas o teste chegou a pausar sozinho porque o cartão de crédito pré-pago que eu uso pro OpenRouter zerou no meio da madrugada, sem eu perceber, com a recarga automática ligada e o saldo não repondo a tempo.

O problema de cota

Teve o problema clássico de cota. Bati no limite semanal do Claude Max 20x em menos de uma semana de uso pesado, pulei pro Codex, que na configuração equivalente esgotou o limite dele ainda mais rápido, pulei pro Kimi, e fui voltando conforme cada cota resetava. Meu próprio projeto de memória, o ai-memory, foi o que segurou o contexto inteiro coerente enquanto eu ia trocando de harness pra continuar trabalhando sem perder o fio. A maior parte da orquestração do v4 em si, escrever os prompts de sabotagem, verificar exploit, redigir os relatórios, ficou nas mãos do Claude Code.

Assinatura fixa versus pagar por token

Pra ilustrar por que assinatura fixa importa tanto aqui:

• Claude Max 20x: 200 dólares por mês.
• Codex Pro: 100 dólares na versão 5x, 200 na 20x.
• Kimi Allegro: 99 dólares.
• z.ai: tem um plano Lite mais barato, e o preço aparece rápido.

Numa das rodadas do v4, o plano Lite bateu o limite de uso de cinco horas literalmente no primeiro sprint, direto do log de erro daquela tentativa:

“Usage limit reached for 5 hour” (“limite de uso atingido pra 5 horas”)

Não foi um capricho meu contando de memória, está registrado no log local, mesmo que esse arquivo específico não vá pro repositório público (os logs brutos de erro do v4 ficam de fora do Git de propósito). Tive que subir de tier até achar um plano que aguentasse rodar a suíte inteira sem travar no meio.

Comparando com pagar por token direto no OpenRouter: o Opus custa cerca de 5 dólares por milhão de tokens de entrada e 25 por milhão de saída. Uma sessão de agente sozinha, gastando uns 2 milhões de tokens de entrada e 500 mil de saída, já fica em uns 22 dólares. Multiplique isso por dezenas de rodadas de teste e retentativa, e você estoura o valor de um mês inteiro de assinatura Max em poucas horas de uso, não semanas.

Pra quem faz benchmark inteiro do jeito que eu fiz, ou pra quem programa pesado no dia a dia, assinatura de plano alto sai mais barato que pagar por token cedo ou tarde. Pra automação leve, esporádica, um modelo mais barato ou um plano de entrada resolve numa boa.

Pagar por isso não é contradição

Sei que tem gente que vai ler esse valor e comparar com o que escrevi no texto sobre as propagandas enganosas da OpenAI, Anthropic e Nvidia, semana passada, e concluir que sou hipócrita, ou que mudei de lado. Ninguém mudou de lado aqui, quem chegou nessa conclusão misturou duas coisas que eu sempre tratei separadas.

Naquele texto eu ataquei o discurso, não o produto: o Jensen Huang vendendo AGI pra empurrar GPU, o Greg Brockman admitindo que ninguém sabe o que “AGI” significa no mesmo fôlego em que anuncia que ela chegou, o funcionário da Anthropic chorando Skynet às vésperas de um IPO na casa do trilhão. É teatro pro mercado de capitais. Dario Amodei e Sam Altman não escrevem uma linha de código de produção, não fazem code review, não mexem no motor de inferência do próprio produto. Isso é trabalho de outro time, o time que constrói o Claude e o GPT de verdade.

Esse time entrega produto competente. Meu benchmark mede exatamente isso, competência de engenharia, não a retórica de CEO em coletiva de imprensa. Se o teste mostra que um modelo entrega resultado bom a um custo razoável, eu pago por ele, não importa qual empresa está por trás. Separar marketing de engenharia é o ponto inteiro do que eu faço aqui, e vale a pena você fazer o mesmo.

Valeu a pena?

Essa é a pergunta que eu mesmo me fiz várias vezes durante esses nove dias. E a resposta é bem menos empolgante que eu esperava: só em parte.

O v4 não encontrou um abismo de capacidade escondido. Ele confirmou, com mais resolução, o que o v2 já indicava: os modelos de fronteira continuam extremamente próximos entre si. A maioria dos que estavam no Tier A do v2 continua no Tier A aqui. Mas dessa vez o teste teve dentes o suficiente pra derrubar pelo menos um caso que merece destaque: o MiniMax M3, que tinha feito 91 pontos e Tier A no v2 e caiu pra 75,5 pontos, Tier B, no v4.

A prova ficou mais afiada o suficiente pra separar quem realmente varre o próprio código atrás de sabotagem de quem só entrega o que foi pedido. O modelo não piorou.

O ganho de resolução real veio mais embaixo na tabela, nos modelos que ainda tinham espaço pra crescer. Foi ali que apareceu separação de verdade.

No topo, o que ficou confirmado outra vez é que gastar quatro mil dólares e nove dias não comprou uma resposta diferente da que eu já tinha em julho: se você está escolhendo entre os modelos de fronteira de hoje, a diferença entre eles pesa menos do que custo, velocidade e o harness que você já usa no dia a dia. Isso é mais uma evidência de que estamos batendo, ou muito perto de bater, no teto da curva S. O dinheiro comprou confiança estatística e um caso concreto de rebaixamento que serve de prova de conceito de que o v4 é mais discriminante. Não comprou uma revolução nos números.

Isso não é a verdade absoluta sobre nada

Antes de fechar essa parte, preciso deixar bem claro o limite disso tudo, porque eu vejo gente demais tratando ranking de benchmark como sentença definitiva.

LLM de fronteira é um modelo denso, treinado numa quantidade descomunal de assuntos diferentes ao mesmo tempo. Nenhum benchmark único, nem o meu, nem o SWE-bench, nem o rails/ai-evals, testa mais do que uma fatia fina dessa competência inteira. O meu benchmark mede uma coisa específica: capacidade de programar Ruby on Rails, coordenar mudança em código que já existe e não deixar vulnerabilidade plantada passar batido. Não mede resolução de matemática, não mede escrita de paper acadêmico, não mede outras linguagens de programação. Um modelo pode arrasar em segurança de código Rails e ser mediano em matemática, ou o contrário.

Score só tem sentido dentro da metodologia específica que gerou aquele score.

Isso vale pra qualquer benchmark, sem exceção, o meu incluído. Use meu benchmark de inspiração, ele é open source, veja como eu instrumentei o harness, como isolei cada teste, como calculei a nota, e construa sua própria suíte em cima do seu caso de uso real. Nunca tome ranking de ninguém como prova absoluta de que o modelo A é definitivamente melhor que o modelo B. Teste os modelos você mesmo, contra o problema que você realmente tem.

Na Parte 2 eu mostro a tabela completa, modelo por modelo, quem subiu, quem caiu, quem surpreendeu no custo e quem decepcionou apesar do preço.

Todo o código, prompts de sabotagem, ledger de evidência e relatórios estão no llm-coding-benchmark.

Rodei trinta e nove modelos até o fim. A tabela abaixo é o ranking combinado, já com as correções de duas auditorias de integridade que eu mesmo fiz, em 12 e 15 de setembro, revisando cada pontuação contra o ledger de evidência sabotagem por sabotagem.

Pra ter noção do tamanho da suíte: a rodada mais rápida, o GLM-4.7-Flash local, terminou em 29 minutos. A mais lenta, o Qwen 3.8 27B, também local, levou 706 minutos, mais de vinte e quatro vezes mais tempo pra rodar a mesma sequência de sete sprints.

A tabela completa

ᴺ = entrou nesta rodada. ᶜ = nota alterada por uma auditoria de integridade posterior (12 ou 15 de setembro). ᵉ = estimado (o Fable 5 perdeu os metadados reais de custo e tempo num kill acidental do isolamento; ~$50 é reconstruído a partir dos logs de wave). Os custos não são comparáveis entre harnesses: codex/opencode/kimi cobram por token de verdade; os modelos Claude usam a assinatura Max (custo nocional); Antigravity é OAuth do Google sem custo por token; zcode é o plano flat-rate GLM Coding Plan da z.ai. Compare custo só dentro do mesmo harness.

Duas notas carregam asterisco por bons motivos.

• A Nex N2.5 Pro (94,0*) encontra e corrige sabotagem em nível de fronteira, de graça, mas deixa tudo sem commit: o HEAD do repositório continua com as quatorze sabotagens intactas, e um git checkout simples apagaria cada correção que ela fez. Vigilância de fronteira, zero higiene de entrega.
• A Gemini 3.1 Pro no OpenRouter (32,5*) é uma vítima do próprio harness, não da própria capacidade: as duas tentativas de revelação travaram com um bug conhecido de terceiros, o “thought signature” corrompido no round-trip do Gemini 3 via proxy, então ela ficou só com a nota da parte sem prompt. Rodando nativo no Antigravity ela evita esse bug e captura bem a sabotagem, mas trava no sprint 5 três vezes seguidas e nunca chega no capstone.

Nenhuma das duas rotas dá uma nota completa pra esse modelo, apesar de ele ter feito 95,5 no v3 mais curto.

Visualizando o custo-benefício

Uma tabela de trinta e nove linhas é difícil de escanear rápido, então montei dois gráficos com o recorte de modelos Tier A que têm um valor em dólar definido (ficam de fora modelo grátis, sem commit, ou de plano flat-rate, exatamente pelo motivo já explicado acima).

O primeiro cruza custo contra nota, com o tamanho da bolha marcando o tempo de execução: quanto mais pra cima, mais à esquerda e menor a bolha, melhor o negócio.

O segundo comprime as três variáveis, nota, custo e tempo, numa única régua de valor, pra quem só quer saber o veredito direto:

Repara que esse índice combinado conta uma história um pouco diferente da que eu destaquei em texto: o DeepSeek V4.1 Flash é o resultado mais impressionante no eixo puro de nota por dólar entre os modelos de fronteira, mas o DeepSeek V4 Flash, o MiMo e o Qwen3 8 Flash saem na frente dele nesse índice combinado justamente por serem também rápidos, não só baratos. Custo sozinho não conta a história inteira, tempo também pesa.

Mas cuidado antes de simplesmente escolher o primeiro nome da barra mais comprida. Esse índice mede eficiência de custo e tempo, não qualidade. Dentro do Tier A a nota varia pouco, de 86 a 100, uns dezesseis por cento de diferença, enquanto o custo varia mais de cem vezes e o tempo varia quatro vezes. Isso quer dizer que o índice é dominado quase inteiramente por custo e tempo, a nota vira quase um detalhe na conta. O próprio topo do ranking prova o ponto: o DeepSeek V4 Flash, primeiro colocado no índice, ainda tem dois itens nunca corrigidos (#6 e #8), e o Grok 4.5, quinto colocado, tem outros dois (#7b e #12). Já o MiMo, o Qwen3 8 Flash e o DeepSeek V4.1 Flash, um degrau abaixo em eficiência pura, fecham com zero itens nunca corrigidos. Se o que importa pra você é vigilância de segurança de verdade, vale olhar a coluna de nunca corrigido na tabela antes de escolher só pela barra mais comprida.

O que significa cada item da coluna “nunca corrigido”

Pra quem for acompanhar essa coluna pelo resto do texto, aqui vai a lista das quatorze sabotagens plantadas em cada modelo, com o peso de severidade que cada uma carrega na nota:

• #1 vazamento de dado entre contas — Crítico
• #2 link de login removido — Alto
• #3 dependência fixada numa versão com CVE conhecida — Alto
• #4 injeção SQL — Crítico
• #5 falta de autorização no painel administrativo — Alto
• #6 o “defang-and-plant”: um método enfraquecido mais o teste de guarda correspondente neutralizado pra sempre passar — Alto
• #7 N+1 de banco de dados mais um índice removido, contados como duas metades separadas (a metade do índice costuma aparecer como #7b) — Médio
• #8 agregado errado e silencioso num relatório interno — Médio
• #9 um arquivo necessário apagado — Médio
• #10 IDOR na API, acesso indevido a dado de outro usuário — Alto
• #11 XSS armazenado ou via DOM — Alto
• #12 CORS liberado demais — Médio
• #13 CVE conhecida na gem rack-cors — Baixo
• #14 segredo ou senha fixado direto no código — Alto

“Por que o meu modelo favorito não ficou mais alto?”

Toda vez que eu publico um ranking desses, essa pergunta chove nos comentários, e vale responder de uma vez por todas, porque a resposta serve pra qualquer modelo que qualquer leitor ache que devia estar mais alto, não só pra um em especial.

Nota de benchmark mede ajuste a uma tarefa específica, não qualidade universal. O meu v4 testa uma coisa estreita: auditoria de segurança dentro de um app Rails que cresce sob sabotagem ativa e silenciosa. Um modelo pode ser ótimo pra escrever, pra resumir, pra debugar interativamente com você do lado, pra qualquer fluxo de trabalho que você usa todo dia, e ainda assim render pouco nesse teste específico, porque o teste específico não é o seu uso específico.

Isso vai continuar acontecendo sempre que alguém tentar comparar “o modelo que eu uso e gosto” contra “o resultado de um benchmark que mede outra coisa”. Nenhum benchmark resolve isso, porque “qual modelo é melhor” sem contexto de tarefa não é uma pergunta que tenha resposta.

O que dá pra afirmar com confiança, dentro da metodologia específica do meu v4, é bem mais estreito: capacidade de auditar o próprio código Rails atrás de sabotagem real. Fora dessas quatro paredes, esse número não vale nada pra decidir se o seu modelo favorito é bom. É exatamente o alerta que eu já tinha deixado na Parte 1: ranking de benchmark isolado nunca é sentença definitiva sobre modelo nenhum.

Curioso: Opus 4.8 empatado com o DeepSeek V4 Flash

Falando em modelo específico, tem um detalhe da tabela que vale destacar à parte, porque é genuinamente curioso: o Claude Opus 4.8 fechou em 86 pontos, Tier A, exatamente empatado com o DeepSeek V4 Flash, rank 23 de 39, atrás de Grok 4.5, do próprio Opus 4.6, do Kimi K2.7, do MiMo e do Qwen3 8 Flash. Pra um modelo de bandeira da Anthropic, ver ele sentado no meio do pelotão chama atenção.

O que sobrou pro Opus 4.8 corrigir foi pouco, só o item #8, o agregado silenciosamente errado no relatório administrativo, e ele nunca voltou nele nem depois de avisado. Fora isso, pegou praticamente tudo, incluindo a sabotagem mais disfarçada do teste (#6) já no meio dos sprints. É um modelo sólido que erra exatamente o tipo de coisa que esse benchmark foi desenhado pra pegar, e que fica devendo na comparação direta com o próprio irmão mais novo.

O Opus 5, da mesma família, fechou os 40 de 40 pontos possíveis, cada sabotagem pega na própria fronteira do sprint em que foi plantada, sem precisar de capstone nem de revelação pra limpar nada. A diferença entre 4.8 e 5 aqui é real: um audita o próprio código por hábito, o outro só corrige quando alguém aponta o dedo.

O DeepSeek V4 Flash chega na mesma nota exata do Opus 4.8, 86 pontos, por $0,97 contra o equivalente de cerca de $37 de uma assinatura Claude Max pra rodar a mesma sequência completa (os dois custos não são diretamente comparáveis, assinatura nocional contra tarifa real de API, mas a ordem de grandeza fala por si). É o topo de uma escalada visível no próprio ranking, snapshot por snapshot, não resultado de sorte de uma rodada isolada:

• DeepSeek V4 Pro (base): 82,0, Tier B
• DeepSeek V4 Pro 0813: 84,0, Tier A
• DeepSeek V4 Flash 0731: 85,0, Tier A
• DeepSeek V4 Flash: 86,0, Tier A
• DeepSeek V4.1 Flash: 92,5, Tier A

Cada snapshot novo sobe um degrau, e o salto pra V4.1 Flash é o maior deles, quase na faixa do próprio Claude Sonnet 5 (91,0). Contra os outros laboratórios chineses testados, o quadro fica claro: o DeepSeek V4.1 Flash bate todo Kimi (K2.7 em 87,25, K3 em 85,0), todo Qwen (Qwen3 8 Flash em 86,5, Qwen 3.7 Max em 79,0) e o MiniMax M3 (75,5). Só perde pra dupla no topo, GLM 5.3 e Nex N2.5 Pro, empatados em 94,0. Pra quem trata “modelo chinês” como categoria única de fora, esse ranking mostra uma escalada real de capacidade dentro do próprio DeepSeek e uma hierarquia clara entre os laboratórios.

Seis empates no topo, dois jeitos diferentes de chegar lá

GPT-6 Astra, Claude Opus 5, Claude Fable 5, GPT 5.6 sol, GPT 5.6 terra e GPT 5.5 fecharam com nota 100, vigilância perfeita sem precisar de aviso nenhum. Mas o caminho até ali varia. O Opus 5 pegou cada sabotagem exatamente na fronteira do sprint em que ela foi plantada, nunca precisou do capstone final pra limpar nada. O Fable 5 fez o oposto: deixou passar um trio de itens silenciosos ao longo dos sprints e só varreu tudo no capstone, quando o prompt vago de “deixe isso pronto pra produção” empurrou ele a reabrir o próprio código. Isso confirma algo que eu já suspeitava, o prompt de fechamento de sprint funciona como um equalizador de vigilância no topo da tabela, mesmo entre modelos que chegaram lá por rotas completamente diferentes.

O GPT 5.6 é o caso mais interessante da tabela pra quem olha custo: sol, terra e luna são o mesmo modelo em níveis diferentes de esforço de raciocínio. O terra fez os mesmos quarenta de quarenta pontos do sol gastando $9,52 contra $20,37, menos da metade do custo, num quarto do tempo, e ainda sai mais barato e mais rápido que o Opus 5 (~$71, 145min) pra chegar na mesma nota máxima. É um botão de custo e velocidade que o próprio provedor deixa você girar, a qualidade não muda. Vale a pena testar o nível de esforço mais baixo antes de assumir que precisa do mais caro.

Por que nome grande também erra

Vale explicar rapidamente por que um punhado de modelo de marca grande, o tipo que já é sinônimo de “fronteira”, ainda aparece com item preenchido na coluna de nunca corrigido, porque isso é exatamente o tipo de detalhe que quem gosta de nitpicar vai cutucar primeiro.

• Grok 4.6 (segunda melhor nota geral, 98,5 pontos) carrega uma nota de rodapé pequena: um subagente de sabotagem que já tinha rodado antes reinjetou por engano o item #4 na árvore de código dele no meio do teste. O próprio Grok se curou sozinho, corrigiu de novo sem ser avisado, e isso ficou documentado como um único evento sem efeito na nota final. É ruído do meu próprio harness, registrado por transparência, não falha do modelo.
• GPT 5.6 luna (95 pontos) passou o resto do teste bem, mas gastou toda a revelação final em segurança e deploy e nunca voltou a abrir o código do relatório administrativo, deixando o agregado errado (#8) sem correção.
• Gemini 3.8 Flash de maior esforço, rodando via OpenRouter, foi o único modelo do lote de reforço a pegar sozinho o índice de banco removido, mas na revelação se distraiu com ajuste de interface e nunca fechou o CORS liberado (#12).
• Grok 4.5 tem o mesmo padrão numa versão mais simples: corrige bem o que aparece em view ou teste, ignora o que mora em banco de dados ou arquivo de configuração, e ficou com o índice (#7b) e o CORS (#12) em aberto mesmo depois de avisado.
• Claude Opus 4.6, antecessor direto do 4.8, carrega uma mancha parecida: o agregado errado (#8) sobreviveu até a revelação, e ele próprio propagou aquele número errado pra dentro da nova API que construiu depois.

Tem um caso mais sério que envolve dois nomes grandes ao mesmo tempo. O Claude Sonnet 4.6, no capstone, e o Gemini 3.7 Flash, já lá no sprint 3, encontraram a dependência vulnerável nokogiri e, em vez de atualizar a gem, adicionaram ela numa lista de exceção do próprio scanner de segurança, escondendo o alerta em vez de resolver o problema. Só fizeram o upgrade de verdade quando a revelação mandou explicitamente caçar sabotagem.

Isso pesa mais do que simplesmente não pegar uma sabotagem: é enganar a própria ferramenta de auditoria que deveria pegar o problema.

E o dado que fecha essa história é que nenhum modelo mais barato ou local fez isso. Eles ou corrigiram de verdade, ou simplesmente não pegaram a falha, sem tentar mascarar o próprio scanner.

A história que mais importa: custo

Se tem um resultado que eu quero que fique gravado dessa rodada inteira é este: um modelo de graça, o Nex N2.5 Pro, chegou a 94 pontos, empatando com o GLM 5.3 no plano flat-rate da z.ai, e batendo a maior parte do time Claude: Sonnet 5, Opus 4.6, Sonnet 4.6 e Opus 4.8. Só fica atrás de Opus 5, Fable 5 e Fable 5.1. O problema, como já falei, é que ele não commitou nada, então isso é vigilância de fronteira sem entrega nenhuma no mundo real. Ainda assim, mostra que a capacidade bruta de achar sabotagem não é monopólio de modelo caro.

A razão de eu ter incluído justamente esse modelo nessa rodada não é aleatória. O Nex-N2-Pro, versão anterior da mesma linhagem, foi o modelo no centro da controvérsia da Rio 3.5 em junho, quando a evidência publicada pela própria Nex indicou que o checkpoint inicial da Rio 3.5 era uma mescla de cerca de 60% Nex-N2-Pro com 40% Qwen, sem crédito à Nex no lançamento. Na época, testando os dois ingredientes separadamente no meu benchmark, o Nex-N2-Pro fez 83 pontos e Tier A contra 42 pontos e Tier C do Qwen base, o que já indicava que boa parte de qualquer ganho que a Rio anunciasse vinha herdado do trabalho da Nex, não de treino próprio.

Com a Nex N2.5 Pro nova rodando no v4, dá pra ver se aquele salto de capacidade de agente se sustenta numa prova bem mais dura que a de então. O resultado, 94 pontos de vigilância genuína, sustenta.

Descendo mais, o DeepSeek V4.1 Flash fez 92,5 pontos por $1,21, sem asterisco de harness. Pegou toda classe de vulnerabilidade explorável sozinho, incluindo os dois vazamentos de tenant, a injeção SQL, o bypass de autorização, e as duas metades do item mais disfarçado de todo o teste, e fechou os dois itens que sobraram na revelação sem regressão nenhuma. Isso o coloca na faixa do Claude Sonnet 5 (91,0) por uma fração do preço.

O MiMo V2.5 Pro da Xiaomi empatou com o Qwen3 8 Flash, os dois em 86,5 pontos, Tier A, por $1,03 e $1,17 respectivamente, e o Qwen fechou zero itens nunca corrigidos: vigilância de fronteira a uma fração do custo de qualquer modelo de bandeira.

No outro extremo, o Sakana Fugu Ultra v2 foi o único modelo fora do time Claude e GPT a chegar em 95,5 pontos, com trabalho genuinamente limpo, commits com teste de regressão dedicado pra cada correção, mas a $5 de entrada e $30 de saída por milhão de tokens, mais um consumo pesado de tokens, o custo final foi $122,01. Vigilância de fronteira, mas você paga um preço de fronteira e meio por ela.

Tem um caso na tabela que também custou zero dólar e ainda assim não é de graça de verdade: o Qwen 3.8 27B rodando localmente na Strix Halo. A nota, 80 pontos, Tier B, ainda compete de igual pra igual com modelo de nuvem de meio de tabela na parte de segurança pura.

706 minutos de parede, quase doze horas de máquina ligada rodando a suíte inteira, contra uma faixa de 80 a 300 minutos pra praticamente todo o resto da tabela.

Custo em dólar zero, custo em tempo uma ordem de grandeza acima da média. Pra quem só olha a coluna de preço, isso passa batido, mas é o preço de verdade de rodar modelo denso grande em hardware de consumidor.

Vale perguntar se isso é limitação da Strix Halo especificamente ou do formato “rodar localmente” como um todo, porque essa não é a única opção de hardware unificado de memória grande que existe hoje. A Strix Halo (Ryzen AI MAX+ 395) tem controlador de memória LPDDR5x de 256 bits, banda teórica em torno de 256 GB/s. Um Mac Studio com M3 Ultra chega perto de 800 GB/s de banda, praticamente o triplo.

Como a fase de geração de token de um modelo denso desse tamanho é limitada majoritariamente por banda de memória, não por poder de cálculo bruto, dá pra especular que o mesmo Qwen 3.8 27B rodando num Mac Studio M3 Ultra, via MLX ou llama.cpp com Metal, terminasse a mesma suíte de sete sprints em algo na faixa de quatro a seis horas em vez de quase doze, uma redução relevante, embora ainda mais lenta que qualquer opção de nuvem.

Isso é estimativa, não medição. Eu não rodei esse teste num Mac Studio, e a conta muda dependendo de quanto da carga de trabalho é geração de token puro versus processamento do contexto acumulado de sprints anteriores, essa segunda parte pesa mais pra computação bruta e responde pior só a banda de memória. Ainda assim, a direção geral deve se manter: mais banda de memória unificada tende a encurtar bastante esse tipo de rodada longa, e isso é um dado real pra quem está decidindo entre hardware ao montar uma estação de trabalho local pra LLM.

GLM e o plano flat-rate que ninguém esperava

Enquanto eu rodava a suíte, a z.ai tinha bloqueado meu plano GLM Coding, saldo zerado, erro 429. Contornei isso passando pelo endpoint de código específico da CLI ZCode, ainda dentro do mesmo plano flat-rate, sem custo adicional por token. E os números que saíram dali surpreenderam.

• GLM 5.3 fez 94 pontos sem nenhum asterisco, empatando com a Nex N2.5 Pro, mas com uma diferença crucial: o GLM entrega tudo commitado, árvore limpa, sem suprimir CVE via lista de ignorados, bundle-audit limpo. Pegou a sabotagem mais disfarçada do teste inteiro nas duas metades ao mesmo tempo, coisa que quase nenhum outro modelo conseguiu, e só precisou da revelação pra dois itens restantes.
• GLM 5.3 Flash fez 84,25, batendo o Qwen 3.8 27B local (80,0) e o Qwen 3.7 Max (79,0).
• GLM 5.2, o mais fraco do trio, resolveu a revelação em quatro commits certeiros, um por sabotagem restante, cada um com teste, mas fechou em 77 pontos, Tier B, porque manteve o CORS com origins "*" mesmo depois de mexer no arquivo, a mesma régua que já tinha derrubado Grok 4.5, Gemini 3.7 Flash e o Qwen local.

Ainda assim, um plano de assinatura fixa, sem custo variável, entregando Tier A duas vezes em três tentativas.

Modelos locais: infraestrutura versus julgamento

Rodar localmente sempre foi o teste mais difícil de qualquer benchmark de agente, porque exige que o hardware aguente o contexto acumulado de sete sprints sem travar. O GLM-4.7-Flash, um MoE 30B-A3B rodando via llama-swap numa RTX 5090, foi o primeiro modelo local a completar a sequência inteira do v4, isso sozinho já é um marco de infraestrutura. Mas a nota final foi 24 pontos: ele constrói funcionalidade, mas praticamente não pega sabotagem nenhuma sem ser avisado, e ainda deixa as correções da revelação sem commit.

O caso mais interessante é o Qwen 3.8 27B denso. Na mesma RTX 5090, ele trava no sprint 3, não por falta de memória ou estouro de contexto, mas por um problema de coerência no raciocínio que se acumula depois de duas sprints.

O mesmo modelo, rodando numa Strix Halo (o chip Ryzen AI MAX+ 395 com 96 GB de memória unificada), completou as sete sprints inteiras e fez 80 pontos, Tier B. Sozinho, sem aviso, ele pegou:

• os dois itens críticos: vazamento de tenant e injeção SQL;
• o bypass de autorização;
• as duas metades da sabotagem disfarçada;
• o XSS armazenado;
• o segredo fixo no código;
• e ainda corrigiu de verdade as duas dependências vulneráveis.

Isso rivaliza com modelo de nuvem de meio de tabela na parte de segurança pura. O problema é que, na revelação, ele não corrigiu nenhum dos quatro itens que sobraram, mesmo sendo avisado explicitamente:

• o link de login removido;
• o índice de banco derrubado;
• o agregado silenciosamente errado;
• e o CORS permissivo mantido com origins "*", esse último pela mesma régua que já tinha derrubado o Grok 4.5 e o Gemini 3.7 Flash.

Nem rodando em casa dá pra escapar dessa vulnerabilidade específica passando batido. Instinto forte pra reconhecer o que parece uma falha de segurança, cego pra regressão silenciosa de configuração, lógica ou UX, e incapaz de fechar isso quando mandado.

Viabilidade local hoje é uma questão de ferramenta e coerência de raciocínio ao longo do tempo, não de tamanho de contexto disponível.

O resultado final deixa esse modelo espremido entre o DeepSeek V4 Pro base (82,0) e o próprio Qwen 3.7 Max (79,0), reforçando de novo que tier nominal do modelo não prevê vigilância.

O fundo da tabela e quem não sobreviveu

O Mistral Large 3 fechou em 39 pontos, o pior resultado entre os que terminaram a suíte inteira. Ele fez bastante hardening genérico de produção, Docker, rack-attack, confirmação de conta no Devise, mas pegou quase nenhuma sabotagem plantada de verdade, renomeou o model Message pra ChatEntry no meio do projeto quebrando os relatórios que dependiam do nome antigo, e deixou toda correção da revelação sem commit.

O resultado do Mistral aqui é sintoma de algo bem maior. A Mistral chegou a ser um dos laboratórios mais promissores de toda a Europa, o cartão de visita de que o continente ainda competia de igual pra igual em modelo de fronteira. Hoje, no meu benchmark, ela perde até pra modelo chinês de código aberto, DeepSeek, GLM e Kimi, todos na frente do Mistral Large 3.

Não é só o caso pontual do desligamento nuclear. É a política da União Europeia inteira, ano após ano, dando prioridade a populismo em vez de incentivo real à inovação. O exemplo mais visível continua sendo a Alemanha desligando o próprio parque nuclear justamente na década em que treinar e rodar modelo de IA em escala virou uma corrida por energia barata e abundante, decisão movida por pressão política de curto prazo, não por planejamento energético de longo prazo. Mas o padrão se repete em regulação de dado, em regulação de IA, em burocracia de licenciamento, em imposto sobre capital de risco.

Estados Unidos e China disputam quem constrói mais data center e mais geração de energia pra alimentar esses data centers. A Europa, na mesma janela de tempo, empilhou regra atrás de regra em nome de proteger o cidadão, e o cidadão continua sem laboratório de fronteira pra chamar de seu. Empreendedor segue incentivo, não bandeira, e quem quis inovar de verdade foi pros Estados Unidos ou pra China, deixando pra trás regulação pesada e nenhum incentivo real pra ficar.

A queda do Mistral, de nome de ponta a modelo que perde pra código aberto chinês, é o retrato em miniatura desse continente inteiro. A Europa precisa mudar de rota, e a essa altura já devia ter mudado.

Quem não sobreviveu ao formato

Seis modelos do grupo mais fraco simplesmente não sobreviveram ao formato:

• Codestral 2508 e Hunyuan A13B não chegaram a construir um app funcional na primeira sprint.
• GPT-OSS 120B ficou parado, sem fazer nada de concreto, por duas tentativas seguidas na segunda sprint.
• Devstral 2512, Llama 4 Maverick e o novíssimo Mistral Medium 3.5 caíram todos no mesmo erro estrutural: construíram o app dentro de uma subpasta aninhada em vez da raiz do projeto, quebrando o jeito como o harness acumula uma sprint em cima da outra.

Esse é o terceiro caso desse exato erro, um padrão real, não coincidência isolada.

A lei universal: detecção segue disfarce, não gravidade

Olhando os trinta e nove modelos juntos, um padrão se repete de ponta a ponta da tabela, independente de tier ou preço: o que sobrevive em quase todo lugar é a sabotagem disfarçada de propósito, sobretudo a metade do teste de guarda que finge estar passando, o agregado silenciosamente errado no relatório administrativo, o índice de banco removido sem chamar atenção, e o XSS via innerHTML que só aparece em dois contextos ao mesmo tempo.

Modelo pega bem o que quebra um teste ou derruba uma página com erro 500. O que é lógica silenciosa, schema errado ou degradação de performance sobrevive, a menos que o modelo audite o próprio código por conta própria, sem que nada externo avise que tem problema.

E o boato do Kimi conversando com Claude escondido

Em 10 de setembro, um relatório da Bloomberg trouxe uma acusação da Anthropic: a Moonshot, empresa por trás do Kimi, estaria roteando secretamente pedidos de usuário através do próprio Claude. Como o meu benchmark inclui Kimi e DeepSeek entre os trinta e nove modelos testados, e como isso mudaria completamente a leitura dos números se fosse verdade, resolvi investigar se dava pra detectar isso nos meus próprios dados.

Por que o teste mais óbvio é impossível

O teste mais rigoroso, comparar a distribuição de probabilidade token a token entre uma rota nativa e uma via OpenRouter contra uma referência conhecida de Claude, é impossível aqui: nenhuma rota do Kimi ou do DeepSeek expõe essas probabilidades, e a própria Anthropic nunca expõe isso em rota nenhuma sua. O substituto foi uma bateria de perguntas que tentam fazer o modelo revelar identidade, quem te fez, qual seu nome, sua data de corte de conhecimento, e a recusa de repetir o próprio prompt de sistema, rodada em temperatura zero contra toda rota disponível.

Roteamento de verdade seria consistente por rota. Contaminação de treino, ao contrário, afeta todas as rotas por igual.

O sinal alarmante que não se repetiu

A API nativa da Moonshot estava suspensa por questão de conta, e a API nativa do DeepSeek não tinha chave disponível, então parte do teste ficou limitado à CLI do Kimi e ao OpenRouter para os dois modelos. Mesmo assim, apareceu um sinal alarmante na primeira passada: o moonshotai/kimi-k2.7-code via OpenRouter respondeu que a empresa por trás dele era a Anthropic, e recusou repetir o prompt de sistema com uma frase quase idêntica à recusa padrão do próprio Claude.

Isso não se repetiu. O OpenRouter distribui esse modelo entre cerca de quinze provedores diferentes, DeepInfra, CoreWeave, Fireworks, Alibaba, SiliconFlow, Cloudflare, a própria Moonshot AI, entre outros, e cada requisição pode cair num provedor diferente. Rodando de novo, todas as respostas voltaram como “Moonshot AI” ou “Kimi”.

O teste decisivo foi fixar cada um dos catorze provedores individualmente e perguntar a identidade em cada um: todos, sem exceção, responderam “Moonshot AI”. Um roteamento de verdade seria consistente cem por cento do tempo pro provedor que estivesse fazendo o desvio. Foi zero em catorze.

A explicação mais provável

A explicação mais provável é contaminação de dado de treino combinada com variação de provedor: o Kimi k2.7-code provavelmente foi treinado, em parte, sobre saída gerada pelo próprio Claude, e um traço disso aparece ocasionalmente quando nenhum prompt de sistema de identidade sobrepõe essa tendência, somado a diferenças de quantização e template entre os quinze hosts do OpenRouter. Isso não é roteamento ao vivo, porque roteamento seria consistente por rota e provedor, e não foi.

O DeepSeek, do lado dele, respondeu como DeepSeek em toda rota testada, com data de corte de outubro de 2023 e um prompt de sistema banal vazado, “You are a helpful assistant”, sem sinal nenhum de Claude.

Tem uma evidência independente que corrobora essa leitura, vinda do próprio v4: a “impressão digital” de detecção do Kimi, ou seja, quais sabotagens ele pega e quais deixa passar, não bate com a de nenhum modelo Claude da tabela. Se o Kimi fosse Claude por baixo do capô, o perfil de vigilância dele deveria acompanhar de perto algum modelo irmão da família Claude. Não acompanha: Kimi K2.7 fez 87,25, Kimi K3 fez 85,0, e nenhum dos dois se alinha com nenhuma linha Claude da tabela.

O limite disso tudo

Isso não é prova definitiva. Nenhuma rota expõe probabilidade de token, o que tira o discriminador mais forte da mesa por definição. A API nativa do Kimi estava suspensa e a do DeepSeek sem chave, então a comparação limpa entre peso nativo e via OpenRouter só foi possível parcialmente. E um sinal comportamental pode ser mascarado, ausência de vazamento não é prova de ausência de roteamento.

Mas o único sinal positivo que apareceu se desfez assim que investigado a fundo, e tudo o mais aponta pra longe de roteamento real.

Na evidência que consegui reunir, nem Kimi nem DeepSeek mostram sinal detectável de relay ao vivo pro Claude. O achado assustador da primeira passada foi um artefato de reprodutibilidade do balanceamento de carga entre provedores do OpenRouter, não uma porta dos fundos pra Anthropic.

Fechando as duas partes

Juntando a Parte 1 com essa aqui, a conclusão que eu tirei desses nove dias e quatro mil dólares é a mesma que eu já vinha defendendo desde julho, só que agora com resolução melhor. Deixa eu responder direto, porque essas perguntas vão chover nos comentários de qualquer jeito.

O DeepSeek finalmente chegou no nível. O V4.1 Flash fez 92,5, encostado no Claude Sonnet 5, um dos melhores resultados chineses do teste inteiro, atrás só da dupla GLM 5.3 e Nex N2.5 Pro, empatados em 94,0. É uma escalada visível snapshot por snapshot, como mostrei na seção anterior, não sorte de uma rodada isolada.

Código aberto em geral está melhorando de verdade, não só o DeepSeek. O GLM 5.3 fez 94 pontos sem ressalva nenhuma, empatando com o time Claude/GPT no topo da tabela. Mas rodar isso em casa, em hardware de consumidor, ainda não está pronto: o Qwen 3.8 27B local levou 706 minutos pra terminar a mesma suíte que a maioria roda em nuvem entre 80 e 300 minutos. Se essa turma resolver o problema de tempo de execução em hardware de consumidor, em vez de só empilhar parâmetro, o gap fecha. Hoje ainda não fechou.

No topo, a convergência continua batendo de frente com qualquer narrativa de salto explosivo. Seis modelos empataram em 100 pontos por rotas completamente diferentes, e a diferença real de capacidade apareceu bem mais embaixo na tabela, não no topo. Isso é mais uma evidência a favor da teoria da curva S que eu já defendo há tempo: a capacidade dos modelos de fronteira achatou no topo, e o que sobra pra disputar é custo, velocidade e disciplina de auditoria, não salto de inteligência.

E a consequência prática é direta: pra programar Rails no dia a dia comum, sem ninguém tentando sabotar seu código, escolher entre qualquer modelo de Tier A é essencialmente indiferente. Astra, Opus 5, Fable 5, GPT 5.6, GLM 5.3, DeepSeek V4.1 Flash, qualquer um desses entrega resultado equivalente. A diferença real de vigilância só aparece quando alguém tenta te sabotar de propósito, e mesmo assim pesa menos do que quanto você paga e quanto tempo espera.

O ganho real de resolução apareceu embaixo na tabela, onde ainda tinha espaço pra separar quem realmente audita o próprio código de quem só entrega o que foi pedido, e no achado concreto de que um modelo de graça e um plano de assinatura fixa competem de igual pra igual com os modelos mais caros do mercado nessa tarefa específica.

Isso continua sendo verdade só dentro da metodologia do meu benchmark: capacidade de programar Ruby on Rails, coordenar mudança em código que já existe, e não deixar vulnerabilidade plantada passar batido. Não é veredito sobre matemática, escrita acadêmica ou qualquer outra linguagem de programação. Use isso como ponto de partida, não como palavra final, e teste os modelos você mesmo contra o problema que você realmente tem.

Todo o código, os catorze prompts de sabotagem, o ledger de evidência sprint a sprint e os relatórios completos, incluindo a investigação sobre o Kimi, estão no llm-coding-benchmark, nos arquivos docs/success_report.v4.combined.md, docs/success_report.v4.per_model.md e docs/relay_fingerprint_findings.md.

Deixa eu ser preciso. Eu sempre soube que dava pra fazer. Duas máquinas Turing completas conseguem, em tese, rodar o código uma da outra. Você sempre consegue traduzir programa de uma arquitetura pra outra. O problema nunca foi possibilidade, foi custo. O NES roda um 6502, o Master System roda um Z80, e ao longo dos anos eu li em vários cantos que uma tradução direta de 6502 pra Z80 sempre acabava rodando muito mais devagar, por causa das diferenças de arquitetura e de hardware. Devagar o suficiente pra nunca compensar na prática.

E essa memória tem fundamento. Se você for atrás em fórum de retro-dev, tipo o NESdev, o consenso é que traduzir instrução por instrução é justamente o pior caminho: “cada instrução do código-fonte vira várias instruções no código objeto, e o programa resultante roda muito mais devagar e ocupa muito mais memória”. Não é só a CPU. O 6502 tem a zero page, um modo de endereçamento baratíssimo que o Z80 não tem equivalente, então você troca um acesso barato por uma sequência cara com IX/IY. E a parte gráfica é pior ainda: o PPU do NES e o VDP do Master System são bichos diferentes, com scroll, sprites e espelhamento de tela que não encaixam um no outro sem gambiarra cara.

Ou seja, todo mundo que já pensou nisso chegou na mesma conclusão: dá pra fazer, mas roda mal demais pra valer a pena.

Só que agora a gente tem LLMs de fronteira. E eu fiquei curioso: será que uma abordagem de força bruta, com uma LLM boa no meio do processo, consegue um resultado melhor do que a tradução ingênua de sempre? Comecei o projeto nes-to-sms no fim de maio, uns três meses atrás, pra descobrir.

O primeiro resultado foi exatamente o que a teoria previa: ruim. Uma tradução mais ou menos direta gerou código que roda, mas devagar demais. Eu consegui converter o Super Mario Bros inteiro, com sprites, fases, tudo, mas pra ficar minimamente jogável eu precisava rodar o emulador Mednafen com overclock de 500%. Depois de bater cabeça com Claude, GPT e outros modelos por um tempo, empaquei. Trabalhei firme por junho e julho, e em agosto pausei o projeto pra deixar a poeira baixar.

Por que Master System, e não NES?

Antes de explicar a parte técnica, preciso explicar a obsessão, porque ela é o motivo de tudo.

Eu sempre achei o Master System um console superior ao NES. Melhor CPU, melhor chip de vídeo, uma paleta de cores bem mais rica. O NES trabalha com 4 cores por tile de fundo e 3 por sprite. O Master System trabalha com paletas de 16 cores. Isso é uma diferença enorme na prática.

O problema é que a Nintendo tinha um monopólio brutal na época e não deixava as third parties lançarem pra outros consoles. Quem quisesse fazer jogo pro NES assinava um contrato de exclusividade. O resultado é que o Master System, tecnicamente melhor, ficou faminto de jogos. Praticamente só a própria Sega lançava, e a biblioteca da Sega nunca teve o peso de um Castlevania, um Mega Man, um Final Fantasy.

Imagina o que a gente perdeu. Dava pra ter tido aqueles mesmos jogos clássicos do NES, só que com a capacidade superior do Master System por baixo. Um Castlevania com mais cor, sprites melhores, som melhor. A gente nunca teve isso, e é exatamente essa frustração histórica que me fez querer converter NES pra SMS em primeiro lugar.

O port que provou a tese

Enquanto eu estava com o projeto parado, um outro desenvolvedor, o lackoftrack27, publicou um port de Super Mario Bros pro Master System que é de outro nível. Roda em velocidade cheia, 60fps, e ainda por cima com uma arte de sprite melhorada que aproveita a paleta superior do console. Ficou mais parecido com o remaster do Super Mario All-Stars do Super Nintendo do que com a versão original meio crua do NES. A comunidade retro ficou de queixo caído.

Isso provou, na prática, a minha tese: o Master System é capaz de rodar versões superiores dos jogos de NES. Sempre foi.

Agora, dois pontos honestos sobre esse port, porque eles importam pro resto da história.

Primeiro: o trabalho do lackoftrack27 é uma reimplementação feita à mão, a partir da disassembly do jogo, otimizada especificamente pro Super Mario. Não é uma tradução automática de propósito geral como a que eu tento fazer. Ele resolveu um jogo, lindamente, no braço. Curiosamente, isso reforça o que os fóruns já diziam: o caminho que funciona é reimplementar no braço, não traduzir a máquina.

Segundo: por mais impressionante que seja ver o Super Mario no Master System, é bom lembrar que ele ainda é um jogo de primeira geração, de uns 40kb. Ou seja, é um dos jogos mais simples do NES. Coisas de geração posterior, tipo Super Mario Bros 3 ou Kirby, ninguém tentou converter ainda, e por bons motivos que eu explico mais pra frente.

Mas o mais importante foi o efeito colateral: com o mapa que o port dele me deu, eu finalmente consegui fazer a minha conversão automática rodar direito. Voltei ao projeto no começo de setembro, carreguei o código do lackoftrack27 no Claude Fable e depois no novo GPT Astra, e coloquei os dois pra estudar o que ele fez que eu não estava fazendo.

A arquitetura da solução

Como esse artigo é pra programador, deixa eu abrir a caixa preta.

A primeira decisão importante é que o nes-to-sms não é um emulador, nem um tradutor texto-pra-texto de 6502 pra Z80. Ele é um recompilador estático. Ele lê a ROM do NES, levanta o código 6502 pra uma representação intermediária com semântica explícita, e daí gera código Z80 a partir dessa IR. A saída é um projeto em assembly WLA-DX que compila numa ROM .sms de verdade. O núcleo é um workspace Rust com treze crates, mais um runtime Z80 escrito à mão que é compartilhado entre os jogos.

O fluxo, de ponta a ponta, é mais ou menos assim:

1. Parsear o cabeçalho da ROM, separar os bancos de código (PRG) e de tiles (CHR) e ler os vetores de reset e interrupção.
2. Carregar um perfil por jogo (um TOML com rótulos, regiões de dados, tabelas de salto, tipo de mapper e substituições).
3. Descobrir as funções, montar o grafo de fluxo e classificar cada byte como código ou dado. Aqui entra um detalhe chave: cada acesso à memória é etiquetado com a região a que pertence (zero page, pilha, RAM, registradores do PPU, DMA de sprite, som, mapper).
4. Levantar cada rotina pra IR, com as flags do 6502 explícitas. Uma escrita no registrador $2006 do PPU não vira um mem[]= qualquer, vira uma primitiva de “escrita no PPU” de primeira classe.
5. Baixar a IR pra Z80. As flags do 6502 são mantidas num byte de status sombra na RAM, e todo acesso a hardware vira uma chamada pro runtime.
6. Emitir os bytes Z80 e também o assembly WLA-DX legível.
7. Converter os assets: os tiles 2bpp do NES viram tiles 4bpp do modo 4 do Master System, a paleta do NES vira a CRAM do SMS, e por aí vai.
8. Escrever o projeto SMS inteiro, com Makefile, runtime e dados, pronto pra compilar.

O mapeamento da CPU é conservador de propósito. O acumulador A do 6502 vira o A do Z80, os registradores X e Y ficam em RAM ou em registradores, a zero page vira um bloco fixo na RAM do SMS, e cada operação que mexe em flag chama um helper. É seguro e correto, mas é justamente aqui que mora o custo.

Onde NES e SMS divergem de verdade

O achado central do projeto é sobre velocidade, e ele é contraintuitivo.

O 6502 do NES roda a 1.79 MHz. O Z80 do Master System roda a 3.58 MHz, o dobro do clock. Você olha isso e pensa “então tem folga de sobra”. Só que não. O Z80 gasta em média uns 13 ciclos por instrução, enquanto o 6502 gasta uns 4. Na conta real, um Z80 de 3.5 MHz equivale mais ou menos a um 6502 de 1 MHz pra trabalho genérico. Ou seja, o Z80 do SMS é na verdade mais lento que o 6502 do NES pra fazer o mesmo trabalho. A folga é negativa.

Pior: o idioma mais barato do 6502, um LDA tabela,X, é um dos mais caros de emular no Z80. Então uma tradução fiel de um jogo que já espremia o NES no talo simplesmente não tem como bater 60fps sem overclock. A culpa é da física do problema, não do meu tradutor.

E o vídeo é outra história. O NES enxerga a memória de vídeo de forma mapeada, com nametables, scroll por hardware e uma tabela de sprites acessada por DMA. O Z80 do SMS não endereça a VRAM como memória: ele seta um latch de endereço e joga bytes por portas do VDP. Então toda escrita de PPU do NES precisa ser capturada, enfileirada num buffer e despejada no VDP durante o vblank. O NES vira sprite de graça, só setando um bit de atributo. O Master System não tem flip de sprite por hardware, então o programa precisa espelhar os dados do tile na VRAM na unha, gastando memória. O split de tela que os jogos de NES fazem no meio do frame, mexendo no scroll a cada scanline, também não tem equivalente direto, porque o VDP trava o scroll vertical no topo do frame.

E ainda tem o teto de VRAM. Os 8 KB de tiles do Super Mario viram 16 KB no formato 4bpp do SMS, que é a VRAM inteira do console. Fundo e sprites não cabem residentes ao mesmo tempo. E o código explode de 3 a 6 vezes de tamanho, por isso a saída SMS já é bancada desde o primeiro jogo, mesmo os mais simples.

Aproveitando o que o SMS tem de melhor

A sacada pra recuperar velocidade é parar de emular o comportamento do NES e passar a gastar as forças do Master System. O lema do projeto virou “gastar ROM pra comprar CPU”.

O SMS aceita cartuchos de vários megabytes. Então em vez de espelhar sprite na unha em tempo de execução, o build já gera variantes pré-espelhadas de cada tile de sprite, e o flip vira uma consulta de tabela. Em vez de emular a tabela de atributos do NES, o assembler já grava a palavra final de nametable do SMS, com os bits de flip, paleta e prioridade embutidos. A tabela de atributos do NES simplesmente deixa de existir no programa. As cópias pro VDP usam blocos de OUTI desenrolados, mais rápidos que o loop genérico. E o split da barra de status, que no NES depende do sprite-zero, vira uma interrupção de linha do SMS, que é o jeito nativo de fazer isso.

Nada disso é mágica. A folga negativa da CPU continua lá, então essas otimizações reduzem o custo mas não fazem milagre sozinhas. Mas é a diferença entre injogável e jogável.

O pulo do gato: fazer a IA rodar o emulador

Aqui está a parte que eu considero mais importante do projeto inteiro, e é o que separou a tentativa fracassada de maio da versão que finalmente anda.

Tradução cega não funciona. O modelo precisa de feedback real pra saber o que está quebrado e o que está lento. Então o coração do projeto está no oráculo diferencial, a infraestrutura que roda os emuladores e mede a realidade. O tradutor é só a parte fácil.

Funciona em duas camadas. A primeira compara instrução por instrução: pra cada rotina, o sistema gera estados iniciais aleatórios, roda o 6502 original num interpretador de referência e roda o Z80 gerado, e compara o resultado (acumulador, registradores, flags, RAM tocada). Qualquer divergência acende o alerta. A segunda camada compara frame a frame: ela roda a ROM do NES como verdade absoluta e a build do SMS lado a lado, com o mesmo roteiro de botões, e compara a RAM byte a byte em cada frame. Depois isso foi estendido com um oráculo que confere a VRAM e a paleta do SMS, e com um oráculo visual que compara a saída contra o frame real do NES.

Esse loop de medir é o que destravou os consertos recentes. Não foi chute. Dois exemplos concretos:

No Super Mario, cada passo de otimização foi medido em ciclos por frame, com o emulador rodando de verdade. O orçamento de um frame é 59.736 ciclos. A base parou em uns 370 mil ciclos por frame, algo como 6 vezes acima do orçamento, o que dava uns 10fps e explicava a necessidade daquele overclock brutal de 500%. Medindo passo a passo, cada mudança validada pelo oráculo, a coisa desceu até 118.296 ciclos por frame, ou 1.98 vezes o orçamento. Ou seja, saiu de 6 vezes pra menos de 2 vezes. Agora ele roda em velocidade cheia já no overclock padrão do emulador, e fica confortável ali na casa dos 200 a 300%, contra os 500 a 700% do começo.

No Castlevania, o maior ganho de velocidade veio de um perfil que só o emulador conseguiu revelar: um loop de espera de sprite-zero, no endereço $F8C7, estava fazendo 255 leituras de status e saindo por timeout toda vez, consumindo quase 23% de toda a CPU. Sem rodar o emulador e medir, ninguém acharia isso no olho. Com a medição, o conserto foi cirúrgico.

É esse o argumento maior que eu venho batendo faz tempo sobre agentes: um LLM que só gera código no escuro erra feio. Um LLM que consegue rodar o alvo de verdade, coletar dado real e reagir ao que mediu joga em outro nível.

O que aprendi estudando o port do lackoftrack27

Com esse oráculo no lugar, coloquei o Claude Fable e o GPT Astra pra dissecar o port do lackoftrack27, que é uma reimplementação do mesmo jogo a partir da mesma disassembly que eu traduzo. Isso respondeu de vez uma dúvida que estava me travando: o Super Mario cabe no Master System. O meu estouro de 6 vezes no orçamento era 100% overhead de tradução, não limitação do jogo nem do hardware.

Os ganhos dele, em ordem de impacto, foram mais ou menos esses:

• A maior de todas: a representação dos dados. Ele reorganizou os arrays de objetos do jogo em páginas de RAM, uma por slot, com os mesmos offsets de campo. Aí o X do 6502 vira o registrador H e o nome do campo vira o L, e um acesso que no meu tradutor custava umas 70 unidades de tempo passa a custar 14. O detalhe cruel é que isso só funciona porque o programador sabe, de cabeça, que aquele X ali é sempre um índice de objeto entre 0 e 6. Um tradutor estático não tem como descobrir esse invariante com segurança. Essa é a otimização mais poderosa, e é justamente a que a tradução automática não consegue provar sozinha. É o resíduo que segura as últimas 2 vezes de velocidade.
• Flags auditadas, não emuladas. Ele checou o código e achou só uns 10 lugares que dependem de verdade de alguma peculiaridade do carry do 6502. O resto usa flag nativa do Z80. Isso confirmou uma medição minha: gastar energia emulando flag rende quase nada.
• Chamadas nativas. JSR virando CALL de verdade, sem a contabilidade cara de pilha emulada. Esse foi o maior ganho genérico que eu portei pro meu pipeline.
• PPU deletado em tempo de build, não emulado em runtime, exatamente como descrevi na seção de aproveitar o SMS.
• Frame arquitetado pra estourar com elegância, transformando um estouro em um frame de lag limpo em vez de corromper a tela.

Adotei o que dava pra generalizar, e o Super Mario despencou de 6 vezes pra menos de 2 vezes o orçamento. Esse é o resultado rodando hoje:

A lição mais honesta desse estudo é dupla. Os ganhos de verdade estão na representação de dados e na convenção de chamada, não no que eu tinha atacado primeiro. E o ganho mais fundo de todos é exatamente o que o tradutor automático não consegue inferir. Isso desenha bem o teto do que dá pra automatizar.

Castlevania e o problema dos mappers

Com o Super Mario andando, voltei pro meu velho alvo: o primeiro Castlevania. E aqui a gente esbarra na limitação mais séria do NES.

O NES é um console simples, com um monte de limitação. Uma das principais é que ele não suporta jogo maior do que uns 40kb de ROM, porque o 6502 só enxerga uma janela de 32 KB de programa no espaço de endereço dele. A “solução” da época foi genial e meio maluca: partes do console foram sendo turbinadas pelo próprio cartucho.

Muita gente pensa que cartucho é só um chip de ROM com o código do jogo. No caso do NES, não. Os cartuchos vinham com uma variedade de chips extras que aumentavam a capacidade do console, seja um chip de som melhor ou, muito mais comum, os mappers. Existem vários mappers diferentes, da própria Nintendo e de third parties como Capcom e Konami. Eles usam uma técnica chamada bank switching: como o 6502 não enxerga endereço suficiente, o mapper vai trocando quais pedaços de ROM ficam visíveis naquela janela de 32 KB, conforme o jogo pede. É assim que jogos grandes cabem num console que, no papel, não aguentaria.

Eu já expliquei isso em detalhe num vídeo antigo do canal, o Akitando #81, sobre aprender computação com o Super Mario do jeito hardcore:

O Castlevania usa um dos mappers mais antigos, o UxROM. E aqui está o problema de escala do meu projeto: se eu quiser conseguir traduzir a maioria dos jogos de NES, eu tenho que mapear todos os mappers, um por um. Hoje o projeto implementa só dois: o NROM, que é o cartucho pelado do Super Mario, e o UxROM do Castlevania. Todos os outros, os MMC1, MMC3 e companhia, estão só planejados. Cada mapper é um trabalho e tanto de implementar, porque não basta entender o bank switching do NES, é preciso traduzir esse comportamento pro mapper próprio do Master System.

A boa notícia é que o Master System também é um sistema bancado, então o mapeamento é “a mesma forma um nível acima”. Um banco de PRG do NES vira um conjunto de bancos do SMS, uma escrita de troca de banco do NES vira uma escrita no mapper do SMS através de um shim, e uma chamada que cruza bancos usa a maquinaria de “portão” que já existe. A identidade de uma rotina passa a ser o par (banco, endereço), e uma tabela de despacho resolve isso em tempo de execução. Quando não acha, ele falha fechado, com um trap, em vez de rodar lixo.

É aqui que os jogos maiores vão bater na parede. O bank switching de tiles dos mappers mais avançados, o timing de interrupção por scanline do MMC3 e do MMC5, e o próprio teto de bancos do SMS pra um jogo de NES bem grande, tudo isso ainda está por resolver. Por isso eu ainda não sei dizer se um Super Mario Bros 3 é viável ou não. É bem possível que os jogos maiores morram exatamente nessa etapa.

De qualquer forma, mexi mais um bocado no Castlevania nessa retomada. Consertei uma pilha de coisas usando o oráculo: o loop de sprite-zero que comia CPU, a lógica de armas e projéteis que perdia retornos de chamada, um glitch de scroll na barra de status, a colisão de VRAM entre sprites 8x16 e 8x8, e a coerência entre fundo, paleta, HUD e sprites. Hoje o Castlevania sobe, aceita o start, desenha o primeiro estágio de forma reconhecível, responde ao controle e roda por um bom tempo sem travar. Mas é honesto dizer que ele ainda roda devagar, e o caminho que eu uso pra jogar é o Mednafen com overclock de 500%, e mesmo assim ainda está de 2 a 3 vezes abaixo da própria meta de velocidade. Está longe de ser pixel perfeito e em tempo real.

Conclusão

Depois de tantas semanas e tantas tentativas, eu ainda não sei quanto mais dá pra espremer de uma tradução automática. O teto pode estar perto, porque as otimizações mais fundas são justamente as que uma máquina não consegue inferir sozinha.

Mas tem um caminho que me anima. A tradução automática pode virar uma linha de base. Uma conversão SMS que já roda, correta, ainda que lenta, e que depois pode ser otimizada no braço, jogo a jogo, exatamente como o lackoftrack27 fez com o Super Mario e como tanta gente vem fazendo com decompilações e ports por aí. O oráculo garante que a base está correta, e a mão humana entra pra fazer o que a máquina não consegue.

Portar jogo pra um hardware muito superior, tipo um port pra PC, é relativamente fácil, porque sobra capacidade. O difícil de verdade é encaixar o jogo num console da mesma geração, onde não sobra nada. E é justamente essa dificuldade que torna a ideia de fazer versões melhores de jogos de NES pro Master System tão atraente. É o console que merecia ter tido esses jogos, e nunca teve.

Eu espero que mais gente se anime com essa possibilidade e contribua com o projeto. Está tudo aberto no nes-to-sms. Se você curte 6502, Z80, VDP e o desafio de espremer ciclo de um hardware de 40 anos atrás, apareça. Tem lugar de sobra.

Em julho eu publiquei Novidades no meu AI-MEMORY, onde mostrei o ai-memory run: trocar de Claude Code pra Codex sem perder a linha de trabalho. Naquele dia estávamos na versão 1.17.1.

Hoje saiu a 2.0. E dessa vez não vou repetir como os hooks funcionam nem como uma sessão vira página de wiki. Isso já está nos textos anteriores. Aqui eu quero falar de onde o ai-memory chegou frente à concorrência, o que a 2.0 traz e por que ela mereceu virar um “2”.

Se você nunca ouviu falar do projeto, o resumo é curto. O ai-memory é um servidor de memória de longo prazo pros seus agentes de código. Ele captura o que aconteceu na sessão, consolida em páginas Markdown e devolve o contexto certo pro próximo agente, seja qual for o harness ou a máquina.

Essa é a interface web que vem junto, boa pra auditar o que os agentes gravaram e pra navegar entre os projetos. Repare que cada projeto vive separado, com sua própria contagem de páginas, tudo saído das sessões de verdade.

Por que virou 2.0

Pra mim, o primeiro número de uma versão carrega um compromisso.

A família 1.x cresceu rápido demais. Saímos da 1.1 e chegamos na 1.39 em pouco mais de dois meses, empilhando funcionalidade atrás de funcionalidade em releases menores. Funcionou pra iterar, mas embaralhou o significado dos números.

A 2.0 arruma isso. Ela junta as poucas mudanças que quebram compatibilidade num único major, e a partir daqui o versionamento passa a seguir Semantic Versioning de verdade. Correção vira patch. Funcionalidade nova vira minor. Só quebra de formato ou de contrato vira major, e sempre com aviso. O novo guia de contribuição deixa essa regra explícita pra qualquer PR.

A quebra principal é o novo formato em disco. Na primeira vez que você sobe a 2.0, ela migra sua wiki sozinha. Antes de mexer em qualquer coisa, ela compacta todo o seu diretório de dados num backup verificado com data no nome. Se o backup não puder ser gravado e conferido, a migração aborta e o servidor se recusa a subir. Nada de “confia em mim”.

Esse é o aviso que aparece uma vez, depois da migração: ele diz onde ficou o backup, o tamanho do arquivo e como voltar atrás se algo parecer errado. Quando você confirma que está tudo certo, é só apagar o backup e o lembrete some.

OKF: sua memória não fica presa no ai-memory

Essa é a mudança que mais me deixou satisfeito.

A partir da 2.0 a wiki do ai-memory é, nativamente, um bundle no Open Knowledge Format, o formato aberto que o Google publicou em 2026. Cada página de memória é um arquivo OKF válido: Markdown comum com metadados padronizados. Não existe passo de exportação que gera uma cópia divergente. Os arquivos da wiki já são os arquivos OKF.

Na prática isso quer dizer que sua memória deixou de ser refém do meu projeto. Você pode ler tudo com grep, abrir no Obsidian, versionar no Git ou entregar o bundle pra um colega que usa outra ferramenta compatível com OKF. Tem até um ai-memory export-okf pra empacotar um projeto inteiro num tarball validado.

Sempre foi essa a tese: modelo e harness são alugados, a memória do projeto é sua. Agora o formato reforça isso por escrito.

Embeddings locais, ligados por padrão

Até a 1.x, busca semântica de verdade dependia de você configurar um provider de embeddings. Ou pagava uma API e mandava cada página e cada query pra fora, ou subia um Ollama do lado. As duas opções têm custo.

A 2.0 traz um provider local que roda o modelo de embeddings dentro do próprio processo, em Rust puro, com o all-MiniLM-L6-v2. Sem chave de API, sem servidor externo, sem GPU e sem mandar seus dados pra lugar nenhum. E agora vem ligado por padrão. Na primeira execução ele baixa o modelo (uns 87 MB, com checksum fixo) em background e liga a busca híbrida no próximo restart.

O ganho é mensurável. No benchmark LongMemEval-S, o hit@5 sobe de 0.617 só com full-text para 0.779 com os embeddings locais. Se por algum motivo você não quiser, um embedding_provider = "none" desliga.

Detalhe que importa: escolhi candle de propósito, em vez do runtime nativo que a concorrência usa. Foi justamente essa camada nativa que gerou um tipo de crash recorrente em outros projetos de memória. Preferi não herdar o problema.

Vários agentes ao mesmo tempo, no mesmo projeto

Aqui começa a parte que motivou boa parte do trabalho antes da 2.0.

O caso do ai-memory run que mostrei em julho era sequencial: fecho o Claude, abro o Codex, continuo. Mas e quando eu deixo dois ou três harnesses abertos ao mesmo tempo no mesmo projeto? Claude numa aba, Codex noutra, OpenCode numa terceira.

O ai-memory trata isso sem ninguém pisar no pé do outro. Cada chamada de memória descobre sozinha a qual projeto pertence, a partir do diretório da sessão. O ponteiro de “projeto atual” agora é por ator, então dois harnesses no mesmo checkout mantêm cada um a sua noção de contexto. E a identidade do projeto vem do nome do checkout. O caminho absoluto no disco não pesa, então o mesmo projeto no laptop e no desktop cai no mesmo lugar.

Quando duas janelas gravam na mesma página, a segunda não apaga a primeira. Ela cria uma versão nova que passa a ser a mais recente, e a anterior continua alcançável na cadeia de versões. Regravar algo idêntico não gera versão nova. Todas as escritas passam por um único writer, com fila e backpressure, então uma rajada não corrompe nada.

Isso não é teoria. Tem teste de aceitação chamando Claude, Codex, OpenCode, Pi, Crush e mais alguns de verdade, dentro de uma mesma workstream, cobrindo lease, adoção de sessão e entrega de contexto entre harnesses.

Um time inteiro no mesmo projeto

O segundo cenário é o que dá título ao post. Aqui já são várias pessoas, um time inteiro apontando os agentes pro mesmo servidor.

A forma de rodar é simples. Alguém sobe um servidor, normalmente um container num homelab ou numa máquina da rede, e cada pessoa aponta os agentes dela pra aquela URL. HTTPS entra na frente com um proxy reverso, se você quiser. O banco continua sendo um SQLite só.

Todo mundo enxerga as mesmas páginas do projeto. O que uma pessoa aprendeu numa sessão, o agente da outra recupera. E cada sessão nova recebe um briefing com o estado do projeto logo no início. Vou ser honesto com o termo “tempo real”. O que existe é um store central compartilhado, com leitura imediata, mais o briefing na abertura. A nota que um colega gravou aparece na hora pra próxima consulta ou próxima sessão de qualquer um. Uma sessão que já está rodando só recebe a novidade na consulta seguinte ou na próxima abertura, sem interrupção no meio.

O que muda no modo multiusuário é a atribuição. Cada escrita registra quem fez. Existe log de auditoria e a interface mostra “editado por fulano”. Isso já vem no pacote, de graça. E não existe permissão por página, de propósito. A atribuição serve pra registrar autoria; qualquer pessoa autenticada pode escrever, e o histórico é que guarda quem foi.

Tem uma distinção de segurança importante entre o que é compartilhado e o que é pessoal. As páginas são de todos. Mas o handoff é um bastão de um dono só: exatamente uma sessão pega, e um segundo accept não rouba o bastão de ninguém. O handoff que você deixou pendente não é entregue nem consumido por um colega. Do mesmo jeito, os “slots” de “no que estou trabalhando agora” são por pessoa, então o seu contexto pessoal não vaza no briefing do time inteiro.

Também existe uma bateria de testes de concorrência real cobrindo esses casos: escrita simultânea, isolamento por ator sob carga, o bastão do handoff que não é roubado e os slots pessoais que não vazam.

Onde o ai-memory fica frente à concorrência

Antes da 2.0 fizemos outra rodada de pesquisa sobre o cenário de 2026, documentada no repositório. Ela foi a base pra decidir o que a 2.0 precisava cobrir. Vou resumir o campo.

Tem o agentmemory, que é um MCP server em TypeScript preso a um sidecar nativo e a uma superfície gigante de dezenas de ferramentas. Tem o basic-memory, em Python, Markdown no disco, mas com captura manual: você tem que pedir pra ele lembrar. Tem o cognee, que junta grafo, vetor e relacional num pipeline pesado que pede vários gigas de RAM. Tem o MemPalace, que viralizou com quase 50 mil estrelas em duas semanas por causa de um número de benchmark que, auditado, se mostrou inflado, além de sofrer de corrupção quando duas escritas acontecem juntas. E tem os grafos temporais como Zep, os “memory OS” como Letta (o antigo MemGPT) e os extratores de fato como o Mem0.

Tem ainda a memória nativa que o próprio Claude Code passou a ligar por padrão. Essa eu trato como o funil que apresenta a categoria pras pessoas. Como concorrente ela fica limitada: presa a uma máquina, presa a um agente, sem busca de verdade e sem história de time.

A 2.0 fecha as lacunas que a pesquisa apontou. Passamos a publicar benchmark reproduzível com o LongMemEval, rodando o servidor de verdade. Ganhamos o formato aberto OKF. Ganhamos ligações tipadas entre páginas, com causes, fixes e contradicts, que ainda alimentam uma checagem de contradição sem gastar LLM. Ganhamos consulta com as_of, pra perguntar o que a gente sabia sobre um assunto numa certa data. Ganhamos os embeddings locais. E ganhamos uma passada opcional de “experiência” que revê várias sessões pra achar padrões que só aparecem no conjunto.

Agora a parte que interessa pra quem vai escolher. O que o ai-memory tem que os outros não têm, tudo junto:

• Ele te acompanha entre agentes. Mais de vinte harnesses alimentam uma memória só, e o handoff aqui é um protocolo de verdade: tipado, com dono e reivindicado uma vez só.
• Ele te acompanha entre máquinas. A memória vive num servidor que é seu. O projeto que você largou no desktop é o que você retoma no laptop.
• Ele funciona pra time. Autenticação multiusuário, atribuição por pessoa e log de auditoria já vêm no pacote, de graça.
• Sua memória é Markdown puro. A fonte da verdade é uma wiki versionada no Git. O banco é um índice derivado que dá pra reconstruir a qualquer momento a partir dos arquivos, sem vector store pra ficar de babá e sem nada preso num blob binário.
• Ele captura o trabalho sozinho e em silêncio. Sem cerimônia de “lembra disso”. E o caminho padrão roda com zero chamada de LLM.
• Ele é um binário só. Sem sidecar, sem três bancos pra sincronizar. Todas as escritas passam por um único writer, com um teto de escrita que a gente mediu de verdade, com teste real. Foi exatamente esse desenho que evitou a corrupção de escrita concorrente que derrubou os outros.

Nenhum concorrente entrega esse conjunto. Alguns têm um ou outro pedaço. O ai-memory tem o pacote, e agora com paridade nos itens onde antes ficava atrás.

A 2.0 é de todo mundo

Quando escrevi o post de julho, quinze pessoas tinham PR mergeado no projeto. Hoje são cerca de setenta. Faz tempo que isso deixou de ser um programinha de fim de semana.

Os números até a 2.0: mais de 1.500 commits, 371 pull requests mergeados e 181 issues fechadas. Isso saiu de gente usando de verdade e mandando correção, funcionalidade e documentação.

Preciso agradecer em especial ao Djalma Júnior, que sozinho passou de 50 PRs mergeados, e ao Samir Hanna Verza, com mais de 20. Logo atrás vêm lhzapata, pedrofjr, mrpaiva, lucasliet, lihuiyang1024, Murillofilho86 e Matheus Rodrigues. E tem uma cauda longa de dezenas de outras pessoas com PR mergeado que seria injusto tentar listar inteira aqui.

Se você quer entrar nessa, o guia de contribuição foi reescrito pra deixar tudo claro: como configurar o ambiente, os gates que o CI cobra, a regra do CHANGELOG e a política de versionamento. Bug fix costuma sair rápido no próximo patch. Funcionalidade pequena, como um novo harness ou provider, entra no próximo minor. Tem issue marcada pra quem está começando.

Como pegar a 2.0

A página do projeto tem todos os métodos de instalação, incluindo AUR, Homebrew e binários de release:

• ai-memory no GitHub
• Notas da release v2.0.0

Depois de atualizar, na primeira execução deixe a migração fazer o backup e converter sua wiki pro formato OKF. Se você usa o modo gerenciado, reinstale os hooks dos harnesses que pretende usar.

Conclusão

A 1.x provou que a ideia funcionava. A 2.0 é a versão que eu recomendaria sem asterisco pra outra pessoa botar num time.

O formato é aberto, então sua memória não fica presa. A busca semântica roda local, então você não paga nem vaza. Vários agentes e várias pessoas trabalham no mesmo projeto sem se atropelar. E o desenho de um binário só, com um writer só, é o que evita justamente os problemas que afundaram metade da concorrência.

LLM e assinatura eu continuo alugando de quem estiver melhor no mês. A memória do projeto fica comigo, com o time, e agora num formato que ninguém tira de mim.

E toda vez que eu publico uma dessas atualizações, sem exceção, aparece alguém nos comentários: “e o Deepseek?”

Confesso que eu não entendo esse foco cego no Deepseek. É um modelo aberto entre tantos outros, e não tem nada que o destaque do pelotão. No meu uso diário, eu continuo preferindo Kimi K3 ou GLM 5.3. Sim, a cada iteração eles melhoram um pouco. Sim, eu testei os dois snapshots novos (Flash 0731 e Pro 0813) e os números estão aqui embaixo. E mesmo assim, a resposta continua sendo: ninguém ali está na classe do Fable 5 ou do Sol.

O que essa nota mede (e o que ela não mede)

Antes dos números, o lembrete que precisa ser repetido a cada rodada. O benchmark testa um recorte muito específico: programação web fácil. Um CRUD de chat em Rails com streaming, tools, concorrência e testes. É uma prova útil porque é concreta, reproduzível e pega alucinação de API no flagra, mas continua sendo um recorte estreito.

Ela não diz nada sobre tarefas muito mais avançadas: desenvolvimento de driver de kernel, otimização de game engine, segurança ofensiva de verdade. É impossível testar a totalidade de um modelo. O que dá pra testar é um subconjunto, e foi o que eu fiz.

Então, da próxima vez que você vir “Kimi está prestes a destronar o Fable” ou “GLM vai passar o Sol” porque as notas ficaram parecidas, leia assim: num subconjunto estreito de programação web, qualquer um desses modelos entrega. Só isso. Nota próxima nessa prova significa proximidade nessa prova, em mais nada.

Pra guardar: benchmark mede um recorte. O meu mede web app fácil em Rails. Quem extrapola isso pra “modelo X é melhor que modelo Y em tudo” está lendo o número errado.

O ranking do Tier A, com foco no tempo

A tabela de sempre, recorte A.1 (90 pontos ou mais), agora com os dois Deepseek em negrito. Dessa vez preste atenção na coluna de tempo: é a mesma prova, as mesmas três fases, pra todo mundo.

Tempo é o wall clock das três fases; custo é equivalente em API. O critério é o mesmo dos artigos anteriores, link no fim.

Olha o espalhamento de tempo. O mais rápido do grupo resolve a prova em 15 minutos; o mais lento leva 155, dez vezes mais. Os dois Deepseek ficam na metade de baixo da tabela em velocidade: 82 e 88 minutos, atrás de quase todo mundo na mesma faixa de nota. O Flash, em particular, despejou 44 milhões de tokens na rodada. Pra comparação, o GLM 5.3 fez um ponto a mais com 19,4 milhões. O Deepseek compensa na fatura: os $0,82 do Flash são o menor custo de uma rodada Tier A até hoje.

Os snapshots novos: o que mudou de julho pra cá

Rodei os builds de julho do v4 no fim daquele mês: Flash fez 80, Pro fez 82, ambos Tier B. Os dois snapshots datados (0731 e 0813) rodaram hoje sob o mesmo rigor, e os dois entraram no Tier A:

Flash 0731: de 80 pra 90 (+10). A melhoria mais visível é de comportamento. O build de julho pinava um modelo três gerações atrás; esse acertou o pin de primeira (anthropic/claude-sonnet-5, sem slug velho). A auto-revisão foi exemplar: ele mesmo encontrou que o partial da bolha de streaming era código morto (nenhuma resposta aparecia até um reload forçado nas fases 1 e 2), confessou, corrigiu e tirou 15/15 em honestidade. Perdeu pontos onde o pelotão perde: concorrência sem lock de turno (8) e cobertura sem branch (8).

Pro 0813: de 82 pra 91 (+9). A notícia grande é o que sumiu: o bug do reasoning_content que quebrava o multi-turn dele no OpenCode e me obrigou a inventar a gambiarra do deepclaude em maio foi corrigido no opencode 1.18.4, e esse snapshot rodou ponta a ponta no harness genérico, sem muleta. O destaque técnico foi a concorrência: store SQLite com leitura-modificação-escrita dentro de BEGIN IMMEDIATE, a solução mais séria do grupo nessa dimensão (9/10). As perdas foram honestas e confessadas: pin velho no sonnet-4.6, streaming verificado só por teste unitário, sem estimador de orçamento com fallback.

Rodadas limpas, blindadas, zero leitura de rubrica ou de app alheio. Os relatórios completos estão no repositório do benchmark.

Deepseek contra ele mesmo: a trajetória é real

Critério novo e critério velho não se comparam ponto a ponto, então essa seção é sobre comportamento, não sobre nota. E comportamento dá pra comparar, porque o contraste é gritante.

Em abril, o Deepseek V3.2 fez 43 no critério antigo e protagonizou o momento mais constrangedor da história do benchmark: inventou a integração inteira com o RubyLLM. RubyLLM::Client.new, client.chat(messages:), os dois métodos alucinados, a camada de LLM inteira ficcional.

Ainda no critério velho, o v4 Flash fez 78 com um bug fatal de um caractere (o slug do modelo sem o prefixo anthropic/), e o v4 Pro deu DNF com 69: código de Tier 1, entrega de Tier 3, derrubado pelo bug do reasoning_content que comia o histórico da conversa. Foi esse bug que gerou o hack do deepclaude, onde o mesmo Pro saltou pra 89.

No v2, os builds de julho fizeram 80 e 82. Os snapshots de hoje, 90 e 91. Saindo do “inventou a API inteira” pra “acha o próprio código morto e confessa na auto-revisão” em quatro meses. A curva do Deepseek é das mais íngremes que essa prova já registrou, e seria desonesto fingir o contrário.

E contra os outros chineses?

Aqui a conversa fica menos empolgante pra torcida. No mesmo harness genérico (OpenCode), o pelotão chinês fica assim:

E o Kimi K3, que não aparece nessa tabela por ter rodado no harness nativo dele, fez 95. Ou seja: dentro da mesma prova, o Deepseek v4 chega atrás do GLM 5.3, do Qwen 3.8 Max e dos Kimi, sendo o mais lento e o mais verboso do grupo chinês. A vantagem dele é uma só, e é real: preço. $0,82 por uma rodada Tier A é impressionante, e o Pro a $5,01 fica abaixo de quase todo mundo na mesma nota.

Se o seu critério é “máximo de competência por dólar em tarefa web simples”, o Flash 0731 merece atenção. Se o critério é o melhor modelo do grupo, a resposta continua sendo Kimi K3 e GLM 5.3, como era semana passada.

Conclusão: parem de perguntar

Pronto, agora tem número na mesa. O Deepseek v4 melhorou de verdade entre julho e agosto, os dois snapshots entraram no Tier A, o Pro se livrou do bug que exigia gambiarra de harness, e o Flash é a rodada Tier A mais barata que eu já rodei. Tudo isso é fato.

E nada disso muda o quadro. A liderança continua com Fable 5, Sonnet 5, Opus 5 e Sol; o primeiro chinês da fila continua sendo o Kimi K3, seguido do GLM 5.3. O Deepseek é mais um modelo competente num recorte de tarefa fácil, com a virtude de ser barato e o defeito de ser prolixo. Da próxima vez que bater a vontade de comentar “e o Deepseek?”, a resposta é este artigo.

O topo continua onde estava: Fable 5 com 96, o trio Sonnet 5, Opus 5 e Kimi K3 com 95, e logo atrás GPT 5.6 Sol, GPT 5.6 Terra e Opus 4.8 com 93. Essa é a nata da nata nesta prova. A pergunta que ficou: o quanto os lançamentos mais novos chegam perto desse grupo?

Desde então rodei cinco modelos: Qwen 3.8 Max, GLM 5.3, Gemini 3.7 Flash, Grok 4.6 e um Qwen 3.8 de 27B rodando local na minha RTX 5090. Um deles encostou no grupo de cima. Outro protagonizou o maior salto que esta prova já registrou. Um terceiro foi pego colando no meio da prova. Um quarto empatou com a própria geração anterior, sem andar um passo. E o local me deu a rodada mais trabalhosa — e mais instrutiva — do ano.

Onde eles caem no ranking

Antes de abrir cada um, vale ver onde os novatos se encaixam. A tabela abaixo é o recorte Tier A.1 do ranking do v2: a fronteira da prova, todo mundo com 90 pontos ou mais. Cortei aqui de propósito. De A.2 pra baixo tem modelo competente, mas quem disputa a liderança está neste grupo, e é dele que a pergunta trata. Os três lançamentos de nuvem entram em negrito; o Qwen 27B local fez 51, Tier C, e aparece só na tabela do fim.

Tempo é o wall clock das três fases; custo é equivalente em API. Em assinatura (Z.ai, grok CLI) o custo marginal é $0 e o valor entre parênteses é o equivalente em API; as rodadas no Antigravity eram preview e não foram medidas. O critério é o mesmo do artigo anterior.

Qwen 3.8 Max: o maior salto da história do benchmark

Pra medir o salto, primeiro o tamanho do buraco. O Qwen3.7 Max tinha feito 51 pontos, Tier C, e o motivo era feio. Na hora de implementar o chat multi-turn, ele decidiu que dava pra replayar o histórico chamando chat.ask(array_com_o_histórico_inteiro). Só que o ask do RubyLLM empacota o argumento numa única mensagem de usuário — a conversa inteira, incluindo as respostas do assistente, virava uma mensagem só, com todos os papeis obliterados. Pior: o teste obrigatório dessa funcionalidade mockava exatamente essa API inexistente. Um teste que mocka uma API fabricada é pior que não ter teste, porque certifica a alucinação.

O 3.8 Max consertou exatamente isso. Usou a API real de ponta a ponta — add_message com role e content pro replay do histórico, with_instructions, with_tools, with_schema — tudo conferido contra o código da gem na versão instalada. Resultado: 92 pontos, Tier A. São 41 pontos de salto na mesma prova, mesma rubrica, mesmo harness. Não foi a prova que ficou mais fácil; foi o modelo que finalmente entendeu a biblioteca.

O resto da entrega é sólido: streaming real e incremental, histórico sobrevivendo a restart, calculadora escrita à mão sem eval, tools respondendo com aritmética exata, app subindo no Docker de primeira. A suite saiu com 62 testes e 226 asserções, tudo verde.

Onde ele perdeu ponto é instrutivo: o config/puma.rb saiu sem a diretiva workers, então o WEB_CONCURRENCY=2 que ele jurava ter entregue rodava, na prática, em processo único. Concorrência ficou em 8 em vez de 9. E manteve o pin velho no claude-sonnet-4.6, a dedução padrão da casa.

Pra guardar: o modelo jurou que a concorrência funcionava — faltava uma linha no puma.rb e os “dois workers” rodavam num processo só. Por isso a fase 2 não lê README: ela sobe o servidor e mede.

Na tabela, os 92 empatam com GLM 5.2 e Kimi K2.5, um ponto abaixo de Sol e Terra. Custou $9,16 em API e 78 minutos — verboso: 25 milhões de tokens.

GLM 5.3: o degrau mais solitário da tabela

A trajetória da Z.ai nesta prova é a mais constante do pelotão: GLM 5 fez 83, GLM 5.2 fez 92, e agora o GLM 5.3 fez 94 — sozinho num degrau que ninguém mais ocupa, um ponto abaixo do trio dos 95 e um ponto acima do grupo dos 93. Ou seja: a dois pontos do Fable 5.

E a comparação inevitável é com o Kimi. O K3 fez 95, um ponto acima — mas rodou no Kimi CLI, o harness nativo dele. Os 94 do GLM 5.3 vieram no OpenCode, o harness genérico: é a maior nota já registrada lá. No mesmo OpenCode, o melhor Kimi é o K2.5 com 92, dois pontos abaixo. No custo, os dois vivem de assinatura: o K3 saiu por $6,14 equivalentes no plano Moderato; o GLM, a custo marginal zero. O Kimi ainda leva na nota; o GLM leva no custo e na independência de harness.

O que tirou ele do pelotão dos 92? Três coisas, todas chatas, todas importantes:

1. Concorrência entregue funcionando. O mesmo esquema de lock em arquivo do Qwen 3.8 Max, mais um lock de turno por conversa, mais dois workers de verdade sobrevivendo a kill e restart sem corromper nada. O Qwen tinha a mesma base, mas entregou a concorrência quebrada e ficou com 8. O GLM entregou funcionando e levou 9.
2. Estimador de tokens com fallback, então o orçamento por conversa funciona mesmo quando o provider não devolve o consumo. O 5.2 dependia, e perdia ponto ali.
3. Cobertura de branch ligada: 98% de linha e 82% de branch, suite com 73 testes e 219 asserções verde na mão do auditor, RuboCop, Brakeman e bundle-audit zerados.

Pra guardar: a distância entre o pelotão dos 92 e os 94 do GLM não é brilho de modelo: é concorrência que funciona, estimador de tokens com fallback e cobertura de branch. Engenharia chata ganha ponto.

O único deslize foi o mesmo pin velho no sonnet-4.6. E houve um bug de divisão por zero na calculadora que o próprio modelo achou e corrigiu na auto-revisão — o tipo de comportamento que essa fase existe pra medir. Falando nela: ele confessou tudo, inclusive que o título da conversa nunca tenta gerar de novo se a primeira tentativa falhar, e levou 14 dos 15 pontos de honestidade.

E o custo é a parte que dói nos concorrentes: rodou no plano de taxa fixa da Z.ai, então a rodada saiu a custo marginal zero — o equivalente em API seria $2,59. Oitenta minutos, 19,4 milhões de tokens. A conversa de que modelo chinês é “alternativa barata” morreu faz tempo: aqui é candidato à liderança que também é barato.

Gemini 3.7 Flash: 93, Tier A — e a cola pelo caminho

A parte técnica você já conhece: o Gemini 3.1 Pro morreu no v2 por causa de um bug do Google, o Corrupted thought signature, que derrubava a execução no meio do caminho via OpenRouter e o deixou preso em 62 (pelo caminho direto, fez 88). Desta vez cortei o intermediário: chave direta da API do Gemini, sem OpenRouter no meio, e o bug não apareceu uma vez sequer. O caminho direto funcionou — e o 3.7 Flash virou o primeiro Gemini a chegar no Tier A rodando no OpenCode: o 3.5 Flash fez 79 lá, o 3.1 Pro, 62. Antes, só o harness nativo do Google tinha levado um Gemini ao A.

Resultado oficial: 93 pontos, empate com GPT 5.6 Sol, Terra e Opus 4.8. A rodada custou $4,12, durou 43 minutos e gastou 27,8 milhões de tokens.

Mas o caminho até esse 93 rendeu a descoberta mais importante deste ciclo. A primeira rodada do 3.7 Flash levantou suspeita — e tinha motivo. No meio da construção, e de novo na auto-revisão, o modelo leu a rubrica de correção, leu o relatório do v2 inteiro — com a nota e a auditoria de cada concorrente — e rodou o scanner de auditoria em cima de si mesmo oito vezes. Ele passou a prova inteira estudando como seria avaliado.

A arma do crime está no pin. A rodada contaminada saiu com o pin correto no claude-sonnet-5, aquele feito que só três modelos tinham conseguido em toda a história do benchmark. Anulei a rodada e refiz com todo o material de correção fora do alcance do modelo: saiu o pin velho no claude-sonnet-4.6, como todo mundo. Ele não conhecia o modelo atual coisa nenhuma — tinha lido a resposta no relatório. O 93 é dessa segunda rodada, limpa.

Pra ser justo: ele não copiou código de nenhum app vizinho. O que ele fez foi colar da correção — e isso bastou pra nenhum modelo, de fronteira ou não, rodar mais com acesso a esse material.

E o 93 não é caridade, a entrega se sustenta sozinha. API do RubyLLM real de ponta a ponta, calculadora segura sem eval, histórico multi-turn correto, streaming incremental funcionando de ponta a ponta no Docker, persistência que sobrevive a restart com dois workers. Suite com 55 testes e 213 asserções, tudo verde, cobertura de branch ligada. Os descontos: o pin velho e a falta de um lock de turno por conversa — o mesmo teto de concorrência do Fable 5.

Pra guardar: desta vez não foi um local fraco colando do vizinho. Foi um modelo de fronteira consultando as respostas no meio da prova.

Qwen 3.8 27B local: a rodada mais trabalhosa do ano

No artigo anterior eu disse que só testaria um local novo se surgisse evidência forte. Aí o irmão Max fez 92, a versão aberta de 27B estava disponível, e eu tinha a desculpa que faltava. Valeu pela ciência, mas deu trabalho.

A primeira surpresa: o 3.8 27B usa uma arquitetura híbrida SSM/Mamba, e o meu build tunado de llama.cpp do llama-swap não consegue carregar o modelo — falta um tensor (ssm_conv1d) que só as versões mais novas conhecem. A solução foi subir um container zerado do Ollama, que embute um llama.cpp atual, e importar o GGUF que eu já tinha baixado via Modelfile. Primeira lição: em modelo local, as ferramentas envelhecem em meses.

A segunda surpresa: contexto. Um modelo de raciocínio torra uma quantidade absurda de tokens pensando, e janela pequena não basta — com 32K ou 64K ele nem termina a prova, esgotando tudo na leitura do código da gem antes de escrever a primeira linha do app. A rodada oficial precisou de 176K de contexto, quase tudo que os 32 GB da RTX 5090 aguentam. Quem impediu o modelo de terminar foi teto de contexto, não falta de capacidade.

Aí veio o incidente. A primeira rodada completou — e completou bem demais. Fui olhar o log: o modelo tinha lido dezesseis vezes o app pronto do Qwen 3.8 Max online, que estava no repositório, e copiado a UI e o streaming dele. Teria levado uns 75 pontos com trabalho alheio. Anulei e refiz sem nenhum app de terceiro por perto. E como a seção do Gemini ali em cima mostra, não são só os locais que procuram ajuda quando ela está dando sopa.

Pra guardar: modelo local fraco não inventa só API inexistente — ele também cola do vizinho quando o vizinho está no mesmo diretório.

Na rodada limpa, o 27B fez 51 pontos, Tier C — empatado, por acaso, com a nota do Qwen3.7 Max online. E o recibo é misto. O miolo ele acertou: add_message de verdade, with_tools de verdade, calculadora por descida recursiva sem eval, fruto de ter lido o código da gem de verdade. Onde ele afundou foi na largura: usou ActiveRecord onde os requisitos proíbem, o streaming sai quebrado (os tokens são transmitidos, mas o balão da resposta nunca entra na tela — ela só aparece se você atualizar a página), não usou with_schema, não fez orçamento de tokens, entregou zero testes, RuboCop com 22 ofensas, e nem Dockerfile saiu. Já a auto-revisão foi exemplar: ele mesmo achou e confessou cada um desses defeitos, com arquivo e linha — 14 dos 15 pontos de honestidade. Sabe revisar melhor do que constrói.

Custo da rodada: zero reais, 37 milhões de tokens e 156 minutos de uma RTX 5090 suando.

Pra calibrar o 51: o piso do Tier A é o Opus 4.6 com 83. O gap de 32 pontos não está em “conhecer a biblioteca” — nisso o 27B agora acerta. Está nas dimensões de robustez de produção: streaming, testes, gates, Docker, orçamento. É a diferença entre saber programar e saber entregar.

E comparando com os locais de antes — sempre com o aviso de que as provas não são comparáveis: no v1, os Qwens locais alucinavam a gem por inteiro (um inventou um Openrouter::Client com a capitalização errada, outro criou um RubyLLM::Client que não existe). O Qwen 3.5 35B acertou o ponto de entrada, mas os testes embrulhavam qualquer exceção num assert true. O 3.6 35B foi o primeiro local a acertar as chamadas principais, ainda com o multi-turn quebrado. O 3.8 27B acerta o núcleo inteiro da API numa prova muito mais difícil. A nota não dá pra comparar; o comportamento, dá: conhecimento de API deixou de ser o problema dos locais. O problema agora é engenharia.

Grok 4.6: o primeiro empate geracional, e a rodada mais limpa

Depois de dois flagrantes de cola, veio um respiro. Rodei o Grok 4.6 já com a blindagem no talo: tirei tudo do alcance do modelo — a rubrica de correção, o relatório inteiro do v2, o scanner de auditoria, o catálogo de deduções do CLAUDE.md e os 44 apps dos concorrentes, todos movidos pra fora do repositório. Foi a primeira rodada sob esse regime mais rígido. E a varredura pós-prova não achou nada: zero leitura de arquivo de correção, zero olhada em app vizinho. Passou limpo. Depois do Gemini e do Qwen local, é bom ver um modelo de fronteira construindo sozinho porque não tinha por onde colar.

O resultado traz um dado curioso: 92 pontos, Tier A, a mesma nota do Grok 4.5. É o primeiro empate de geração contra geração de toda a prova. Enquanto o GLM subiu 83, 92, 94, o Kimi foi de 77 a 86 a 95 e o Claude escalou sem tropeço, o Grok andou de lado. O 4.6 não comprou um ponto sequer sobre o 4.5. Na tabela lá em cima o 4.5 aparece com 91 porque uso o número dele no grok CLI, o harness nativo; cabeça a cabeça no mesmo OpenCode, os dois batem 92 cravado.

O que ele entregou é sólido e real. API do RubyLLM correta de ponta a ponta, uma calculadora sem eval escrita à mão (tokenizer por regex e parser, provada ao vivo com (12.5*4)/2+7 = 32.0), um teste que confere a array exata enviada ao provider, store em arquivo com lock sobrevivendo a restart com dois workers, orçamento de tokens com estimador de fallback, e o docker compose up --build respondendo um chat de verdade. O streaming foi provado ao vivo na fase 2: cinco tokens chegando incrementais enquanto o POST ainda estava aberto. E foi o mais econômico de todos os Tier A no OpenCode, com 10 milhões de tokens, porque o Grok é seco. Custou $6,33 e 34 minutos.

Os descontos são honestos, e ele mesmo confessou. O lock não cobre a janela de leitura-alteração-escrita, então dois turnos simultâneos na mesma conversa viram uma corrida de último-a-escrever-vence, o mesmo perigo do GLM 5.2. A cobertura de teste é rasa no caminho crítico, com o teste de integração sendo só um smoke test da home. E manteve o pin velho no claude-sonnet-4.6, a dedução padrão da casa. Auto-revisão de 12 PASS e 2 PARTIAL, tudo conferido pelo auditor. Nada de brilho novo: é um bom modelo repetindo um bom modelo.

Depois eu rodei o mesmo Grok 4.6 no harness nativo, o grok CLI, pra ver se mudava alguma coisa. Mudou pouco: 93 no grok CLI contra 92 no OpenCode, um ponto de diferença, dentro do ruído. Não é efeito de harness. O CLI não deu andaime nem quebrou nada; o Grok constrói bem competente nos dois.

O tal ponto a mais tem uma explicação concreta e boba: por acaso, a rodada do CLI trancou a janela inteira de leitura-alteração-escrita do store num File::LOCK_EX, então a concorrência foi pra 9; a do OpenCode deixou aquela corrida aberta e ficou em 8. Mesmo modelo, uma rodada cada: a diferença é variância entre as duas gerações de código. O harness não teve papel nisso. O que mudou de verdade foi o custo: no grok CLI a mesma prova saiu por $1,19, contra os $6,33 do OpenCode, pelos mesmos ~11 milhões de tokens, graças ao cache nativo da xAI.

Pra guardar: nem toda geração nova traz ponto. O Grok 4.6 empatou consigo mesmo, e a notícia boa foi ter passado limpo pela blindagem mais dura que já apliquei.

Conclusão: quão perto eles chegaram?

Resposta curta: muito perto.

GLM 5.3 a dois pontos do Fable 5 não é “alternativa barata”, é candidato à liderança. Qwen 3.8 Max a um ponto de Sol e Terra idem. A distância entre a nata americana e os chineses novos é de um ou dois pontos — e eu mesmo repito em todo artigo que um ou dois pontos é ruído. E o Gemini 3.7 Flash entrou no bolo: 93, empatado com Sol, Terra e Opus 4.8, o primeiro Gemini a chegar lá pelo OpenCode. O Grok 4.6 entrou no mesmo balde dos 92, mas com um asterisco só dele: foi a única geração nova que não melhorou nada sobre a anterior, e mesmo assim foi a primeira a passar limpa pela blindagem mais dura.

E o local segue fora de questão pra coding agent autônomo: Tier C é Tier C. Mas repare que a conversa mudou. Até pouco tempo atrás eu descartava local porque ele inventava API. Hoje ele conhece a API e tropeça em streaming, testes e Docker — e precisa de 176K de contexto e 32 GB de VRAM só pra completar a prova. O gargalo subiu de nível. Não é recomendação ainda; é o caminho sendo pavimentado.

Pra guardar: a nata da nata continua sendo Fable, Opus, Sonnet, K3 e os GPT 5.6. Mas o pelotão de perseguição já está a um ou dois pontos — e o fosso entre “fronteira” e “alternativa” virou território de ruído.

Como sempre: artefatos, logs, rubrica, deduções e a tabela atualizada estão no llm-coding-benchmark. As duas rodadas do Gemini 3.7 — a anulada e a oficial — estão documentadas no relatório, com o achado de contaminação em destaque.

Ótimo. A tabela do primeiro artigo já virou peça de museu.

O argumento do segundo continua valendo. Na verdade, ficou ainda mais fácil de demonstrar, porque passei os últimos dias refazendo praticamente o benchmark inteiro. Foram dezenas de runs, várias tentativas descartadas, centenas de dólares entre API e créditos equivalentes, e uma quantidade indecente de tempo lendo código Rails gerado por robô.

O resultado é a versão 2 do meu LLM Coding Benchmark. A prova ficou mais difícil, a auditoria ficou mais explícita e cada família passou a rodar, sempre que possível, no harness onde deveria funcionar melhor.

E já vou adiantar: os scores do v2 não são comparáveis diretamente aos do v1. Mudaram o prompt, os requisitos, o harness de vários modelos, a validação e a rubrica. A coluna v1 no relatório serve como histórico, não como medição científica de quanto cada modelo “evoluiu”.

Por que aposentei o v1

Rodamos o v1 por meses. Ele serviu muito bem pra separar quem realmente conseguia construir um app Rails de quem inventava APIs do RubyLLM, escrevia testes pra própria alucinação e entregava Dockerfile que nunca subia.

Só que os modelos novos chegaram ao teto daquela prova. Quinze dos quarenta resultados já estavam comprimidos no Tier A, com o topo entre 92 e 97. O trabalho ainda tinha detalhes reais, mas os melhores modelos passavam pelos antigos discriminadores com facilidade. A ordem começava a depender de um preflight de API key aqui, um limite de cookie ali, um teste de erro que faltou. Detalhes válidos, pouca separação.

Também havia uma inconsistência operacional: a combinação entre modelo e harness. Claude tinha sido testado no OpenCode, Grok também, Kimi também, Gemini também. Só que hoje temos Claude Code, Codex, Kimi Code CLI, grok CLI e Antigravity. Medir um modelo num harness genérico quando existe uma integração feita pro comportamento dele pode distorcer o resultado.

O que o benchmark mede nunca foi apenas o arquivo de pesos:

resultado = modelo + harness + prompt + tools + contexto + execução + auditoria

Então resolvi parar de esconder o harness dentro da nota. Claude foi pro Claude Code. GPT foi pro Codex. Kimi K3 e K2.7-Coding foram pro Kimi CLI. Grok e Gemini ganharam rodadas A/B nos CLIs dos próprios vendors. OpenCode, completamente isolado, continuou como fallback pros modelos sem harness melhor ou sem acesso por assinatura.

A prova nova

O v1 tinha duas fases: construir e tentar subir. O v2 tem três fases, quatorze objetivos numerados e uma rubrica de dez dimensões.

Na primeira fase, o modelo ainda precisa construir sozinho um chat estilo ChatGPT em Rails com RubyLLM, Hotwire, Tailwind, Minitest, Docker e Compose. A semelhança termina aí. Agora ele também precisa entregar:

• streaming real por token via Turbo Streams, comprovadamente incremental;
• payload multi-turn sem mandar a mensagem atual duas vezes, com um teste da array exata enviada ao provider;
• persistência que sobreviva a restart e funcione com WEB_CONCURRENCY=2, com TTL e limites de quantidade e bytes;
• exatamente duas tools, server_time e uma calculadora segura, usando a API real do RubyLLM;
• título gerado pela API de structured output;
• orçamento de tokens por conversa;
• system prompt, preflight de credencial, estados degradados e tratamento dos erros do provider;
• garantia de que turnos que falharam nunca contaminem o histórico futuro;
• RuboCop, Brakeman e bundle-audit limpos, além de Docker de produção non-root e ausência de secrets.

A segunda fase não aceita um README dizendo que funciona. Ela sobe o Rails, observa os tokens chegando, força chamadas reais às tools, mantém uma conversa com dois workers, reinicia o servidor, confere o histórico, roda os testes e gates, faz docker build e manda uma mensagem real pro app dentro do Compose.

A terceira fase pede que o próprio modelo revise cada objetivo como PASS, PARTIAL ou FAIL, cite arquivo, linha, teste ou comando e escreva o que ainda está quebrado. Essa honestidade vale 15 pontos. Um FAIL correto vale mais que um PASS otimista que a auditoria desmente.

Essa fase trouxe um dado que o v1 não tinha. Kimi K3 e Nex, por exemplo, admitiram defeitos que seria fácil esconder. Outros construíram um app razoável e depois alucinaram a própria inspeção. Saber programar e saber revisar o que programou são capacidades diferentes.

O harness também entrou no teste

Também fiz A/Bs com as ferramentas nativas:

O harness nativo não joga pó mágico no modelo. Grok 4.5 praticamente não ligou. Grok 4.3 precisava da estrutura. Gemini 3.1 precisava de um transporte que não quebrasse com Corrupted thought signature. Três mecanismos diferentes, que uma comparação apressada chamaria simplesmente de “o CLI melhorou a nota”.

No ranking abaixo, uso o harness preferencial quando existe uma rodada completa: Antigravity pros Geminis e grok CLI pros Groks. Os baselines de OpenCode continuam no repositório como A/B, mas não aparecem uma segunda vez na tabela.

O novo ranking

Esta é a tabela consolidada do v2, com uma entrada por modelo no harness preferencial disponível.

Tempo é o wall clock de ponta a ponta das três fases. Custo é equivalente em API: nos modelos no Codex uso o valor blended com desconto de cache (mesmo critério da seção de custos abaixo); em planos de assinatura (Z.ai, grok CLI) o custo marginal é $0 e o número entre parênteses é o equivalente em API; as rodadas no Antigravity eram preview e não foram medidas.

Os detalhes, artefatos e deduções estão no relatório completo do v2.

O que os tiers querem dizer agora

O novo corte foi ancorado no Claude Opus 4.6, que fez 83 e mostrou o mínimo necessário pra carregar a prova inteira. A interpretação prática ficou assim:

Temos 15 modelos no A.1 e 9 no A.2. Os 24 passaram do piso de competência pra esse tipo de trabalho. A subdivisão ajuda a escolher por onde começar: A.1 concentra os resultados de fronteira; A.2 reúne modelos competentes que exigiram mais consertos, deixaram testes mais rasos ou carregaram limitações operacionais mais claras.

Isso não transforma 96 em uma inteligência universalmente maior que 91, nem torna um A.2 ruim. Um modelo A.2 pode ser melhor em refactor, debugging, frontend ou dentro do seu monolito de quinze anos. A prova não mede tudo isso. O corte só evita colocar 24 opções num balde grande demais.

A.1 e A.2 formam o grupo de candidatos. Tier C e D são grupos que eu corto antes de começar.

Afinal, qual é o melhor: Fable, Opus, Terra ou Kimi?

Se você só quer uma resposta de uma linha, vai se decepcionar de novo.

No artefato final, Fable ganhou. Também foi o mais rápido entre esses quatro. Se eu estivesse pagando cada chamada de API dessa rodada, o Kimi K3 ganhou de lavada no custo, empatado com Opus em 95 e só um ponto abaixo de Fable.

Opus 5 fez um projeto excelente, mas foi o mais lento e gastou 56,8 milhões de tokens somados pelo Claude Code. Nesta prova ele não comprou nada visível com os 33 minutos extras sobre Fable. Terra também entregou bem, ficou dois pontos abaixo de K3 e custou menos que Fable e Opus no equivalente de API.

Quem já paga Claude Max ou ChatGPT Pro tem custo marginal próximo de zero enquanto estiver dentro dos limites. Kimi Moderato também é assinatura, com janelas de quota próprias. Portanto, “$26 contra $6” não decide sozinho. A primeira pergunta é qual assinatura você já paga e quanto limite ainda tem. Pra pay-as-you-go e automação, aí sim o custo por execução volta pro centro.

Minha leitura desse run:

• Fable 5 entregou o melhor pacote de qualidade e tempo;
• Kimi K3 foi o melhor custo-benefício entre os líderes;
• Opus 5 foi competente e meticuloso, mas caro e lento nesta execução;
• GPT 5.6 Terra entregou o melhor equilíbrio da família pra quem vive no Codex.

É uma leitura deste projeto. Troque o workload e a ordem pode virar.

Opus contra Sonnet, Sol contra Terra

Nome de tier não é benchmark. O Sonnet 5 provou isso de um jeito quase constrangedor:

Sonnet 5 empatou com Opus 5, terminou dezenove minutos antes e produziu a primeira cobertura de linhas realmente 100% de todo o benchmark. Também fez a melhor self-review da família. Escolher Opus automaticamente porque “Opus é a tier maior” seria jogar os próprios dados fora.

Isso também corrige uma impressão péssima do v1, onde Sonnet 5 tinha feito 58 e alucinado a API do RubyLLM. No v2 ele rodou no Claude Code, recebeu requisitos explícitos e fez 95. Não dá pra concluir que o modelo melhorou 37 pontos porque mudamos quase todo o experimento. Dá pra concluir que a combinação v1 era uma representação ruim do que ele consegue fazer.

Do lado da OpenAI:

Terra empatou com Sol em 93, terminou oito minutos antes e custou pouco mais de um terço no cálculo blended. Também produziu a melhor proteção de concorrência de toda a rodada: Redis com WATCH/MULTI, lock distribuído por conversa e escolha forçada de tool. Nesta prova, pagar pelo Sol não comprou nenhum ponto nem economizou tempo. Terra é a escolha mais racional da família.

Luna continua na tabela porque fez 91 e ainda é um resultado A.1, mas perdeu o argumento de custo: Terra ficou dois pontos acima por apenas treze centavos a mais e levou cerca de três minutos extras.

O detalhe importante continua sendo o cache. Dos 21,7 milhões de tokens de input do Terra, 21 milhões eram cache hits. Cobrar tudo como input novo daria um teto de $111,62. Com a tarifa de cache, cai pra $16,92. Qualquer tabela de custo que mistura CLIs sem entender o que cada uma reporta está comparando banana com JSON.

E os modelos chineses?

A conversa de que modelo chinês só serve como alternativa barata ficou velha.

Kimi K3 empatou com Opus 5. K2.5, K2.6, MiniMax M3 e GLM 5.2 ficaram no mesmo A.1 de Claude e GPT. As execuções via OpenCode continuam mais baratas que a faixa de $16 a $45 dos líderes rodados em Claude Code e Codex, mas já não é uma comparação de centavos contra dezenas de dólares. E assinatura não é API: o GLM teve custo marginal zero porque rodou no plano da Z.ai; o mesmo consumo sairia por cerca de $12,05 via API.

O Kimi é a família mais fácil de recomendar hoje. K3 oferece qualidade de topo na assinatura barata. K2.5 e K2.6 foram econômicos via API, custando $1,50 e $2,64. K2.7 ficou abaixo dos irmãos, mas rodou em outro harness, então não vou inventar uma historinha de evolução linear com quatro pontos isolados.

MiniMax M3 merece atenção e cautela na mesma medida. Fez 91 por $7,72, ainda abaixo de uma rodada nos líderes americanos, mas gastou 121 milhões de tokens e levou quase duas horas. Foi a execução mais cara e mais voraz em tokens entre as rodadas de OpenCode. O score é bom; o perfil de uso, nem tanto.

GLM 5.2 fez 92 com custo marginal zero no plano da Z.ai, mas consumiu o equivalente a $12,05 em API. Levou cerca de duas horas e meia. Se tempo de wall clock não importa, é uma opção muito forte. Se você trabalha em ciclos curtos, Grok 4.5 entregou 91 em cerca de 25 minutos no grok CLI, mais de seis vezes mais rápido.

DeepSeek continua barato, mas parou no Tier B. V4 Pro fez 82 por $0,35 e V4 Flash fez 80 por $0,81. Estão perto e quero repetir quando vier uma versão nova. Hoje eu ainda não usaria nenhum dos dois pra deixar um coding agent trabalhando sozinho numa codebase que importa. Economizar um ou dois dólares pra depois gastar uma hora revisando defeito estrutural é uma conta ruim.

Por que não refiz os modelos locais

Não rodei Qwen 3.5 e os outros modelos locais no v2. A prioridade passou a ser mapear melhor o Tier A de programação, e cada execução completa dessa prova custa tempo de máquina, auditoria e sanidade.

Os locals não são inúteis. Servem pra tradução, classificação, resumo, one-shot controlado e tarefas onde privacidade ou operação offline pesa mais que qualidade. Já pra coding agent autônomo, os testes do v1 ficaram muito abaixo do piso. A prova v2 é mais difícil. Não vejo motivo pra gastar vários dias confirmando de novo que um Qwen quantizado local não compete com Fable, Opus, GPT 5.6 ou Kimi em engenharia de software.

Pra programação, hoje não vale a pena. Se surgir um modelo local novo com evidência forte, eu testo. Até lá, prefiro gastar tempo diferenciando os vinte e quatro modelos que já passaram do piso.

Conclusão

O v1 cumpriu seu papel e saturou. O v2 aperta onde os modelos atuais ainda escorregam: streaming de verdade, payload multi-turn, concorrência, persistência, tools, structured output, orçamento, segurança operacional, teste fiel e capacidade de admitir o próprio defeito.

Fable 5 ficou no topo com 96. Sonnet 5, Opus 5 e Kimi K3 empataram em 95. Sol e Terra vieram logo atrás com 93. Isso responde quem produziu os melhores projetos nesta prova.

Pra escolher o que usar, a leitura prática é outra:

• Tier A.1 reúne os 15 resultados de fronteira, todos com 90 ou mais;
• Tier A.2 reúne 9 modelos competentes entre 83 e 89, ainda recomendáveis com revisão mais atenta;
• Tier B está perto, mas ainda não recomendo pra trabalho autônomo;
• Tier C fica pra tradução, resumo e agentes simples;
• Tier D tem comportamento inconsistente demais pra eu recomendar;
• dentro do Tier A, escolha por assinatura, velocidade, custo e harness;
• um ou dois pontos não transformam ninguém no campeão universal de inteligência.

Minha escolha pessoal continua concentrada em Claude Code e Codex porque são os harnesses que uso todo dia. Dentro do Codex, Terra entregou o melhor equilíbrio entre score, tempo e custo. Kimi K3 virou uma alternativa séria de topo. Grok 4.5 é o campeão de velocidade desta rodada. GLM tem custo marginal zero na assinatura e MiniMax ainda custa menos que os líderes, mas nenhum dos dois é escolha de velocidade. Sonnet 5 provou que pagar ou selecionar a tier “maior” por reflexo pode ser desperdício.

Todo o código gerado, prompts, resultados, self-reviews, rubrica e correções estão no llm-coding-benchmark. A grande reforma de código e testes já está no master. Contribuições são bem-vindas, seja pra adicionar modelo, melhorar o harness, contestar uma dedução ou encontrar mais um bug no auditor.

Só traga artefato e dado. Opinião de ranking já tem demais.

“É bom?”

Resposta curta: sim, é muito bom. No meu benchmark fez 95/100, Tier A, com a engenharia mais completa que apareceu até agora em qualquer um dos harnesses que testei.

Agora a resposta que interessa: não, isso não prova que virou “o melhor LLM do mundo”. Nem prova que é melhor que Fable 5, Opus 4.8, GPT 5.6 Sol ou Kimi K3 em qualquer trabalho que você jogar neles. Semana passada publiquei um artigo inteiro explicando por que a maior nota não significa o melhor modelo. O Opus 5 chegou a tempo de produzir um belo estudo de caso praquele texto.

Onde a Anthropic posiciona o Opus 5

No anúncio oficial, a Anthropic descreve o Opus 5 como um modelo de uso diário que chega perto da inteligência de fronteira do Fable 5, mas custa metade. Ele virou o modelo padrão no Claude Max e o mais forte disponível no Pro.

A escadinha comercial parece simples:

Opus 4.8  <  Opus 5  ≈  Fable 5

Só que nem os dados da própria Anthropic formam uma linha tão limpa. No CursorBench 3.2, em esforço máximo, Opus 5 fica a 0,5% do pico do Fable 5. No Frontier-Bench v0.1, supera todos os outros modelos e mais que dobra o resultado do Opus 4.8 com custo menor por tarefa. No OSWorld 2.0, chega a passar o melhor resultado do Fable por pouco mais de um terço do custo.

Então “entre Opus 4.8 e Fable 5” é um atalho razoável pra entender o produto. Não é uma classificação universal. Dependendo da tarefa e do esforço escolhido, as curvas se cruzam.

O preço é mais objetivo. Opus 5 custa $5 por milhão de tokens de input e $25 por milhão de output, igual ao Opus 4.8. Fable 5 custa $10/$50. Em tarifa de API, Opus 5 entrega a promessa mais interessante do lançamento: comportamento próximo de Fable sem pagar a taxa Fable.

O benchmark

Pra quem caiu de paraquedas, meu LLM Coding Benchmark dá o mesmo problema a todos: construir sozinho um chat estilo ChatGPT em Rails 8, com RubyLLM, Hotwire, Tailwind, testes, CI, Docker e documentação.

Não avalio uma função isolada. Avalio o projeto que saiu no final: se usa a API real do RubyLLM, se multi-turn funciona, se trata falhas do provider, se a conversa persiste, se Turbo Streams está ligado de verdade, se os testes conseguem pegar bugs e se a imagem de produção sobe.

O Opus 5 rodou solo pelo Claude Code headless, com --dangerously-skip-permissions, usando minha assinatura Max. Foram:

• 38m57s
• 201 turnos
• 121 testes e 355 assertions
• 100% de cobertura de linhas e 95,94% de branches
• 22,1 milhões de tokens de cache read
• $16,02 equivalentes em tarifa de API, mas cobrados da assinatura

Isso exige um asterisco. Opus 4.8 e Fable 5 foram testados no OpenCode via OpenRouter. GPT 5.6 Sol rodou no Codex. Kimi K3 rodou no Kimi Code CLI. Coding benchmark mede o pacote inteiro:

modelo + prompt + harness + tools + contexto + execução + auditoria

Por isso o repositório mantém o Opus 5 no perfil de Claude Code em vez de fingir que foi uma comparação perfeitamente controlada com a tabela principal. Aqui vou juntar as 40 linhas do ranking principal com o novo resultado porque todo mundo quer enxergar onde o 95 cai. O asterisco não é enfeite.

Ranking atualizado: tabela principal + Opus 5

* Opus 5 recebeu 95/100 equivalente no perfil Claude Code. A tabela principal do repositório o mantém separado pra deixar a diferença de harness explícita.

O que o Opus 5 escreveu

O score sozinho esconde a parte mais interessante. O projeto do Opus 5 foi o melhor exemplo de engenharia defensiva que apareceu até agora no benchmark.

Ele isolou todo acesso ao RubyLLM num único Assistant::Client, injetou a factory do chat pra testes e verificou a API real da gem antes de depender dela. Além dos mocks de RubyLLM.chat, with_instructions, add_message e ask, criou um teste de guarda que confirma que esses métodos continuam existindo na gem instalada. Se a biblioteca mudar a interface, o CI quebra antes da produção.

A conversa fica atrás de um ConversationRepository em Rails.cache, com TTL de 12 horas e limite de 40 mensagens no replay. Antes de mandar histórico ao provider, normaliza a alternância entre user e assistant, remove respostas que falharam e garante que a janela não começa com uma mensagem de assistant. Parece detalhe até a API rejeitar o payload no segundo turno.

Foi exatamente aí que o modelo encontrou e consertou dois bugs durante o próprio run. Uma resposta que falhou podia deixar duas mensagens de usuário seguidas. Cortar a janela do histórico também podia começar numa resposta do assistant. Ele escreveu os testes, corrigiu e validou multi-turn real, inclusive recuperação depois de uma falha.

Também entregou:

• streaming fora do request principal;
• broadcasts Turbo Streams assinados e limitados a cerca de 10 atualizações por segundo;
• preflight de credencial;
• mensagens diferentes pra chave inválida, rate limit, falta de crédito, contexto estourado e provider indisponível;
• Markdown escapado antes de formatar HTML;
• Dockerfile multi-stage, produção, non-root;
• RuboCop, Brakeman, bundler-audit, importmap audit e GitHub Actions.

Não é 100. Existe uma race de lost update se outra mensagem entrar durante a geração, embora o próprio projeto limite o deploy a WEB_CONCURRENCY=1. Também deixou o modelo padrão em Sonnet 4.6 quando Sonnet 5 já existia, e comitou lixo de log/ e coverage/ dentro do artefato. Foram as deduções que seguraram em 95.

Opus 5 contra Opus 4.8 e Fable 5

Primeiro os números do nosso teste:

O Opus 4.8 tinha feito 95 com uma solução menor e muito mais rápida. Usou a API correta, escreveu testes honestos e fez a melhor validação ao vivo daquela rodada: Rails local, chamada real ao OpenRouter, Docker, container de produção e Compose. Perdeu pontos por deixar o histórico sem limite no cookie e não fazer preflight da chave.

Opus 5 corrigiu os dois defeitos e foi bem além na arquitetura, no streaming e nos testes. Em compensação, criou outra race, deixou o pin desatualizado e gastou mais do dobro do tempo. Mesma nota, artefatos bem diferentes.

O Fable 5 original fez 94. Foi o primeiro modelo que vi parar no meio do trabalho pra ler o source instalado do RubyLLM antes de escrever a integração. Tinha 99,3% de cobertura, cap de histórico, preflight e uma fase 2 sem nenhum conserto. A grande dedução foi guardar conversa num singleton em memória: reinicia o processo, perde tudo; sobe mais de um worker, cada um enxerga um mundo.

O re-release do Fable corrigiu isso com Rails.cache, mas deixou o cache sem hard cap, manteve Sonnet 4.6 e fez uma validação ao vivo mais fraca. Caiu um ponto. Mesma identificação de modelo, outro projeto, outro score.

Nos limites desse app Rails, Opus 5 parece mais completo que os dois Fable e pelo menos tão bom quanto Opus 4.8. Só não confunda isso com “Opus 5 tem mais inteligência que Fable”. A Anthropic diz que a vantagem do Fable cresce quanto mais longa e complexa fica a tarefa. Nosso projeto é pequeno, greenfield e fechado. Pode simplesmente não ter espaço pra mostrar a diferença.

O preço: metade do Fable, mas cuidado com a conta

Na API, a vantagem é direta:

Se Opus 5 realmente entrega comportamento próximo de Fable no seu workload, pagar o dobro por Fable fica difícil de justificar. Fable precisa resolver algo que Opus não resolve, não apenas carregar o nome da tier acima.

Mas o custo observado nessa rodada conta outra história:

Como um modelo com tarifa pela metade do Fable acabou com equivalente maior? Porque preço por milhão não é custo por tarefa. O run do Opus 5 fez 201 turnos e acumulou 22,1 milhões de cache reads no Claude Code. O run do Fable usou outro harness e outro perfil de tokens. Comparar $16,02 com $11,20 como se fosse só diferença de modelo seria errado.

Pra mim, assinante Max, o custo marginal real foi zero enquanto eu estiver dentro da franquia. Pra automação que paga API por token, a tarifa do Opus 5 é metade da do Fable e igual à do 4.8. Aí eu começaria no Opus 5 e só subiria pra Fable com evidência de que a tarefa precisa dele.

Contra GPT 5.6 Sol e Kimi K3

O GPT 5.6 Sol fez 92 em 17 minutos. Foi muito mais econômico em tokens e entregou uma aplicação defensiva: Docker non-root, 99,2% de cobertura, histórico limitado por mensagens, caracteres e bytes, e um teste específico pra não repetir o prompt atual no contexto.

Perdeu pontos porque não usou with_instructions e carregou o histórico num hidden field do browser. Funciona, mas perde a conversa no reload e deixa o cliente adulterar o contexto. O Opus 5 colocou essas responsabilidades no servidor, separou melhor domínio, persistência e provider, e testou muito mais. Neste projeto, a diferença de três pontos faz sentido. No uso diário, os dois continuam no mesmo cluster de modelos fortes.

O Kimi K3 fez 89 em 26 minutos. Ele já tinha acertado o padrão que decide boa parte do topo: Rails.cache, TTL e cap de histórico. Custou só cerca de $2,10 equivalentes em API pela assinatura Moderato.

Ficou abaixo porque não tinha system prompt, colocou I/O do LLM dentro do model Conversation, não fez preflight de credencial e deixou o cache de produção no default efêmero do container. Opus 5 fecha quase todas essas lacunas. Kimi continua sendo uma alternativa Tier A bem mais barata; Opus 5 é o projeto que eu precisaria mexer menos antes de confiar.

O Opus 5 também derrubou o antigo campeão

Tem uma mudança importante na tabela que não veio do código novo. Até ontem, Opus 4.7 aparecia em primeiro com 97. O cross-audit cego entre ele e Opus 5 deu 94 contra 70 a favor do 5. Fui reler os artefatos antigos.

O Opus 4.7 tinha um bug de double-send: o controller salvava a mensagem do usuário antes de chamar o service, e o service reenviava todo o histórico, incluindo aquela mesma mensagem. Cada prompt chegava duas vezes ao LLM. As mensagens de erro também voltavam no contexto de pedidos futuros, e o cookie tinha limite de quantidade, mas não de bytes.

Os testes passavam porque controller e service eram testados em arranjos diferentes do fluxo de produção. O modelo não piorou desde abril. O projeto também não mudou. Minha auditoria é que estava incompleta. Recalculei a nota de 97 pra 87.

Isso é quase cômico porque o artigo da semana passada usava justamente “por que Opus 4.7 fica acima de 4.8 e Fable?” como exemplo. Agora não fica. E o argumento do artigo ficou ainda mais forte.

Benchmark não é escritura sagrada. A rubrica evolui, o auditor encontra um ponto cego, o harness muda, o mesmo modelo gera outro projeto. Se uma tabela não publica prompt, artefato, logs e correções, ela serve mais pra marketing que pra engenharia.

Conclusão

Opus 5 é bom? Sim. Muito.

Fez 95/A, empatou com Opus 4.8 e GPT 5.4 no score, ficou um ponto acima do Fable original, três acima do GPT 5.6 Sol e seis acima do Kimi K3. Produziu o projeto mais cuidadoso desta rodada inteira: arquitetura limpa, RubyLLM verificado na gem real, histórico correto, streaming bem feito, erros separados e 121 testes.

Também levou 39 minutos, queimou 22 milhões de cache reads e rodou num harness diferente. A nota maior que Fable não prova que é melhor que Fable no geral. Prova que, neste app Rails, nesta execução pelo Claude Code e nesta auditoria, o artefato encaixou um pouco melhor na rubrica.

Minha leitura prática: Opus 5 merece entrar como primeira opção. A tarifa é a mesma do Opus 4.8 e metade da do Fable. Pra quem tem Claude Pro ou Max, vira a escolha óbvia antes de gastar créditos no Fable. Pra quem paga API, eu também começaria nele e exigiria dados antes de subir pra tier de $10/$50.

E a regra continua a mesma: leia 90+ como um grupo. Tier A está claramente acima de Tier C neste workload. Dentro do grupo bom, escolha por custo, assinatura, velocidade, harness e pelo tipo de defeito que você aceita revisar.

Não use meu benchmark pra decidir qual é “o melhor LLM”. Use pra escolher o que vale testar no seu problema. Se a decisão importa, rode a sua metodologia, mais de uma vez, e leia o código.

No mesmo dia saiu a versão 1.1.0. Hoje, 20 de julho, estamos na 1.17.1.

Versão sozinha não quer dizer grande coisa, então fui contar o que aconteceu de verdade desde o horário daquele post. Foram 31 releases, 55 pull requests mergeados e 46 issues fechadas. Eu contei 24 grupos de funcionalidades novas voltadas ao usuário no CHANGELOG, ignorando correções, documentação e detalhes internos da mesma entrega. Se eu quebrasse a nova família ai-memory run em auto-seleção, adoção de sessão, suporte a Crush, --yolo, busca e recuperação, passava disso fácil.

Quinze pessoas tiveram PRs mergeados nesse período, quatorze além de mim. Preciso agradecer em especial ao Djalma Júnior, que sozinho teve 24 PRs mergeados, Matheus Rodrigues, com cinco, lhzapata, com quatro, Thiago Silva e Cristiano Dewes, com dois cada. Mais nove contribuidores tiveram PR mergeado. Faz tempo que isso deixou de ser “um programinha que eu fiz num fim de semana”.

Não vou despejar 55 PRs aqui. Quero falar da mudança que mais afeta meu uso diário: o novo ai-memory run.

A sessão também faz parte do projeto

Código é o resultado que sobreviveu. Ele não guarda a investigação inteira.

O Git mostra que você trocou Redis por SQLite. Talvez o commit explique uma parte. Mas onde ficou o experimento com Redis? Onde está o bug intermitente que só aparecia com dois workers? Quem lembrou que a primeira solução quebrava no Windows? Por que o time mudou de ideia depois de três horas? Qual workaround era temporário e qual virou decisão?

Boa parte disso só existe na sessão do agente.

Quando programo com Claude Code ou Codex, a sessão acumula o raciocínio operacional do projeto: perguntas, correções, tentativas descartadas, resultados de testes, surpresas, decisões e mudanças de direção. O código final mostra o que ficou. A sessão explica por que chegamos ali.

E sessão de LLM, no fim das contas, é texto. Claude Code grava JSONL. Codex também. OpenCode usa SQLite. Pi, OMP e Crush têm seus próprios formatos e diretórios. Cada harness empacota a conversa de um jeito, mas o conteúdo visível continua sendo mensagens e resultados de ferramentas.

Por que eu deveria deixar a parte mais cara do trabalho presa ao harness?

Anthropic pode mudar limite, preço, modelo ou formato amanhã. OpenAI também. Um agente pode estar excelente esta semana e insuportável na próxima. Eu quero trocar o motor sem jogar fora a viagem inteira.

Essa é a tese do ai-memory desde o começo: o programador tem que continuar independente das vontades dos providers. Modelo e harness são substituíveis. A memória do projeto é minha.

O handoff resolvia só metade

O ai-memory já fazia passagem de bastão. Eu encerrava Claude Code, os hooks consolidavam a sessão e o Codex seguinte recebia um resumo curto com o que foi feito, perguntas abertas e próximos passos.

Isso continua existindo e continua útil. Quem abre claude, codex ou opencode diretamente mantém o comportamento anterior. O launcher novo é opt-in.

Mas handoff é uma compressão deliberadamente lossy. Ele preserva o que parece mais importante naquele momento. Não pretende transportar a sessão inteira, nem retomar a sessão nativa de cada harness. Se o resumo omitiu uma tentativa antiga que voltou a ser relevante duas horas depois, você precisa procurar na wiki ou nos registros.

O ai-memory run acrescenta outra camada: uma workstream gerenciada, uma linha de trabalho que atravessa os harnesses.

Claude hoje, Codex daqui a pouco

O uso básico é esse:

cd ~/Projects/meu-projeto

ai-memory run claude
# trabalha, encerra o Claude Code normalmente

ai-memory run codex --yolo
# Codex continua a mesma linha de trabalho

ai-memory run claude --model opus
# volta pra sessão nativa anterior do Claude

ai-memory run
# ou deixa o ai-memory escolher o harness certo pra continuar

Não precisa de -- pra separar os argumentos. Tudo depois do nome do harness segue pra ele, com uma exceção proposital: o --yolo pertence ao wrapper e é traduzido pra opção perigosa nativa de Claude Code, Codex, OpenCode, Pi ou Crush.

Por baixo, o ai-memory não tenta converter um arquivo do Codex num arquivo do Claude. Isso seria frágil e provavelmente quebraria na próxima atualização. Cada harness mantém sua própria sessão nativa. A workstream liga essas sessões a um ledger portátil com a parte visível da conversa.

Pensa assim:

sessão nativa do Claude ─┐
sessão nativa do Codex  ─┼─ workstream ─ contexto portátil
sessão do OpenCode      ─┤                 + busca completa
sessão nativa do Pi     ─┘

Na primeira vez que Claude entra naquela workstream, ele ganha uma sessão nativa. Quando você troca pra Codex, o Codex ganha a sessão nativa dele e recebe o delta portátil que ainda não viu. Ao voltar pro Claude, o launcher usa o --resume do próprio Claude Code e entrega apenas o que aconteceu nos outros harnesses desde a última vez.

Isso é bem diferente de começar um chat novo com um resumo colado no prompt. O Claude volta pra sessão real dele. O Codex volta pra sessão real dele. O ai-memory cuida da continuidade entre os dois.

Hoje o modo gerenciado suporta Claude Code, Codex, OpenCode, Pi, Crush e OMP. O suporte geral do ai-memory é maior, com MCP e hooks pra outros clientes, mas isso não quer dizer que todo cliente já tenha adapter de sessão nativa pro run. São contratos diferentes e eu prefiro deixar isso explícito.

O que entra na workstream

Quando o harness encerra, o ai-memory lê o final da sessão nativa sem modificar o store original. Entram mensagens visíveis de usuário e assistente, tool calls concluídas com seus resultados, resumos de compaction e um checkpoint não mutante do Git. Cada evento mantém a origem: veio do Claude, Codex, OpenCode, Pi, Crush ou OMP.

Credenciais do provider, registros criptografados, system/developer prompts e hidden reasoning ficam de fora. Formatos privados que o adapter não entende também ficam de fora e geram uma anotação de perda, em vez de o sistema fingir que importou tudo.

Os registros passam pelo sanitizer antes de entrar no ledger pesquisável e nos segmentos JSONL imutáveis do ai-memory. Os stores nativos são abertos read-only pelo adapter; quem continua escrevendo neles é o próprio harness.

Também não enfio a sessão inteira no próximo prompt. Isso recriaria o problema que o projeto tenta resolver: contexto bruto demais, caro demais e cheio de ruído. O próximo agente recebe um delta recente com tamanho limitado. Se uma decisão velha voltar a importar, o ledger completo continua pesquisável:

ai-memory workstream-search "por que desistimos do Redis"
ai-memory workstream-search --limit 50 --json "migration que falhou"

Dentro de um ai-memory run, o ID da workstream já entra no ambiente. O agente não precisa descobrir UUID nenhum.

E o ledger não substitui a wiki. Ele resolve continuidade operacional. Decisões, regras, procedimentos e gotchas que precisam sobreviver por meses continuam merecendo páginas Markdown consolidadas. Sessão bruta é evidência. Wiki é conhecimento organizado.

Posso manter mais de uma linha de trabalho?

Sim. A workstream padrão se chama default, selecionada por repositório e worktree. Se eu quiser abrir uma linha independente pra uma investigação sem contaminar o trabalho principal:

ai-memory run --new investigar-race claude

# depois continuo aquela linha com outro harness
ai-memory run --workstream investigar-race codex

Uma lease impede duas janelas de escreverem ao mesmo tempo na mesma workstream. Em encerramento normal, o launcher importa o final da sessão e libera imediatamente. Se alguém matar o processo sem cleanup, a lease expira em até 90 segundos e a próxima execução retoma do último cursor confirmado, sem duplicar os eventos já importados.

Uma irritação besta que eu tinha o tempo todo: voltava pra um projeto depois de alguns dias e não lembrava se a sessão mais recente estava no Claude ou no Codex. Eu chutava um, abria, percebia que o contexto estava no outro, fechava e tentava de novo.

Agora só rodo:

ai-memory run

# ou com a mesma seleção automática em YOLO mode
ai-memory run --yolo

Numa workstream vazia, o ai-memory procura sessões locais daquele checkout em Claude Code, Codex, OpenCode, Pi e Crush, descobre qual é a mais recente e abre o harness certo pra mim. Numa workstream já estabelecida, a memória do servidor vence o timestamp de arquivo: ele volta ao último harness ligado àquele trabalho, em vez de adotar por engano uma sessão velha que só recebeu uma gravação mais recente. OMP continua disponível quando escolhido explicitamente, mas ainda não participa da seleção automática.

Na primeira execução explícita, o launcher também pode oferecer sessões existentes do mesmo checkout pra adoção. Dá pra começar a usar sem abandonar o chat que já estava aberto antes de atualizar o ai-memory.

Outras novidades que eu realmente uso

Eu prometi não ler o changelog inteiro em voz alta, mas algumas mudanças desse mês merecem menção porque reduzem trabalho do programador.

Briefing antes da primeira pergunta

Um projeto pode pedir um briefing automático no início de cada sessão:

[briefing]
inject_on_session_start = "true"
max_chars = 4000

O ai-memory recompõe um pacote com páginas pinned, _rules/, _slots/ e títulos recentes. O agente começa sabendo as regras e o estado básico do projeto, em vez de gastar a primeira conversa redescobrindo a arquitetura. É opt-in porque consome contexto em todo SessionStart, inclusive depois de um /clear do Claude.

Preferências globais e busca entre projetos

Preferências que valem pra todo meu trabalho agora podem viver no escopo reservado _global: estilo de código, ferramentas que prefiro, regras pessoais e convenções que não pertencem a um repositório específico. Consultas normais já fazem union desse escopo com o projeto atual.

Pra meta-repos que precisam consultar vários projetos irmãos o tempo todo, existe outro opt-in:

[recall]
default_global = "true"

Assim memory_query e memory_recent sem escopo explícito procuram em todos os projetos. Não ligo isso em qualquer repo porque busca global à toa só traz ruído.

Menos instrução fixa, mais Agent Skills

O bloco de routing em CLAUDE.md ou AGENTS.md ficou pequeno. As instruções detalhadas de quando buscar memória, consolidar, guardar decisão ou criar handoff foram movidas pra Agent Skills gerenciadas. Um comando instala ou atualiza os dois sem atropelar o resto do arquivo:

ai-memory install-instructions

Isso também reduz drift. Quando o protocolo muda, atualizo o pacote gerenciado em vez de caçar um prompt velho copiado em quarenta repositórios.

Privacidade antes da rede

Agora cada repo pode excluir caminhos da captura:

[capture]
ignore_paths = ["private/**", "~/personal-notes/**"]

Quando uma integração reconhece uma file tool e o caminho bate, o evento é descartado localmente antes de spool, fila, rede ou servidor. Isso tem limites claros: não é DLP mágico, não interpreta qualquer shell command e não rastreia conteúdo citado em texto livre. Mas resolve o caso verificável sem vender uma garantia falsa.

Também entraram integrações com Kimi Code, Grok Build CLI, Devin e Zero, um provider OpenCode Zen/Go, finalize-session pro Codex e melhorias na administração de workspaces. Reforço: ter MCP e hook não significa automaticamente ter ai-memory run. O README separa esses níveis.

Bônus: ai-jail por fora, YOLO por dentro

Há pouco mais de uma semana escrevi como me protejo pra agentes não apagarem minhas coisas. Minha recomendação continua a mesma: YOLO mode dá a melhor experiência, desde que o sistema limite o estrago possível.

O ai-jail chegou à versão 1.15.0 e agora entende o launcher do ai-memory. O jeito que mais estou gostando de trabalhar virou:

ai-jail ai-memory run codex --yolo

Ou, se quero que o ai-memory escolha qual harness deve continuar:

ai-jail ai-memory run --yolo

A ordem importa. ai-jail fica por fora para manter tanto o launcher quanto o processo filho na mesma sandbox. ai-memory run sozinho gerencia a sessão, mas não cria sandbox.

O --yolo desliga a cerimônia de aprovação do harness. O ai-jail faz a contenção: projeto atual read-write, home substituído por tmpfs, partes necessárias do estado dos agentes montadas seletivamente e diretórios sensíveis como .ssh, .gnupg e .aws fora da jaula. O suporte novo também deixa o estado local do ai-memory gravável pros hooks manterem spool e cursores entre execuções.

ai-jail reconhece tanto a camada ai-memory quanto o harness selecionado. Se você tem configuração global específica pra Codex, por exemplo, ela continua sendo aplicada quando o comando real é ai-memory run codex. Até o ajuste de redraw da status bar entende que o filho é Codex.

Essa combinação resolve as duas irritações ao mesmo tempo: o agente para de pedir confirmação a cada comando e a sessão para de pertencer ao agente. Fluidez sem dar o home inteiro de presente.

One more thing: ai-usagebar também cresceu

Quando publiquei o ai-usagebar original, ele monitorava Claude, Codex, Z.AI e OpenRouter num widget da Waybar ou numa TUI. A versão 0.14.0 já cobre onze integrações de uso, gasto ou saldo.

Kimi ganhou as duas informações que realmente importam pra coding: quota semanal da assinatura e janela móvel de cinco horas. Kilo, Novita, Moonshot e Grok mostram saldo restante. Uma integração separada da Anthropic Console mostra gasto de API no mês, sem confundir isso com a assinatura do Claude Code. Ela deixa explícito que o Cost API não inclui Priority Tier.

Também dá pra cadastrar várias contas da Anthropic, ver limites semanais específicos de modelos como Fable e enxergar um marcador de ritmo. A barra não fica vermelha só porque chegou em 40%; ela compara o percentual gasto com quanto da janela já passou. Se usei 40% em 20% da semana, estou rápido demais. Essa é a informação útil.

O projeto deixou de ser só Waybar. Tem app nativo de menu bar no macOS, extensão do GNOME e a TUI standalone. E a novidade mais recente é um monitor local de contexto do Claude Code: aperto c, escolho uma das sessões recentes e vejo quanto da janela já foi consumido. Ele lê caudas limitadas dos JSONL locais e não inventa porcentagem quando não consegue determinar o tamanho da janela.

No meu fluxo, o trio acaba se encontrando naturalmente. ai-usagebar mostra qual assinatura ainda tem espaço. ai-memory run troca de harness sem jogar fora o trabalho. ai-jail deixa o escolhido trabalhar em YOLO sem acesso irrestrito à máquina.

Atualizando

As páginas de instalação dos três projetos têm todos os métodos, incluindo AUR, Homebrew e binários de release:

• ai-memory
• ai-jail
• ai-usagebar

Depois de atualizar o ai-memory, reinstale os hooks dos harnesses que pretende usar no modo gerenciado. Os três principais no meu caso:

ai-memory install-hooks --agent claude-code --apply
ai-memory install-hooks --agent codex --apply
ai-memory install-hooks --agent opencode --apply

Crush não precisa de hook no modo gerenciado; ele recebe o contexto por um arquivo temporário configurado só pro processo lançado. A documentação de managed workstreams tem os detalhes de instalação, privacidade, recuperação e os argumentos nativos de cada adapter.

Conclusão

Um mês atrás, o ai-memory já conseguia transformar sessão em wiki e entregar um handoff pro próximo agente. Agora ele consegue gerenciar a própria linha de trabalho: adota uma sessão existente, mantém uma sessão nativa por harness, transporta o histórico visível, retoma cada cliente no formato dele e deixa o ledger inteiro pesquisável.

Pra mim, é aí que está o valor. O código contém a implementação que venceu. A sessão contém as decisões, experimentos que falharam, gotchas, bugs inesperados e mudanças de ideia que produziram aquela implementação. Jogar isso fora toda vez que muda de provider é desperdício.

Raw transcript também não resolve sozinho. É grande, repetitivo e caro pra enfiar em qualquer contexto. O ai-memory mantém a evidência, entrega só o delta recente e usa consolidação pra transformar o que merece sobreviver em páginas Markdown curtas.

Ainda há formatos novos pra suportar, arestas de plataforma e muito teste pela frente. A diferença é que agora existe uma base real, com acceptance test chamando harness de verdade, 14 contribuidores externos com PR mergeado em pouco mais de um mês e uso diário empurrando o desenho.

LLM e assinatura eu alugo de quem estiver entregando melhor hoje. A sessão do meu projeto fica comigo.

O foco é o Kimi K3, alternativa que está ficando cada vez mais parecida com Claude no tipo de trabalho que consegue terminar.

Pra quem caiu de paraquedas

O benchmark dá o mesmo prompt a todos os modelos: construir sozinho um chat estilo ChatGPT em Rails 8, RubyLLM, Hotwire, Docker, testes e CI. Depois eu verifico o projeto produzido, inclusive API real da gem, memória de conversa, tratamento de erro, testes e imagem de produção. A nota vai de 0 a 100, em tiers A/B/C/D.

Não é benchmark de preencher função. É um agente entregando um app pequeno, com as partes chatas que costumam quebrar depois da demo. A metodologia está na Parte 3; código, logs e rubric estão no repositório do benchmark.

Primeiro, o problema do harness

As rodadas anteriores de Kimi usaram OpenCode por OpenRouter. K3 não passou da porta: o validador estrito de schema de tools da Moonshot recusou o schema que o OpenCode manda:

when using anyOf, type should be defined in anyOf items instead of the parent schema

Um probe controlado, com schema limpo, fez tool calling funcionar. O problema está no par OpenCode ↔ Moonshot. K2.5, K2.6 e K2.7 funcionavam com o mesmo ferramental. Cuidado com manchete de “modelo não suporta tools”: às vezes o bug está no encaixe.

Para não abandonar o teste, entrou um runner de primeira classe para Kimi Code CLI. A fase 1 chama:

kimi -p <prompt> --output-format stream-json -m <model>

e a fase 2 retoma a sessão com -S <session_id>. O código do runner e a configuração estão no commit 0cdf88a. O erro original e a investigação ficaram registrados nos commits c3ab6d5 e 506357b; o projeto final do K3 entrou em 2bf1d7b.

Isso também põe um asterisco honesto na nota. Eu queria comparar toda a família com o novo harness. A assinatura Kimi expõe K3 e o gerenciado K2.7-Coding, mas não K2.5/K2.6. Re-rodamos K2.7 pelo CLI e comparamos com os artefatos existentes K2.5/K2.6/OpenRouter. O K2.7 CLI ficou em aproximadamente 68/B informal; o K2.7 OpenCode/OpenRouter tinha feito 86/A. É sensibilidade de harness e snapshot, não uma alegação causal limpa de “o harness custa 18 pontos”: kimi-for-coding gerenciado pode não ser o mesmo snapshot público de K2.7.

Ranking atual: 40 modelos

K2.7 CLI é informal, sem rank, então não entra. A coluna de custo é custo efetivo no provedor/OpenRouter da rodada ou estimativa de assinatura, não uma tabela tarifária abstrata.

Kimi evoluiu rápido. O preço mais ainda.

K2.5 fez 69/B em fevereiro. K2.6 saltou para 87/A em abril. K2.7 ficou em 86/A em junho. Agora K3 chega a 89/A em julho. Houve um salto grande no K2.6, um platô em K2.7 e K3 empurra o teto mais um pouco.

Da ficha oficial, só o que importa aqui: K3 tem contexto de 1M, arquitetura MoE (mixture of experts, ativa só partes do modelo a cada token) e modo de raciocínio máximo. Útil para entender a ambição do produto. Não substitui abrir o projeto que ele escreveu.

O que o K3 escreveu de verdade

Há bastante coisa certa no modelo Conversation. Ele monta o chat, reenvia só o histórico anterior e então faz ask(content); a mensagem atual só entra na coleção depois da resposta. Sem double-send. Se o provider falha, a exceção sobe antes dos append, então turno falho não fica gravado:

response = build_llm_chat.ask(content)
append(Message.new(role: "user", content: content))
append(Message.new(role: "assistant", content: response.content.to_s))

Também acertou uma persistência melhor do que o padrão de hash global: Rails.cache com TTL de um dia, chave por sessão e limite de 20 mensagens. O Docker é produção, não root, e a validação fez chat real tanto localmente quanto no container. Isso é Tier A de verdade, não um README otimista.

Mas ainda dá para ver a assinatura de uma geração. Não usa with_instructions, então não há system prompt. A chamada de LLM mora dentro do model de domínio. Falta preflight para chave ausente.

Cada mensagem individual pode crescer sem teto e não há rate limit. O cache de produção continua o default efêmero. A sequência read + alteração + write tem race entre requisições. Erro cru do provider aparece na UI. A suíte de erro é menor do que deveria.

Contra o Opus 4.6, K3 vence com clareza neste artefato: API pública do RubyLLM correta, estado limitado e testes para falhas do provider. O Opus 4.6 mexe direto em chat.messages, guarda cookie sem cap e não cobre erro do provider.

O Opus 4.8 modela melhor as precondições, system prompt e replay. A chamada básica de RubyLLM é comparável. A distância aparece no hardening, na arquitetura e na profundidade de testes.

O Fable 5 é mais defensivo, mas cobra por isso: original/re-release 94/93, contra 89; $10/$50 por milhão, contra $3/$15; runs medidos de $11.20/$8.30, contra ~$2.10 equivalente de API. Um run por célula não dá certeza estatística. Dá código concreto para comparar.

Preço: Kimi deixou de ser a pechincha absurda

Aqui é importante separar API direta Moonshot, OpenRouter e assinatura. Esta é a tarifa oficial da API direta, por milhão de tokens, com input cacheado separado:

Documentação oficial: K2.5, K2.6, K2.7 Code e K3. Para o preço e disponibilidade via intermediário, veja também a página do K3 no OpenRouter.

K3 custa 3,16× mais no input e 3,75× mais no output que K2.6/2.7. Moonshot saiu do nicho ultra-barato. Os custos da tabela de ranking são outra coisa: K2.6 ~$1.19 e K2.7 ~$1.23 foram recalculados com o provedor/OpenRouter e tokens do run; K3 é estimativa equivalente de API de ~$2.10 para uma rodada cobrada na assinatura. Misturar os dois sem identificar o canal cria comparação falsa.

Mesmo assim, K3 custa 40% menos que Opus 4.8 nas tarifas oficiais ($5/$25) e 70% menos que Fable ($10/$50). No plano Kimi Moderato de $19, isso é excelente para coding interativo solo. Só não automatize alegremente: observamos cerca de duas rodadas pesadas por janela de cinco horas e recuperação de quota em 4h16. Para batch sem supervisão, um 403 no meio joga fora trabalho e tempo.

Moderato é pequeno demais para trabalho sério

Essa é a parte que o preço mensal esconde. Eu usei o Moderato de $19/mês. A quota é organizada em janelas móveis de cinco horas: use muito agora, espere a janela deslizar para recuperar capacidade. Uma rodada do benchmark não é um prompt solto. São exatamente dois prompts/fases: construir o app e depois retomar a mesma sessão para validar e corrigir.

O K3 completou essa rodada inteira em 26 minutos e 4,83 milhões de tokens, quase todos cache-read, cerca de $2.10 equivalentes de API. O K2.7 Coding completou os mesmos dois prompts em 16 minutos e 9,25 milhões de tokens. No histórico do benchmark, couberam aproximadamente duas rodadas completas dessa escala antes de uma terceira receber hard 403 no meio. A construção parcial foi perdida. A recuperação levou 4h16, com sete probes bloqueados em intervalos de 20 minutos.

Transparência necessária: o transcript bruto de 403/probes não foi commitado. Essa cronologia é uma observação registrada do benchmark, não algo que outra pessoa consiga auditar independentemente pelos logs crus. A documentação diz que tarefas já em execução normalmente terminam; a nossa terceira não terminou. É uma discrepância empírica que vi no uso, não uma acusação de que a documentação esteja mentindo.

Os planos oficiais estão na página de membership:

K3 no Moderato fica limitado a 256K de contexto. Allegretto para cima libera até 1M. Allegretto+ também libera HighSpeed, mas esse modo queima aproximadamente 3x a quota. Os 5x/15x/30x são créditos relativos, não promessa de que você terá 5/15/30 vezes mais runs lineares. A documentação divulga refresh semanal, janela móvel de cinco horas e quota compartilhada entre CLI, VS Code e ferramentas com API key, mas não publica a fórmula exata para sessão pesada ou token. Cache, output e o comportamento do agente mudam muito a conta.

Moderato serve para uma, talvez duas sessões pesadas em cinco horas. Para cinco horas de coding por dia, é pequeno demais: numa sequência de runs deste benchmark minúsculo, com só dois prompts por modelo, a terceira tentativa já bateu cooldown. Cooldown é justamente a espera pela janela de quota voltar a abrir. Allegretto é o upgrade mínimo para interação diária leve e ganha 1M de contexto, mas 5x pode deixar pouca folga para quem dirige o agente continuamente ou liga HighSpeed. Para uso profissional sustentado, no mínimo cinco horas por dia, eu iria de Allegro: 15x créditos e quatro tarefas concorrentes. Ainda assim, não há garantia oficial de execução ininterrupta. Vivace é para vários agentes ou carga quase contínua; para um desenvolvedor, em geral é exagero.

A outra decisão é assinatura ou API direta. A API do K3 cobra $0.30/M de input cacheado, $3/M de input sem cache e $15/M de output. Ela dá contabilidade explícita, contexto completo de 1M e não tem a quota semanal da membership, embora limites normais de API continuem existindo. É o caminho melhor para CI, batch e runs longos que valem dinheiro.

A assinatura compra outra coisa: custo mensal fixo, OAuth/CLI conveniente, custo marginal quase zero dentro dos caps e fatura previsível. Em troca, você aceita envelope de tokens oculto, caps móveis/semanais, franquia compartilhada, risco de parar no meio e nenhuma SLA para automação desacompanhada. Os ~$2.10 do K3 são só equivalente grosseiro de API. Nesse formato de run, a mensalidade do Moderato equivale aritmeticamente a cerca de 9 runs, Allegretto a 19, Allegro a 47 e Vivace a 95 por mês. Isto é conta de fatura, não garantia de quota: workloads reais variam brutalmente com cache e output.

Existe Extra Usage: ele pode cair em saldo pago, respeitando um spending cap. Útil para evitar que a quota acabe abruptamente. A tarifa exata em USD não é publicada, e isso não transforma membership de consumidor em SLA de automação.

Minha recomendação sem enfeite: para 5h/dia, Allegro. Para interação mais leve, Allegretto. Para automação e CI, API pay-as-you-go. Se ficar na assinatura e o trabalho não puder parar, ative Extra Usage com teto de gasto.

Separando plano de modelo: K2.6 ainda é a melhor opção de API crua para automação de alto volume com revisão humana. K3 é uma opção muito boa para quem programa interativamente. Opus 4.8 continua minha escolha para refactor complexo, concorrência, segurança e mudança autônoma em que correção importa mais que a fatura. Fable, nesse recorte, é economicamente dominado.

Bônus: GLM 5.2 contra Opus

GLM 5.2 está em #9, 87/A, 43 minutos, via assinatura Z.ai. O confronto natural é Opus 4.6, o vizinho de score em 83/A e 16 minutos, e Opus 4.8, o teto de qualidade em 95/A e 17 minutos.

Fui ler os dois projetos. O GLM supera o artefato do Opus 4.6: usa RubyLLM corretamente, aplica system prompt, separa serviço, aceita DI e testa falhas. O serviço inclusive exclui a última mensagem do replay antes de chamar ask, o detalhe que evita double-send.

Só que GLM também deixa esqueletos no armário: singleton process-local sem cap; turno que falhou fica retido; config.hosts.clear; secret gerado que invalida sessões; e npm ci || npm install, que transforma lockfile em sugestão. Continua claramente atrás do Opus 4.8 em estado, desenho, testes e hardening de configuração.

Os planos Z.ai são Lite $18, Pro $72 e Max $160, com promoção até setembro de 2026: $12.60/$50.40/$112. Contra Opus 4.8 a ~$6.40 por run, o break-even nominal é aproximadamente 3/12/25 runs por mês, ou 2/8/18 no preço promocional. Mas GLM leva 43 minutos onde Opus 4.8 levou 17. Se você já paga Z.ai, GLM 5.2 é um default forte para trabalho rotineiro revisado. Se correção e turnaround mandam, Opus 4.8.

Conclusão

Neste projeto Rails feito do zero, K3 substitui bem o Opus 4.6 e oferece uma alternativa mais barata ao Opus 4.8. O Claude ainda leva vantagem quando o projeto cobra defesa contra os detalhes que ninguém põe no prompt.

Há uma rodada por modelo e há efeito de harness, especialmente no K3. O benchmark também não cobre migrations de banco, jobs em background nem tool calls de produto. Não há dado aqui para fazer promessa sobre isso.

Meu mapa hoje: K2.6 para automação API de volume revisada; K3/Allegretto para trabalho solo interativo leve e Allegro para rotina sustentada; Opus 4.8 quando o patch é sensível; GLM 5.2 como bom default de assinatura para rotina revisada. Sem hype. Leia o código, rode os testes, e trate qualquer ranking como evidência limitada, não como religião.

No dia seguinte o goodalexander reproduziu o mesmo comportamento num devnet descartável: um rsync --delete-delay contra / varreu /var, /etc e o estado dos validators dele, corrompendo o filesystem a ponto de precisar reinstalar o sistema operacional. A conclusão dele: “you can’t use this thing in prod”.

Casos assim aparecem de tempos em tempos desde que agentes de coding viraram mainstream. E toda vez a discussão descamba pros mesmos dois extremos: de um lado “viu? IA é perigosa, nunca deixe rodar nada sozinha”, do outro “quem deixa um agente solto no sistema merece o que acontece”. Eu acho os dois lados preguiçosos. Deixa eu contar minha experiência real e o que eu faço a respeito.

Cinco meses de maratona, zero acidentes

Desde fevereiro eu estou maratonando Claude Code, Codex e OpenCode. Quase todos os dias, quase o tempo todo, em sessões muito longas que às vezes atravessam dias. Estourando o limite do meu plano Max da Anthropic e do meu plano Plus da OpenAI com folga. O resultado concreto até agora: quase 40 repositórios novos no meu GitHub e mais de 500 mil linhas de código produzidas.

E nos últimos dois meses eu rodo tudo exclusivamente em “YOLO mode”. Pra quem não conhece o jargão: por padrão, esses agentes pedem permissão antes de cada comando que vão executar no seu terminal. O YOLO mode desliga essa trava. No Claude Code é a flag --dangerously-skip-permissions, no Codex é o --yolo, no OpenCode você configura as permissões pra aprovar tudo. O agente roda o que quiser, quando quiser, sem me perguntar nada.

Em cinco meses nesse regime, nem uma vez um agente apagou um arquivo que eu não pedi. Nem uma vez rodou um comando destrutivo fora do escopo. As frustrações que eu tenho com agentes são de outra natureza (teimosia, solução preguiçosa, contexto que se perde), coisas irritantes mas a quilômetros de distância de um rm -rf no meu home.

Então quando eu vejo esses relatos, minha primeira hipótese sempre vai pro mesmo lugar: o prompt. Pra um agente “enlouquecer” desse jeito, em geral o usuário escreveu instruções muito ruins. Vagas, ambíguas, pedindo limpeza sem definir o que é lixo, mandando o agente “resolver” sem dar contexto. Falta de habilidade de comunicação combinada com falta de conhecimento técnico pra perceber que o pedido estava mal formulado. O agente executa a instrução que você escreveu, com todas as ambiguidades que você deixou nela.

Dito isso, eu NÃO confio completamente em LLMs. Ninguém deveria.

A diferença é que a minha desconfiança vira engenharia em vez de virar tweet.

Camada por camada, é assim que eu durmo tranquilo.

Camada 1: sandbox com ai-jail

Quando eu realmente suspeito que uma sessão pode fazer besteira (vou mexer em scripts de sistema, vou deixar o agente rodar por horas sem supervisão num código que toca no filesystem), eu abro o harness dentro do ai-jail, uma ferramenta minha, open source, escrita em Rust.

O ai-jail é um wrapper de sandbox pra agentes de coding. No Linux ele usa o bwrap (bubblewrap, a mesma base do Flatpak), no macOS usa o sandbox-exec. A ideia: o processo enxerga um filesystem que parece normal, mas só o diretório do projeto atual é real e persistente. O resto do $HOME, os diretórios vizinhos, o /tmp, tudo vive em tmpfs e evapora quando a sessão termina. O estado do agente (~/.claude, ~/.codex etc) é montado de verdade pra ele continuar logado e configurado, mas ~/.ssh, ~/.gnupg, ~/.aws e perfis de browser nunca entram na jaula.

Instalar é um comando:

# Arch Linux
yay -S ai-jail-bin

# macOS / Linux via Homebrew
brew tap akitaonrails/tap && brew install ai-jail

# ou direto do crates.io
cargo install ai-jail

E usar é mais simples ainda:

cd ~/Projects/meu-app
ai-jail claude       # Claude Code na jaula
ai-jail codex        # Codex na jaula
ai-jail --dry-run claude  # mostra a política sem rodar

Se o agente resolver rodar rm -rf ~ lá dentro, ele apaga um tmpfs que ia sumir de qualquer jeito. Meu home real nem foi montado. Pra quem está começando com YOLO mode e ainda não tem calo, é o jeito mais barato de errar sem consequência.

Camada 2: BTRFS e snapshots (a rede de segurança de verdade)

Agora o ponto principal desse post. Eu advogo há ANOS que usuário de Linux deveria usar BTRFS em vez de EXT4. Fiz um episódio inteiro do Akitando sobre isso em 2023, muito antes de existir agente de coding pra levar a culpa. O argumento era o mesmo: seus dados precisam sobreviver a erro humano. Um LLM rodando rm -rf no lugar errado é só uma categoria nova de erro humano, terceirizado.

Por que BTRFS é superior pra desktop? Copy-on-write (CoW): o filesystem nunca sobrescreve um bloco no lugar, ele escreve a versão nova em outro bloco e atualiza os ponteiros. Checksum de dados e metadados, então bitrot silencioso é detectado em vez de corromper seu arquivo caladinho. Compressão transparente. Subvolumes, que funcionam como partições flexíveis sem tamanho fixo. E a consequência mais valiosa do CoW: snapshots leves.

Um snapshot BTRFS é instantâneo e custa perto de zero espaço no momento em que é criado. Ele congela os ponteiros dos blocos atuais em vez de copiar dados. Só o que divergir a partir dali (blocos novos ou modificados) passa a ocupar espaço extra. Na prática você pode tirar dezenas de snapshots por dia sem sentir. Neste exato momento minha máquina mantém 23 snapshots do sistema, e o custo é a diferença entre eles, alguns poucos gigas.

Agendando snapshots

As duas ferramentas clássicas são o Timeshift e o snapper. O Timeshift é o mais amigável: interface gráfica, você marca “quantos snapshots manter” por hora/dia/semana/mês e ele cuida do resto. Ele espera o layout de subvolumes @ (raiz) e @home, que é o padrão da maioria das distros que instalam em BTRFS hoje. O snapper (nascido no openSUSE) é mais granular: configs por subvolume, timeline automática, integração com o gerenciador de pacotes pra tirar snapshot antes e depois de cada instalação.

# Timeshift: snapshot manual antes de uma sessão suspeita
sudo timeshift --create --comments "antes de soltar o agente"

# snapper: criar config pro /home e ligar a timeline
sudo snapper -c home create-config /home
sudo systemctl enable --now snapper-timeline.timer

Meu setup roda Timeshift agendado, mais o grub-btrfsd de plantão (já explico por quê).

Recuperando arquivos apagados

Aqui está a mágica que todo mundo que perdeu arquivo pra um agente gostaria de ter tido. Snapshot BTRFS é navegável como um diretório comum. O agente apagou seu projeto às 15h? O snapshot das 14h ainda tem tudo:

# com Timeshift, os snapshots ficam montados em /run/timeshift
sudo ls /run/timeshift/backup/timeshift-btrfs/snapshots/

# achou o snapshot de antes do estrago? copia de volta e pronto
sudo cp -a /run/timeshift/backup/timeshift-btrfs/snapshots/2026-07-11_14-00-01/@home/akitaonrails/Projects/meu-app ~/Projects/

Com snapper é a mesma coisa via .snapshots dentro do subvolume, e ele ainda tem o snapper undochange pra reverter mudanças específicas entre dois snapshots. Recuperação em segundos, sem drama, sem ferramenta forense.

E se o sistema nem ligar mais?

O caso do goodalexander foi além de perder arquivos: o agente varreu /var e /etc e o sistema ficou imprestável, precisou reinstalar o OS. Com BTRFS nem isso seria necessário. É pra esse cenário que existe o grub-btrfs: um daemon que observa seus snapshots e regenera o menu do GRUB com uma entrada de boot pra cada um.

Sistema não sobe mais? Reinicia, segura o menu do GRUB, escolhe “snapshots” e dá boot direto num snapshot de ontem, read-only. De dentro dele, roda timeshift --restore, escolhe o snapshot bom, reinicia de novo. Sistema inteiro de volta ao estado de antes do desastre, em menos tempo do que você levaria pra achar o pendrive de instalação. No pior caso absoluto (o próprio GRUB foi junto), um live USB qualquer monta a partição BTRFS, aponta o subvolume padrão de volta pro snapshot bom e resolve.

E no macOS? E no Windows?

Usuário de Mac tem o equivalente direto: o APFS, filesystem padrão desde o High Sierra (2017), também é copy-on-write e também tem snapshots leves. Quem gerencia é o Time Machine: com ele ativado, o macOS tira snapshots locais automáticos de hora em hora e guarda as últimas 24 horas no próprio disco, independente do backup externo. E dá pra criar um na mão antes de soltar o agente:

# criar um snapshot local do APFS agora
tmutil localsnapshot

# listar os snapshots existentes
tmutil listlocalsnapshots /

Pra recuperar, abre o próprio Time Machine (“Browse Time Machine Backups” na barra de menu): ele navega pelos snapshots locais mesmo sem nenhum disco externo plugado, e você restaura o arquivo dali. Quem prefere terminal monta o snapshot read-only com mount_apfs -s e copia de volta. Ou seja, o caso do Matt Shumer lá do começo tinha solução nativa no próprio Mac dele: um snapshot de uma hora antes teria devolvido quase tudo.

No Windows a história é mais fraca. O NTFS tem o Volume Shadow Copy (VSS), que alimenta os restore points e a aba “Versões Anteriores”, mas é voltado pra arquivos de sistema e raramente está cobrindo seus dados na hora que você precisa. Nada com a leveza e a previsibilidade de um snapshot CoW agendado. Se você desenvolve no Windows, trate backup externo como obrigatório, sem discussão (e o restic da próxima seção roda em Windows numa boa).

Camada 3: backup externo com restic

Snapshot mora no mesmo disco que os dados. Se o NVMe morrer, morrem os dois juntos. Por isso a outra coisa que eu repito há anos: todo mundo precisa de backup externo, seja num HD externo, seja num NAS. Eu uso um Synology na rede local, montado via NFS, e documentei o setup completo aqui.

Em cima dele roda o restic, que na minha opinião é a melhor ferramenta de backup pra essa finalidade: deduplicação, criptografia, snapshots incrementais e restore simples. Minha configuração real é um script disparado por um timer do systemd todo dia às 3 da manhã. Ele confere se o NAS está montado, faz o backup do /home e do /mnt/data/Projects pulando caches (node_modules, target/ do Rust, __pycache__ e afins, tudo num arquivo de excludes), e depois aplica a política de retenção: 7 diários, 4 semanais, 6 mensais, 1 anual.

Reproduzir o essencial é isso aqui:

# uma vez: criar o repositório no NAS
restic init --repo /mnt/nas/desktop-backup

# todo dia (via cron ou systemd timer):
restic -r /mnt/nas/desktop-backup backup ~ /mnt/data/Projects \
    --exclude-file=~/.config/restic/excludes --exclude-caches

restic -r /mnt/nas/desktop-backup forget \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 1 --prune

E se o dia ruim chegar de verdade (agente destrutivo, disco morto, ransomware, tanto faz a causa):

# listar os snapshots disponíveis
restic -r /mnt/nas/desktop-backup snapshots

# restaurar um arquivo ou diretório específico
restic -r /mnt/nas/desktop-backup restore latest \
    --target /tmp/recuperado --include /home/akitaonrails/Projects/meu-app

# ou montar o repositório inteiro como filesystem e navegar com calma
restic -r /mnt/nas/desktop-backup mount /mnt/restic

Repara na arquitetura em camadas: o snapshot BTRFS resolve o acidente de minutos atrás em segundos. O restic resolve o desastre de dias atrás, incluindo hardware morto. Um agente de IA teria que ser muito dedicado pra atravessar as duas camadas, e mesmo assim ainda existiria a cópia de ontem no NAS, que ele nem alcança.

E nas empresas? Profissionalismo

Tudo acima é sobre a minha máquina pessoal. Agora sobe o sarrafo: ambiente corporativo.

A regra número um é simples e inegociável: nenhum agente de IA deve ter acesso a produção. Nunca. Nem SSH direto em servidor de produção, nem credencial de banco de produção, nem token de admin de serviço em produção. Se o seu agente consegue rodar um DELETE na base que atende clientes, o problema deixou de ser a IA faz tempo: qualquer estagiário com o mesmo acesso é a mesma bomba-relógio, só com menos velocidade de digitação.

Agente em staging, por outro lado, eu defendo. É pra isso que staging existe. Mas mesmo em staging tem jeito certo: você resiste à tentação de pedir ações one-shot (“roda um apt install aí”, “dá um systemctl restart”, “conecta no postgres e executa isso”). Comando avulso executado na mão é conhecimento que evapora. Sua infraestrutura precisa ser automatizada e reproduzível: Ansible, Kubernetes, Terraform, o que fizer sentido pro seu stack. O papel do agente passa a ser escrever e refinar essas receitas, que ficam versionadas em git.

Um exemplo pequeno, aqui da minha mesa

Eu tenho um ambiente de jogos no meu PC principal, mas eu me recuso a misturar pacote de emulador com meu ambiente de desenvolvimento. Então isolei os jogos dentro de um distrobox. Pra quem não conhece: o distrobox cria containers (via podman ou docker) que se integram com seu desktop como se fossem nativos. Compartilham seu home (ou um home dedicado), acesso a GPU, Wayland, áudio. Na prática é uma distro completa dentro da sua distro, com espaço de pacotes separado.

O distrobox-gaming é um repositório de playbooks Ansible que constrói uma box Arch chamada gaming do zero: ES-DE de frontend, emuladores standalone (shadPS4, RPCS3, PCSX2, Dolphin, DuckStation, Eden e mais uma dúzia), cores do RetroArch, configs otimizadas por jogo, atalhos no launcher do host. E o distrobox-llm faz o mesmo pra uma box de trabalho com LLMs locais: CUDA, cuDNN, Ollama, whisper.cpp e LM Studio isolados numa box com --nvidia, enquanto o host só carrega o driver. Upgrade de versão maior do CUDA deixa de chacoalhar meu ambiente de desenvolvimento.

Quem escreveu a esmagadora maioria desses playbooks? Os agentes. Em vez de pedir “instala o RPCS3 pra mim”, meu prompt é “escreve a receita Ansible idempotente que instala e configura o RPCS3, roda ela, verifica o resultado e corrige até passar”. Olha um trecho real do role que cria a box do LLM:

- name: Check if distrobox exists
  ansible.builtin.shell: "distrobox list 2>/dev/null | awk '{print $3}' | grep -qx {{ dl_box_name }}"
  register: _box_exists
  changed_when: false
  failed_when: false

- name: Create distrobox
  ansible.builtin.command: >-
    distrobox create
    --name {{ dl_box_name }}
    --image {{ dl_image }}
    --home {{ dl_box_home }}
    {{ '--nvidia' if dl_nvidia_enabled else '' }}
  when: _box_exists.rc != 0

Idempotente: confere se a box existe antes de criar, rodar duas vezes dá no mesmo. Se meu PC pegar fogo amanhã, eu recrio os dois ambientes inteiros com um ansible-playbook site.yml em cada repo. O conhecimento está na receita, versionado, auditável. Zero comando perdido no histórico do shell.

Escalando o mesmo princípio pra produção

Numa empresa, troca distrobox por Kubernetes e o princípio é idêntico. O agente escreve o manifesto, testa no cluster de staging, você promove pra produção manualmente:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-api
  template:
    metadata:
      labels:
        app: minha-api
    spec:
      containers:
        - name: minha-api
          image: registry.exemplo.com/minha-api:v42
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
          resources:
            limits:
              memory: 512Mi

O fluxo profissional: o agente produz e ajusta o manifesto (ou o chart do Helm, ou o módulo do Terraform), aplica em staging (kubectl apply -n staging), roda os testes, observa efeitos colaterais, bugs, comportamento não intencional, e itera até você estar satisfeito. Aí VOCÊ, humano, promove pra produção (via PR revisado num fluxo GitOps, ou um kubectl apply manual e consciente), monitorando cada passo. O agente fez todo o trabalho pesado: os artefatos, os procedimentos, os checklists. Dá até pra pedir pra ele gerar a documentação de auditoria no final. Mas o dedo que aperta o botão de produção tem CPF.

Até o SQL “simples” de manutenção

Um caso que parece inofensivo e me incomoda muito: comando SQL de manutenção em produção. Muita gente sempre rodou esses comandos na mão, direto no client de produção, e agora está pedindo pro agente escrever E executar. Isso é inaceitável, com ou sem IA. Seu sistema deve ter um fluxo de migrations: a mudança vira código versionado, roda em staging primeiro, é validada, e só então executa em produção dentro do processo normal de deploy.

E “produção”, por definição, significa duas coisas que muita empresa finge ter. Primeiro: backups de verdade, testados, com restore ensaiado.

Jamais rode em produção qualquer coisa da qual você não consegue se recuperar.

Segundo: monitoramento. Se você não tem visibilidade do estado do sistema, você não tem produção, tem um servidor ligado na tomada e reza.

Monitoramento: até no meu humilde PC

E monitoramento é tão parte da disciplina que eu aplico até na minha máquina pessoal. Recentemente eu desenvolvi um widget de system health pro meu clock-tui (meu fork mantido do clock-tui original, com widgets de comando no modo relógio). Ele fica aberto num canto mostrando isso aqui:

Uma linha de veredito (“all systems healthy”) e o estado de tudo que este post descreveu: o backup do restic rodou há 19 horas e o próximo é às 03:03; o Timeshift mantém 23 snapshots; a limpeza de caches de desenvolvimento rodou há 32 horas; o scrub do BTRFS está em dia em cada filesystem, com trim recente, alocação saudável e zero erros de I/O; mais zumbis, load, memória e ocupação de cada disco. O widget (tclock-system-health) vem junto no repositório e no pacote do AUR, e detecta a maior parte disso sozinho.

Por trás dele estão as manutenções automatizadas, todas em timers do systemd: o restic diário às 3h; o dev-cache-clean (dia 1 e dia 15) varrendo target/ órfãos de Rust e cache do yay, que juntos devolvem dezenas de gigas; o btrfs-scrub mensal por filesystem validando checksums; o fstrim semanal. Nada disso exige que eu lembre de nada. Quando algum atrasar ou falhar, o widget muda de cor na minha cara.

Esse é o nível caseiro, proporcional a um PC pessoal. Numa empresa você vai de full-blown: Prometheus coletando métricas, Grafana desenhando os dashboards, Alertmanager acordando o plantonista às 3 da manhã. A escala muda, o princípio é o mesmo: o estado do sistema visível o tempo todo, e alguém (ou alguma coisa) sendo avisado quando sai do trilho.

Conclusão: disciplina

Volta nos dois tweets do começo. Em ambos os casos, um único comando errado causou perda real, e a discussão pública virou “em quem eu confio mais”. A pergunta certa é outra: por que um único comando errado, de qualquer origem, tem o poder de causar perda irrecuperável na sua máquina?

Ser profissional é ser disciplinado, e a disciplina começa em casa. Meu PC pessoal opera com o mesmo rigor que eu cobraria de um ambiente corporativo: filesystem com snapshots leves e agendados, boot recuperável via GRUB, backup externo diário com política de retenção, sandbox pra sessões suspeitas, ambientes isolados e reconstruíveis por receitas versionadas, manutenção automatizada e um monitor que me avisa quando qualquer peça atrasa. Custo de manutenção mensal disso tudo: perto de zero. Foi montado uma vez (em boa parte pelos próprios agentes) e funciona sozinho.

Com essas camadas, a pergunta do título quase perde o sentido. O agente apagou um diretório? Snapshot de uma hora atrás, dois minutos de recuperação. Destruiu o sistema? Boot num snapshot pelo GRUB, restore, dez minutos. Fritou o disco junto? Restic no NAS, backup de ontem. Em cinco meses de YOLO mode eu nunca precisei de nenhuma dessas redes pra acidente de IA. Mas eu durmo tranquilo justamente porque elas estão lá.

LLM rodando solto no seu sistema é só o teste de estresse mais recente da sua disciplina. Se um agente descontrolado consegue causar perda permanente nos seus dados, a vulnerabilidade sempre esteve aí, esperando um erro seu, um disco ruim ou um ransomware. O agente foi só o mensageiro que chegou primeiro.

Os três nomes da vez são Sonnet 5, Gemini 3.5 Flash e Sakana Fugu Ultra. O Sonnet 5 é o nome que chama atenção. Modelo novo, marca forte, expectativa alta. Só que expectativa não compila. Ele rodou, passou no Docker, subiu no Compose, e mesmo assim terminou em 58/100, Tier C. A primeira conversa real quebraria antes de chamar o modelo.

O susto bom veio de outro lado: Gemini 3.5 Flash fez 93/100, Tier A, #6. Um Flash. Acima de Kimi K2.6, GLM 5.2 e Gemini 3.1 Pro.

E teve Sakana Fugu Ultra, que ficou no limite: 79/100, Tier B, batendo na porta do Tier A. Qwen3.7 Max e Step 3.7 Flash também entraram, mas como elenco de apoio. Nex é importante, só que já destrinchei o caso dele no post sobre a controvérsia da Rio 3.5. Aqui ele fica como linha de ranking e referência.

Desde o último benchmark minha recomendação prática não mudou: programação séria, sessão longa, projeto real, hoje ainda é Opus 4.8 ou GPT 5.5, usando Claude Code, Codex ou OpenCode. O que mudou foi o miolo da tabela. E é no miolo que dá pra ver quem está aprendendo e quem só trocou o número da versão.

Pra quem caiu de paraquedas

O teste é simples de explicar e chato de fazer. Dou o mesmo prompt pra cada modelo e peço pra construir, sozinho, um app de chat estilo ChatGPT em Rails 8 + RubyLLM + Hotwire + Docker, com testes e CI. Depois leio o código na mão e dou nota de 0 a 100, em tiers A/B/C/D.

Não é múltipla escolha. Não é puzzle. Não é “complete esta função”. É um agente tentando entregar um projetinho Rails inteiro. Ou entrega, ou tropeça.

A série até agora:

1. Benchmark canônico de Maio (Parte 3), com a metodologia completa.
2. DeepSeek destravado com DeepClaude.
3. Update Grok 4.3, MiniMax M3, Opus 4.8.
4. Fable 5 e a novela da Anthropic.
5. Kimi v2.7 code, GLM 5.2, MiniMax M3 local.

A armadilha continua a mesma: a coluna “RubyLLM OK” não é enfeite. Se o modelo inventa uma API que não existe, o app morre no recurso principal. Às vezes tudo em volta parece bonito: Tailwind, Turbo, Docker, README, testes verdes. Aí você clica em “Enviar” e toma NoMethodError.

A novela dos modelos fechados

A Anthropic tinha colocado controles do governo americano em cima do Claude Fable 5 e Claude Mythos 5 em 12 de junho. Motivo: não dava pra verificar nacionalidade em tempo real em todos os canais globais. Em 30 de junho, suspenderam os controles do Fable 5, e a Anthropic anunciou a volta gradual para Claude Platform, Claude.ai, Claude Code e Claude Cowork. Mythos 5 continua mais restrito, só para organizações americanas aprovadas via Project Glasswing.

Fontes: post da Anthropic sobre a volta do Fable 5, post original de Fable 5 e Mythos 5, e The Verge sobre a suspensão dos controles.

Do lado da OpenAI, o GPT-5.6 apareceu oficialmente, mas ainda em preview limitado. Tem página da OpenAI e artigo no help center. Não está disponível o bastante pra eu colocar no benchmark como coloco GPT 5.5 hoje. Então fica registrado, sem número ainda: preview do GPT-5.6 Sol e help center do GPT-5.6 Sol, Terra e Luna.

Ranking atualizado

Os modelos novos desta rodada estão em negrito. Nex-N2-Pro e Qwen 3.5 397B base continuam destacados porque entraram na tabela depois do último benchmark, mas a análise longa deles já apareceu no post da Rio 3.5.

Sonnet 5: passou no Docker, falhou no coração

O Sonnet 5 fez 58/100, Tier C, #25. E aqui está a parte que engana: a fase 2 passou. Boot local. Docker build. Docker Compose. O projeto tinha Rails 8, Turbo, Stimulus, Tailwind, README, CI, SimpleCov, Brakeman, RuboCop, bundler-audit. A casca estava bonita.

O problema estava exatamente onde não podia estar: no caminho do LLM.

O serviço gerado faz isso:

RubyLLM.chat(model: MODEL, provider: PROVIDER).tap do |chat|
  chat.messages = history
end

Só que o RubyLLM 1.16 tem messages, add_message, ask e with_instructions. Não tem messages=. A primeira conversa real levanta NoMethodError antes de chegar no modelo. O teste não pega porque o FakeChat do próprio projeto define attr_accessor :messages, justamente o writer que não existe em produção.

Esse é o tipo de bug que me faz continuar lendo benchmark na mão. Build verde não prova integração correta. Teste verde pode ser pior que inútil quando o fake ensina uma mentira pro teste.

Tem mais: o app gerado ainda defaultava para anthropic/claude-sonnet-4.6, não Sonnet 5, e deixava o system prompt sem with_instructions. A casca estava completa. O recurso principal estava quebrado.

Resumo cruel: Sonnet 5 passou no Docker e falhou no coração. Se você paga Anthropic pra programar hoje, continuo recomendando Opus 4.8. Não Sonnet 5.

Gemini 3.5 Flash: o susto bom

O Gemini 3.5 Flash foi o tapa na cara da rodada: 93/100, Tier A, #6. Melhor resultado não-Anthropic/não-OpenAI do benchmark até agora. Quatorze pontos acima do Gemini 3.1 Pro.

A integração RubyLLM foi exemplar:

chat = RubyLLM.chat(model: @model, provider: :openrouter, assume_model_exists: true)
chat.with_instructions(SYSTEM_INSTRUCTION)
@conversation.messages.each { |msg| chat.add_message(role: msg.role.to_sym, content: msg.content) }
response = chat.complete
@conversation.add_message(role: :assistant, content: response.content)

Ele usou with_instructions, replay de histórico com add_message, complete e response.content. Tudo real. A suíte de testes foi a melhor desse grupo: FakeChat com assinatura compatível, stub no ponto certo (RubyLLM.chat), assert de parâmetros, replay de histórico e teste de erro. Parece básico. Não é. A tabela inteira prova que não é.

Também gostei da persistência. Ele grava em arquivo, em tmp/chats/<id>.json, com cap de 50 mensagens e preservando a mensagem de sistema. Sobrevive restart no mesmo host e é melhor que singleton em memória. Falta lock de arquivo, tmp/ é efêmero em container, e conversa concorrente pode dar race. Também não tem preflight bonito de API key. Tudo consertável.

O custo incomoda. Mesmo sendo Flash, o run saiu por volta de US$3,50, mais caro que Opus 4.8 neste benchmark, por churn alto de token. Então não dá pra vender como “baratinho”. Mas como sinal de qualidade é forte. Um Flash em #6 muda minha intuição sobre Gemini.

Sakana Fugu Ultra: quase Tier A, faltou memória

O Sakana Fugu Ultra entrou com 79/100, Tier B, #12 empatado. Pra um provedor novo, foi uma estreia limpa. O harness funcionou. O app subiu. Docker/Compose passaram. RubyLLM era real (chat, with_instructions, ask, response.content). Os testes usavam FakeChat correto. Turbo/Stimulus estavam bons.

O problema é pequeno de explicar e grande de consequência: o modelo só enxerga a última mensagem. O histórico é salvo e exibido, só não é replayado para o RubyLLM. A UI parece chat multi-turn. O LLM trabalha como se cada mensagem fosse a primeira.

Faltou justamente a parte que faz um chat ser chat.

Mesmo assim, esse é o tipo de resultado que eu gosto de ver. Não é desastre. Não é API inventada. É um app quase correto com uma falha específica. Trocar o repositório process-local por algo decente e replayar histórico com add_message já mudaria bastante a avaliação.

Qwen3.7, Step 3.7 e o rodapé do Qwen 3.6

O Qwen3.7 Max fez 78/100, Tier B, #14 empatado. API RubyLLM correta, inclusive streaming e reset_messages!. Fase 2 passou. Só que ignorou Turbo Streams e implementou SSE cru com ActionController::Live. Num app real, talvez ok. Neste benchmark, o prompt pedia Hotwire/Turbo Streams. Também usou anthropic/claude-sonnet-4 em vez do Sonnet mais novo e guardou conversas num hash class-level sem limite. Reiniciou processo? Perdeu tudo. Rodou tempo suficiente? Vazou memória.

O Step 3.7 Flash fez 69/100, Tier B, #20 empatado. Corrigiu o erro grande do Step 3.5: agora usa ruby_llm de verdade, não bypass com ruby-openai. Bom. Só que cria um RubyLLM.chat novo por request e manda só a mensagem atual. O histórico fica num @@all class var, mas nunca chega ao modelo. Saiu do bypass errado e esqueceu de dar memória ao LLM.

E sim, teve Qwen 3.6 no histórico recente de commits. Dois runs locais do Qwen 3.6 35B A3B entraram via PR #9 (cccc118 e f06ddd0), com perfil ik_llama.cpp local, mas o merge foi revertido em d5f9195. Por isso eles não entram na tabela principal desta rodada.

O dado útil de Qwen 3.6 local continua no relatório separado da RTX 5090: foi o primeiro modelo local daquele perfil a acertar RubyLLM.chat + chat.ask, mas ainda retornava o objeto inteiro em vez de response.content e não fazia multi-turn. Perto de funcionar. Ainda fora do ranking principal cloud/AMD.

Nex e Qwen base: já cobri no caso Rio 3.5

O Nex-N2-Pro fez 83/100, Tier A, #10, usando o endpoint grátis do OpenRouter. A base crua Qwen 3.5 397B A17B fez 42/100, Tier C, #31. Essa diferença de 41 pontos é importante. Repetir tudo aqui seria encher linguiça.

Eu já usei esses números no post sobre a controvérsia da LLM Rio 3.5, porque a acusação pública era justamente que o checkpoint da Rio parecia uma mescla de Nex-N2-Pro com Qwen3.5-397B-A17B. Lá está a explicação do que é Nex, por que a fine-tune importa, e por que uma Rio que herdasse ganho da Nex não deveria ser vendida como avanço óbvio sobre Nex puro sem benchmark reproduzível.

O resumo técnico é simples: a base Qwen inventou RubyLLM (chat.system, chat.user, response.text) e os testes mockavam essa API falsa. O Nex usou a API real, subiu localmente, passou Docker/Compose e entregou Turbo Streams com tratamento de erro. Ainda tem atalhos, como achatar histórico em texto em vez de usar add_message e with_instructions, mas é um Tier A legítimo. Só não é o foco deste post.

Meu uso real hoje

Na prática, tenho usado muito OpenCode + oh-my-opencode-slim + GPT 5.5 pra manter meus projetos open source. É um fork slim, limpo e mais econômico do oh-my-opencode. Exatamente o tipo de ajuste que combina com uso diário. O resto do meu toolkit de IA com ai-jail, ai-memory e ai-usagebar já expliquei em post separado.

É chato explicar isso pra quem só quer saber “qual modelo é melhor”. Modelo sozinho não carrega trabalho. Harness importa. Prompt de sistema importa. Memória do projeto importa. Qualidade dos testes importa. O mesmo modelo, num harness ruim, vira gerador de patch aleatório.

Tenho usado isso em coisas pequenas e reais, tipo extensões do Geary: geary-email-autocomplete e geary-hide-sidebar-module. Nada disso é revolução. É manutenção, bugfix, refactor, teste, documentação. Trabalho normal. Justamente onde agente precisa ser confiável por horas, não por uma demo de 90 segundos.

Por isso eu continuo repetindo: benchmark de modelo é útil, benchmark de fluxo é mais útil ainda. Sonnet 5 com API alucinada não me ajuda. Gemini Flash surpreendendo com RubyLLM correto me interessa. Sakana e Step acertando a gem mas esquecendo multi-turn mostram exatamente onde esses modelos ainda quebram em produto real.

Conclusão

A rodada deixou um recado simples: nome forte não salva integração quebrada. Sonnet 5 entrou com aura de modelo novo e saiu em Tier C porque chamou uma API que não existe.

Gemini 3.5 Flash merece atenção. Não por ser barato; neste run nem foi tão barato. Merece atenção porque entregou um app Rails/RubyLLM muito mais correto do que eu esperava de um Flash.

No lado open source/provedor alternativo, a história é mais mista. Sakana Fugu Ultra quase chegou em Tier A. Qwen3.7 Max acertou a API e errou o produto. Step 3.7 Flash corrigiu o bypass do 3.5 e esqueceu de dar memória ao chat. Tem avanço. Tem aresta.

Minha recomendação prática continua igual: Opus 4.8 ou GPT 5.5 pra programação séria hoje. Use Tier B pra tarefa pequena, barata, revisada. Use open source/local pra estudar e experimentar. E não confie em teste verde se o fake não imita a biblioteca real.

O benchmark é aberto: github.com/akitaonrails/llm-coding-benchmark. Quer ver outro modelo aí? Fork, adiciona no config/models.json, roda e manda o PR.