No mesmo dia saiu a versão 1.1.0. Hoje, 20 de julho, estamos na 1.17.1.

Versão sozinha não quer dizer grande coisa, então fui contar o que aconteceu de verdade desde o horário daquele post. Foram 31 releases, 55 pull requests mergeados e 46 issues fechadas. Eu contei 24 grupos de funcionalidades novas voltadas ao usuário no CHANGELOG, ignorando correções, documentação e detalhes internos da mesma entrega. Se eu quebrasse a nova família ai-memory run em auto-seleção, adoção de sessão, suporte a Crush, --yolo, busca e recuperação, passava disso fácil.

Quinze pessoas tiveram PRs mergeados nesse período, quatorze além de mim. Preciso agradecer em especial ao Djalma Júnior, que sozinho teve 24 PRs mergeados, Matheus Rodrigues, com cinco, lhzapata, com quatro, Thiago Silva e Cristiano Dewes, com dois cada. Mais nove contribuidores tiveram PR mergeado. Faz tempo que isso deixou de ser “um programinha que eu fiz num fim de semana”.

Não vou despejar 55 PRs aqui. Quero falar da mudança que mais afeta meu uso diário: o novo ai-memory run.

A sessão também faz parte do projeto

Código é o resultado que sobreviveu. Ele não guarda a investigação inteira.

O Git mostra que você trocou Redis por SQLite. Talvez o commit explique uma parte. Mas onde ficou o experimento com Redis? Onde está o bug intermitente que só aparecia com dois workers? Quem lembrou que a primeira solução quebrava no Windows? Por que o time mudou de ideia depois de três horas? Qual workaround era temporário e qual virou decisão?

Boa parte disso só existe na sessão do agente.

Quando programo com Claude Code ou Codex, a sessão acumula o raciocínio operacional do projeto: perguntas, correções, tentativas descartadas, resultados de testes, surpresas, decisões e mudanças de direção. O código final mostra o que ficou. A sessão explica por que chegamos ali.

E sessão de LLM, no fim das contas, é texto. Claude Code grava JSONL. Codex também. OpenCode usa SQLite. Pi, OMP e Crush têm seus próprios formatos e diretórios. Cada harness empacota a conversa de um jeito, mas o conteúdo visível continua sendo mensagens e resultados de ferramentas.

Por que eu deveria deixar a parte mais cara do trabalho presa ao harness?

Anthropic pode mudar limite, preço, modelo ou formato amanhã. OpenAI também. Um agente pode estar excelente esta semana e insuportável na próxima. Eu quero trocar o motor sem jogar fora a viagem inteira.

Essa é a tese do ai-memory desde o começo: o programador tem que continuar independente das vontades dos providers. Modelo e harness são substituíveis. A memória do projeto é minha.

O handoff resolvia só metade

O ai-memory já fazia passagem de bastão. Eu encerrava Claude Code, os hooks consolidavam a sessão e o Codex seguinte recebia um resumo curto com o que foi feito, perguntas abertas e próximos passos.

Isso continua existindo e continua útil. Quem abre claude, codex ou opencode diretamente mantém o comportamento anterior. O launcher novo é opt-in.

Mas handoff é uma compressão deliberadamente lossy. Ele preserva o que parece mais importante naquele momento. Não pretende transportar a sessão inteira, nem retomar a sessão nativa de cada harness. Se o resumo omitiu uma tentativa antiga que voltou a ser relevante duas horas depois, você precisa procurar na wiki ou nos registros.

O ai-memory run acrescenta outra camada: uma workstream gerenciada, uma linha de trabalho que atravessa os harnesses.

Claude hoje, Codex daqui a pouco

O uso básico é esse:

cd ~/Projects/meu-projeto

ai-memory run claude
# trabalha, encerra o Claude Code normalmente

ai-memory run codex --yolo
# Codex continua a mesma linha de trabalho

ai-memory run claude --model opus
# volta pra sessão nativa anterior do Claude

ai-memory run
# ou deixa o ai-memory escolher o harness certo pra continuar

Não precisa de -- pra separar os argumentos. Tudo depois do nome do harness segue pra ele, com uma exceção proposital: o --yolo pertence ao wrapper e é traduzido pra opção perigosa nativa de Claude Code, Codex, OpenCode, Pi ou Crush.

Por baixo, o ai-memory não tenta converter um arquivo do Codex num arquivo do Claude. Isso seria frágil e provavelmente quebraria na próxima atualização. Cada harness mantém sua própria sessão nativa. A workstream liga essas sessões a um ledger portátil com a parte visível da conversa.

Pensa assim:

sessão nativa do Claude ─┐
sessão nativa do Codex  ─┼─ workstream ─ contexto portátil
sessão do OpenCode      ─┤                 + busca completa
sessão nativa do Pi     ─┘

Na primeira vez que Claude entra naquela workstream, ele ganha uma sessão nativa. Quando você troca pra Codex, o Codex ganha a sessão nativa dele e recebe o delta portátil que ainda não viu. Ao voltar pro Claude, o launcher usa o --resume do próprio Claude Code e entrega apenas o que aconteceu nos outros harnesses desde a última vez.

Isso é bem diferente de começar um chat novo com um resumo colado no prompt. O Claude volta pra sessão real dele. O Codex volta pra sessão real dele. O ai-memory cuida da continuidade entre os dois.

Hoje o modo gerenciado suporta Claude Code, Codex, OpenCode, Pi, Crush e OMP. O suporte geral do ai-memory é maior, com MCP e hooks pra outros clientes, mas isso não quer dizer que todo cliente já tenha adapter de sessão nativa pro run. São contratos diferentes e eu prefiro deixar isso explícito.

O que entra na workstream

Quando o harness encerra, o ai-memory lê o final da sessão nativa sem modificar o store original. Entram mensagens visíveis de usuário e assistente, tool calls concluídas com seus resultados, resumos de compaction e um checkpoint não mutante do Git. Cada evento mantém a origem: veio do Claude, Codex, OpenCode, Pi, Crush ou OMP.

Credenciais do provider, registros criptografados, system/developer prompts e hidden reasoning ficam de fora. Formatos privados que o adapter não entende também ficam de fora e geram uma anotação de perda, em vez de o sistema fingir que importou tudo.

Os registros passam pelo sanitizer antes de entrar no ledger pesquisável e nos segmentos JSONL imutáveis do ai-memory. Os stores nativos são abertos read-only pelo adapter; quem continua escrevendo neles é o próprio harness.

Também não enfio a sessão inteira no próximo prompt. Isso recriaria o problema que o projeto tenta resolver: contexto bruto demais, caro demais e cheio de ruído. O próximo agente recebe um delta recente com tamanho limitado. Se uma decisão velha voltar a importar, o ledger completo continua pesquisável:

ai-memory workstream-search "por que desistimos do Redis"
ai-memory workstream-search --limit 50 --json "migration que falhou"

Dentro de um ai-memory run, o ID da workstream já entra no ambiente. O agente não precisa descobrir UUID nenhum.

E o ledger não substitui a wiki. Ele resolve continuidade operacional. Decisões, regras, procedimentos e gotchas que precisam sobreviver por meses continuam merecendo páginas Markdown consolidadas. Sessão bruta é evidência. Wiki é conhecimento organizado.

Posso manter mais de uma linha de trabalho?

Sim. A workstream padrão se chama default, selecionada por repositório e worktree. Se eu quiser abrir uma linha independente pra uma investigação sem contaminar o trabalho principal:

ai-memory run --new investigar-race claude

# depois continuo aquela linha com outro harness
ai-memory run --workstream investigar-race codex

Uma lease impede duas janelas de escreverem ao mesmo tempo na mesma workstream. Em encerramento normal, o launcher importa o final da sessão e libera imediatamente. Se alguém matar o processo sem cleanup, a lease expira em até 90 segundos e a próxima execução retoma do último cursor confirmado, sem duplicar os eventos já importados.

Uma irritação besta que eu tinha o tempo todo: voltava pra um projeto depois de alguns dias e não lembrava se a sessão mais recente estava no Claude ou no Codex. Eu chutava um, abria, percebia que o contexto estava no outro, fechava e tentava de novo.

Agora só rodo:

ai-memory run

# ou com a mesma seleção automática em YOLO mode
ai-memory run --yolo

Numa workstream vazia, o ai-memory procura sessões locais daquele checkout em Claude Code, Codex, OpenCode, Pi e Crush, descobre qual é a mais recente e abre o harness certo pra mim. Numa workstream já estabelecida, a memória do servidor vence o timestamp de arquivo: ele volta ao último harness ligado àquele trabalho, em vez de adotar por engano uma sessão velha que só recebeu uma gravação mais recente. OMP continua disponível quando escolhido explicitamente, mas ainda não participa da seleção automática.

Na primeira execução explícita, o launcher também pode oferecer sessões existentes do mesmo checkout pra adoção. Dá pra começar a usar sem abandonar o chat que já estava aberto antes de atualizar o ai-memory.

Outras novidades que eu realmente uso

Eu prometi não ler o changelog inteiro em voz alta, mas algumas mudanças desse mês merecem menção porque reduzem trabalho do programador.

Briefing antes da primeira pergunta

Um projeto pode pedir um briefing automático no início de cada sessão:

[briefing]
inject_on_session_start = "true"
max_chars = 4000

O ai-memory recompõe um pacote com páginas pinned, _rules/, _slots/ e títulos recentes. O agente começa sabendo as regras e o estado básico do projeto, em vez de gastar a primeira conversa redescobrindo a arquitetura. É opt-in porque consome contexto em todo SessionStart, inclusive depois de um /clear do Claude.

Preferências globais e busca entre projetos

Preferências que valem pra todo meu trabalho agora podem viver no escopo reservado _global: estilo de código, ferramentas que prefiro, regras pessoais e convenções que não pertencem a um repositório específico. Consultas normais já fazem union desse escopo com o projeto atual.

Pra meta-repos que precisam consultar vários projetos irmãos o tempo todo, existe outro opt-in:

[recall]
default_global = "true"

Assim memory_query e memory_recent sem escopo explícito procuram em todos os projetos. Não ligo isso em qualquer repo porque busca global à toa só traz ruído.

Menos instrução fixa, mais Agent Skills

O bloco de routing em CLAUDE.md ou AGENTS.md ficou pequeno. As instruções detalhadas de quando buscar memória, consolidar, guardar decisão ou criar handoff foram movidas pra Agent Skills gerenciadas. Um comando instala ou atualiza os dois sem atropelar o resto do arquivo:

ai-memory install-instructions

Isso também reduz drift. Quando o protocolo muda, atualizo o pacote gerenciado em vez de caçar um prompt velho copiado em quarenta repositórios.

Privacidade antes da rede

Agora cada repo pode excluir caminhos da captura:

[capture]
ignore_paths = ["private/**", "~/personal-notes/**"]

Quando uma integração reconhece uma file tool e o caminho bate, o evento é descartado localmente antes de spool, fila, rede ou servidor. Isso tem limites claros: não é DLP mágico, não interpreta qualquer shell command e não rastreia conteúdo citado em texto livre. Mas resolve o caso verificável sem vender uma garantia falsa.

Também entraram integrações com Kimi Code, Grok Build CLI, Devin e Zero, um provider OpenCode Zen/Go, finalize-session pro Codex e melhorias na administração de workspaces. Reforço: ter MCP e hook não significa automaticamente ter ai-memory run. O README separa esses níveis.

Bônus: ai-jail por fora, YOLO por dentro

Há pouco mais de uma semana escrevi como me protejo pra agentes não apagarem minhas coisas. Minha recomendação continua a mesma: YOLO mode dá a melhor experiência, desde que o sistema limite o estrago possível.

O ai-jail chegou à versão 1.15.0 e agora entende o launcher do ai-memory. O jeito que mais estou gostando de trabalhar virou:

ai-jail ai-memory run codex --yolo

Ou, se quero que o ai-memory escolha qual harness deve continuar:

ai-jail ai-memory run --yolo

A ordem importa. ai-jail fica por fora para manter tanto o launcher quanto o processo filho na mesma sandbox. ai-memory run sozinho gerencia a sessão, mas não cria sandbox.

O --yolo desliga a cerimônia de aprovação do harness. O ai-jail faz a contenção: projeto atual read-write, home substituído por tmpfs, partes necessárias do estado dos agentes montadas seletivamente e diretórios sensíveis como .ssh, .gnupg e .aws fora da jaula. O suporte novo também deixa o estado local do ai-memory gravável pros hooks manterem spool e cursores entre execuções.

ai-jail reconhece tanto a camada ai-memory quanto o harness selecionado. Se você tem configuração global específica pra Codex, por exemplo, ela continua sendo aplicada quando o comando real é ai-memory run codex. Até o ajuste de redraw da status bar entende que o filho é Codex.

Essa combinação resolve as duas irritações ao mesmo tempo: o agente para de pedir confirmação a cada comando e a sessão para de pertencer ao agente. Fluidez sem dar o home inteiro de presente.

One more thing: ai-usagebar também cresceu

Quando publiquei o ai-usagebar original, ele monitorava Claude, Codex, Z.AI e OpenRouter num widget da Waybar ou numa TUI. A versão 0.14.0 já cobre onze integrações de uso, gasto ou saldo.

Kimi ganhou as duas informações que realmente importam pra coding: quota semanal da assinatura e janela móvel de cinco horas. Kilo, Novita, Moonshot e Grok mostram saldo restante. Uma integração separada da Anthropic Console mostra gasto de API no mês, sem confundir isso com a assinatura do Claude Code. Ela deixa explícito que o Cost API não inclui Priority Tier.

Também dá pra cadastrar várias contas da Anthropic, ver limites semanais específicos de modelos como Fable e enxergar um marcador de ritmo. A barra não fica vermelha só porque chegou em 40%; ela compara o percentual gasto com quanto da janela já passou. Se usei 40% em 20% da semana, estou rápido demais. Essa é a informação útil.

O projeto deixou de ser só Waybar. Tem app nativo de menu bar no macOS, extensão do GNOME e a TUI standalone. E a novidade mais recente é um monitor local de contexto do Claude Code: aperto c, escolho uma das sessões recentes e vejo quanto da janela já foi consumido. Ele lê caudas limitadas dos JSONL locais e não inventa porcentagem quando não consegue determinar o tamanho da janela.

No meu fluxo, o trio acaba se encontrando naturalmente. ai-usagebar mostra qual assinatura ainda tem espaço. ai-memory run troca de harness sem jogar fora o trabalho. ai-jail deixa o escolhido trabalhar em YOLO sem acesso irrestrito à máquina.

Atualizando

As páginas de instalação dos três projetos têm todos os métodos, incluindo AUR, Homebrew e binários de release:

• ai-memory
• ai-jail
• ai-usagebar

Depois de atualizar o ai-memory, reinstale os hooks dos harnesses que pretende usar no modo gerenciado. Os três principais no meu caso:

ai-memory install-hooks --agent claude-code --apply
ai-memory install-hooks --agent codex --apply
ai-memory install-hooks --agent opencode --apply

Crush não precisa de hook no modo gerenciado; ele recebe o contexto por um arquivo temporário configurado só pro processo lançado. A documentação de managed workstreams tem os detalhes de instalação, privacidade, recuperação e os argumentos nativos de cada adapter.

Conclusão

Um mês atrás, o ai-memory já conseguia transformar sessão em wiki e entregar um handoff pro próximo agente. Agora ele consegue gerenciar a própria linha de trabalho: adota uma sessão existente, mantém uma sessão nativa por harness, transporta o histórico visível, retoma cada cliente no formato dele e deixa o ledger inteiro pesquisável.

Pra mim, é aí que está o valor. O código contém a implementação que venceu. A sessão contém as decisões, experimentos que falharam, gotchas, bugs inesperados e mudanças de ideia que produziram aquela implementação. Jogar isso fora toda vez que muda de provider é desperdício.

Raw transcript também não resolve sozinho. É grande, repetitivo e caro pra enfiar em qualquer contexto. O ai-memory mantém a evidência, entrega só o delta recente e usa consolidação pra transformar o que merece sobreviver em páginas Markdown curtas.

Ainda há formatos novos pra suportar, arestas de plataforma e muito teste pela frente. A diferença é que agora existe uma base real, com acceptance test chamando harness de verdade, 14 contribuidores externos com PR mergeado em pouco mais de um mês e uso diário empurrando o desenho.

LLM e assinatura eu alugo de quem estiver entregando melhor hoje. A sessão do meu projeto fica comigo.

Eu gosto dessa fase. O projeto deixa de ser “o que eu imaginei no meu setup” e vira “o que quebra na máquina de outra pessoa”. Aí aparece Windows, macOS, Arch, AUR, path esquisito, token salvo em lugar diferente, shell diferente, terminal diferente. Chato? Sim. Necessário? Também.

Mas o prato principal de hoje não é ai-jail nem ai-memory. É TUI. Mais especificamente, é minha mania recente de escrever pequenas ferramentas de terminal em Rust com Ratatui, mas querendo que elas fiquem com cara de Bubble Tea.

O app que não vou abrir

Nas últimas semanas também mexi num projeto privado que não pretendo abrir. É uma TUI pra acompanhar minha conta nos EUA, investimentos, assets, posições, covered calls, open calls, essas coisas chatas de adulto. Não vou publicar o código porque é o tipo de ferramenta que nasceu colada no meu fluxo financeiro, nas minhas planilhas, nos meus extratos e nas minhas gambiarras internas. Abrir isso seria transformar uma ferramenta minha em suporte gratuito pra bug de banco dos outros. Tô fora.

Mas dá pra mostrar a cara geral. Censurei o que precisava censurar:

Observação óbvia, mas vou deixar explícito: todos os valores, tickers, posições e datas mostrados no screenshot são dados falsos de demonstração. Não é dado real da minha conta, nem portfolio real, nem recomendação de investimento.

Toda vez que faço uma TUI pequena, a mesma dúvida aparece: que stack usar?

Se eu fosse escrever tudo na unha, provavelmente escolheria Python ou Go. São linguagens mais confortáveis pra esse tipo de utilitário pequeno. Python porque é direto, cheio de biblioteca, ótimo pra script que conversa com API e parseia JSON. Go porque gera binário simples, cruza plataforma bem, e tem ergonomia boa pra CLI.

Só que hoje eu raramente escrevo esse código todo na unha. Eu orquestro Claude, Codex, OpenCode, mando revisar, mando refatorar, mando testar. Nesse cenário, a falta de ergonomia do Rust pesa menos, porque quem briga com borrow checker, trait bound e lifetime chato é o LLM. Eu fico mais no papel de revisor e usuário final. E aí Rust começa a ficar muito atraente.

Ferramental bom. cargo é ótimo. Testes são fáceis de rodar. Cross compile é administrável. O binário final é limpo. Erro de memória idiota praticamente some. Não estou dizendo que Rust é magicamente melhor que Go ou Python pra toda TUI. Não é. Mas com LLM escrevendo a maior parte, o custo que normalmente me faria evitar Rust cai bastante. E os modelos atuais estão surpreendentemente competentes em Rust, desde que você mande rodar teste, consertar warning e não aceite a primeira versão como se fosse revelação divina.

Ratatui é bom, mas eu queria a cara do Charm

O Ratatui é uma biblioteca Rust pra construir interfaces ricas no terminal: dashboards, apps interativos, tabelas, listas, gauges, layouts, tudo aquilo que antigamente a gente chamava de “ncurses moderno”. Ele é o sucessor espiritual do tui-rs, e hoje é provavelmente o caminho mais óbvio se você quer fazer TUI séria em Rust.

Ratatui funciona bem. O problema é gosto pessoal: por padrão, não acho bonito. Não é feio no sentido “isso parece programa de DOS de 1993”. Dá pra fazer coisa boa. Mas muita TUI em Ratatui cai naquela estética quadrada, cinza, funcional, meio admin panel de datacenter.

Eu gosto mais da pegada da Charmbracelet. O gum, por exemplo, é uma coleção de comandos pra deixar shell script interativo sem virar festival de read -p e case. Prompt, select, filter, spinner, tabela, pager, estilo. Você monta um script bash com cara de app decente em minutos.

E tem o Bubble Tea, em Go, inspirado na arquitetura Elm. Você tem um model, recebe mensagens, atualiza estado, renderiza uma view. É uma ideia simples e muito boa pra terminal: estado entra, evento entra, view sai. A Charm também tem um gosto visual que eu curto: cores boas, espaçamento decente, componentes leves, nada com cara de formulário WinForms jogado no terminal.

Então eu queria o seguinte: continuar em Rust com Ratatui, mas roubar a sensação de Bubble Tea. Não o runtime inteiro. Não um clone perfeito. Só a direção visual e alguns componentes.

Daí nasceu o ratatui-bubbletea.

O projeto não substitui o Ratatui. Ele fica por cima. A ideia é oferecer uma camada de tema e componentes com inspiração em Bubble Tea/Bubbles, mas ainda renderizando com Ratatui.

Hoje ele é dividido em crates:

• ratatui-bubbletea-theme, com paleta, helpers e estilos compartilhados.
• ratatui-bubbletea-components, com componentes prontos como select list, spinner, progress, table, text input, viewport e help.
• ratatui-tea, opcional, pra quem quer uma ergonomia mais perto de Model, Msg e Cmd, sem fingir que Rust virou Go.

O README tem os exemplos completos e a documentação do que já existe. Por enquanto, eu trato como toolkit pequeno. Serve pra meus apps, e se servir pra mais alguém, ótimo. Se não servir, também não tem drama. O objetivo era parar de reimplementar o mesmo tema e os mesmos widgets toda vez que eu começava uma TUI nova.

ai-usagebar como exemplo público

Como não vou abrir o app financeiro, precisava de um exemplo público usando essa estética. Então atualizei meu ai-usagebar.

Pra quem não lembra, expliquei o projeto no post “Criei um Widget de Waybar pra Omarchy pra Monitorar Uso de Planos de LLM: ai-usagebar”. Ele nasceu como widget de Waybar pra mostrar uso de planos de LLM: Claude, OpenAI Codex/ChatGPT, Z.AI, OpenRouter. Bateu o olho na barra, sabe se está perto do limite e qual vendor usar agora.

Depois virou também TUI standalone. E graças a contribuições, hoje suporta Windows também. Isso é engraçado porque a origem dele é totalmente Linux/Omarchy/Waybar. Mas é open source: alguém usa em outro ambiente, encontra atrito, manda PR, e pronto, o projeto fica menos provinciano.

No ai-usagebar a diferença visual não muda a vida de ninguém. É uma tela simples. Abas, gauges, texto, atalhos. Mas é um bom exemplo porque é pequeno, real, testado, empacotado, e não depende do meu app privado. Dá pra olhar o código e ver como apliquei a camada de tema.

Os apps de coceira própria

Esses projetos todos seguem a mesma lógica: eu tenho uma coceira, faço uma ferramenta pequena, uso, ajusto, empacoto. Nada de roadmap de startup. Nada de manifesto. Só ferramenta que resolve um incômodo meu.

Um exemplo recente é o clock-tui. Ele não nasceu comigo. Era um projeto Rust antigo, tclock, que parecia abandonado. Eu queria um relógio grande no meu segundo monitor vertical. Aquele monitor fica do lado, e eu gosto de ter um “desk clock” enorme ocupando parte da tela. Usei o clock-tui original por um tempo.

Só que uma tela vertical inteira só pra mostrar hora é desperdício. Eu já tinha o ghpending, que lista issues e PRs abertos em todos os meus projetos. Ele é meu “tem alguém esperando resposta?” em formato de CLI. Também queria ver minha agenda.

Então fiz outro app pequeno: google-calendar-tui. Ele usa as contas Gmail já registradas no GNOME Online Accounts e resume meus próximos compromissos no terminal. Read-only. Sem ritual de OAuth novo. Sem mais um config secreto espalhado em lugar esquisito.

Com essas duas peças, modernizei o clock-tui e adicionei layout de widgets auto-refresh. Agora o relógio ocupa a tela como eu queria, mas em volta dele aparecem pendências do GitHub e agenda do Google Calendar.

Isso é exatamente o tipo de coisa que eu nunca faria se custasse um fim de semana inteiro. Mas com LLM, vira uma sequência de tarefas pequenas: lê o projeto antigo, moderniza dependências, roda teste, adiciona módulo de widget, chama ghpending, chama google-calendar-tui, organiza layout, corrige bug, empacota. Ainda dá trabalho. Mas é trabalho de supervisão e refinamento, não de ficar brigando com boilerplate.

Ajustando Geary sem fork

Outra coceira veio do GNOME.

Como eu queria centralizar minhas contas no GNOME Online Accounts, comecei a usar Geary e o calendário do GNOME no segundo monitor também. Gosto da ideia: contas configuradas uma vez, apps do desktop reaproveitando a mesma infraestrutura, nada de cada programinha inventar seu próprio login.

O problema é que o Geary tem um layout fixo de três colunas. Numa tela normal, tudo bem. Num monitor vertical, fica apertado. A coluna de pastas, a lista de mensagens e o corpo do e-mail brigam por espaço. Eu não queria manter um fork do Geary só pra esconder uma sidebar. Fork de app GTK grande é dívida. Você pisca e passa o resto da vida resolvendo conflito de merge.

Então fiz um módulo GTK: geary-hide-sidebar-module. Ele injeta um comportamento no Geary em runtime e permite recolher/expandir a sidebar, com atalho e auto-collapse em janela estreita. Sem recompilar Geary. Sem manter fork. Só um módulo pequeno com uma responsabilidade bem específica.

Essa é uma lição boa: às vezes você não precisa forkar a aplicação inteira. Dá pra ajustar por fora. GTK_MODULES existe. Wrapper existe. Config existe. CSS existe. Script existe. Nem toda personalização precisa virar uma manutenção eterna de código dos outros.

Código pequeno ficou barato

É por isso que estou insistindo tanto nessa ideia de apps pequenos. Com LLMs atuais, ficou muito fácil implementar uma ideia específica pra deixar seu ambiente do jeito que você quer. Sem esperar alguém ter exatamente a mesma dor. Sem ficar procurando no GitHub por três horas uma ferramenta que faz 80% do que você quer e 40% do que você não quer.

Você descreve a coceira, cria um repo, pede um protótipo, testa, manda refatorar, manda escrever teste, manda empacotar. Se ficar ruim, joga fora. Se ficar bom, instala e usa.

Eu não deixo isso virar gambiarra jogada no ~/bin sem dono. Meus apps têm testes. Têm builds automatizados. Muitos têm release no GitHub, pacote no AUR, instalação normal com yay no Arch. Usam paths XDG, então config vai pra ~/.config, cache vai pra ~/.cache, dados vão pra ~/.local/share. Fica organizado. Dá pra atualizar. Dá pra remover. Dá pra outra pessoa clonar e contribuir.

Pra fechar, os links todos num lugar só:

• ratatui-bubbletea
• ai-usagebar
• clock-tui
• ghpending
• google-calendar-tui
• geary-hide-sidebar-module
• ai-jail
• ai-memory

Se você usar algum deles e quebrar no seu setup, abre issue. Se souber corrigir, manda PR. Eu uso essas ferramentas de verdade, então bug report útil tende a virar correção rápido.

Minha regra prática é essa: personalize seu ambiente sem transformar tudo em gambiarra. Faça ferramenta pequena. Teste. Empacote. Documente. Deixe o LLM carregar o peso chato e use seu cérebro pra decidir o que presta.

Essa é a parte divertida de programar que tinha sumido um pouco. Agora voltou.

Vou repetir uma coisa importante antes que alguém saia clonando todos os meus repositórios achando que virou produto 1.0: a maior parte dos projetos frank-* no meu GitHub são provas de conceito. São experimentos. Alguns funcionam bem pra mim, no meu ambiente, no meu fluxo. Isso não quer dizer que estão prontos pra virar dependência crítica da sua empresa amanhã de manhã. Quer brincar, contribuir, estudar, ótimo. Só não confunda “publiquei no GitHub” com “está production ready”.

Existem exceções. O FrankMD, por exemplo, recebeu uma quantidade decente de contribuições, testes, lapidação, correções de bugs reais, uso real. Hoje ele já é bem mais estável do que era no primeiro post. Ainda assim, o ponto continua: esses projetos nasceram como laboratório de vibe coding, não como plano de produto de 3 anos com roadmap, suporte enterprise e SLA.

Este post é um apanhado do que aprendi nesse laboratório. Algumas ferramentas minhas, alguns hábitos, algumas recomendações. Nada místico. Nenhuma “nova forma revolucionária de programar”. É engenharia velha com ferramenta nova.

Primeiro: pare de colecionar agente

Se você é desenvolvedor normal, você não precisa de 12 agentes, 40 wrappers, 7 orquestradores e um diagrama de Kubernetes pra escolher quem vai escrever um if.

Na prática, foque em Claude Code, Codex ou opencode. Só isso.

Sim, existe Gemini CLI. Sim, existe Cursor. Sim, existe Windsurf, Crush, OpenClaw, Pi, Aider, e amanhã vai aparecer mais meia dúzia. Eu testei um monte. Leia meus posts de benchmark de LLMs, especialmente o “LLM Benchmarks Parte 3: DeepSeek, Kimi, MiMo”. A conclusão é chata e óbvia: hoje, as melhores opções de custo-benefício pra programação pesada são Opus 4.7 e GPT 5.5 nos planos Pro/Plus/Max subsidiados. Nada chega perto quando o assunto é trabalhar várias horas por dia com agente de código de verdade.

Pagar token direto é caro. Pagar plano mensal subsidiado sai muito mais barato. É por isso que eu vivo alternando entre Claude Code e Codex: não porque eu quero “multi-agent architecture”, mas porque os planos têm limites e eu trabalho muitas horas seguidas.

DeepSeek v4 e Kimi 2.6 são mais baratos? Sim. São usáveis? Sim. Eu gosto deles pra vários casos. Mas pra Agile Vibe Coding do jeito que venho defendendo desde o post “Do Zero à Pós-Produção em 1 Semana”, ainda falta. Eles tropeçam mais em continuidade, em refatoração longa, em testes, em entender o projeto inteiro. Dá pra usar? Dá. Mas se o objetivo é produtividade consistente, Opus e GPT ainda são a régua.

Rodar modelo open source local é legal. Eu mesmo brinquei bastante com isso no review do Minisforum MS-S1 Max com AMD AI Max+ 395. Pra one-shot, pra estudar, pra brincar com inferência local, é divertido. Pra Agile Vibe Coding o dia inteiro, todo dia, ainda não é prático. Latência, contexto, qualidade, manutenção do setup, VRAM, tudo cobra imposto.

Também não é prático ficar rodando múltiplos LLMs em paralelo, tipo “planner + executor + reviewer + juiz”. Eu testei isso no post “LLM Benchmarks: Vale a Pena Misturar 2 Modelos?”. A ideia é bonita no papel. Na prática, aumenta custo, aumenta latência, aumenta superfície de erro, e o ganho não paga a complexidade.

O segredo não é ter um monte de agentes. Esquece OpenClaw ou Pi pra programação do dia a dia. O segredo é processo de engenharia. XP. Testes. Clean Code pra agentes de IA. CI. Pair programming. Refatoração constante. Código pequeno. Deploy automatizado. Feedback rápido.

Ferramenta ajuda. Engenharia ganha.

ai-jail: autonomia com cerca

O primeiro projeto que quero destacar é o ai-jail. Ele é um wrapper de sandbox pra rodar agentes de IA com acesso restrito ao sistema. No Linux usa bubblewrap (bwrap) e Landlock. No macOS usa sandbox-exec. A ideia é simples: o agente enxerga o ambiente que precisa pra trabalhar, mas não sai fuçando seu sistema inteiro.

Uso todo dia? Sim. Uso sempre? Não.

Quando sei que não vou fazer nada arriscado, abro claude ou codex direto. Se vou mexer num projeto simples, só rodar testes, editar markdown, refatorar coisa local, muitas vezes nem me preocupo. Em mais de 600 horas de Agile Vibe Coding intenso, mais de meio milhão de linhas de código e documentação, nunca tive um caso desses folclóricos de LLM destruindo meu sistema host de um jeito irrecuperável.

E olha que eu usei agentes explicitamente pra configurar meu Omarchy. ZSH, Hyprland, Waybar, configs de terminal, scripts de login, tudo. Nunca fizeram nada que eu não pedi.

Essas histórias de “o agente deletou meu home inteiro sozinho” eu leio com um pé atrás. Na minha experiência, quando você pede pra deletar algo perigoso, Claude e Codex perguntam confirmação. Você precisa dizer sim. Se você disse sim sem ler, a culpa não é mágica negra do LLM. É usuário no modo zumbi.

Dito isso: nada é garantido. Daí o ai-jail.

Meu uso preferido é combinar ai-jail com o modo sem freio do harness:

ai-jail claude --dangerously-allow-permissions
ai-jail codex --dangerously-bypass-approvals-and-sandbox

Parece contraditório, mas faz sentido. Eu tiro a fricção de confirmação dentro do agente, mas coloco uma cerca no nível do sistema operacional. O agente pode trabalhar rápido dentro do projeto, mas o filesystem do host fica essencialmente read-only. O diretório atual fica read-write. O que eu mapear explicitamente com --rw-map também fica read-write. O resto não é pra tocar.

O README do ai-jail resume bem: é um sandbox wrapper pra agentes como Claude Code, GPT Codex, OpenCode e Crush. No primeiro run ele cria um .ai-jail no projeto, que pode ser commitado. Suporta --dry-run pra ver os mounts antes de executar, --lockdown pra modo mais restritivo, --private-home pra esconder dotfiles reais, --mask .env pra esconder arquivos sensíveis dentro do próprio projeto, e perfis de navegador isolado pra Chromium/Firefox.

O ponto importante: não venda isso como segurança absoluta. Processo sandbox não é VM. Kernel bug existe. Side channel existe. macOS tem limitações. O próprio README é claro: se você precisa isolar workload hostil de verdade, use uma VM descartável. Eu não uso ai-jail como “blindagem militar”. Uso como mais uma camada, boa o suficiente pro fluxo de desenvolvimento.

E mesmo dentro do projeto, tudo é Git. Eu faço push frequente pro GitHub ou pro meu Gitea privado. Então o pior caso realista é o agente destruir o diretório do projeto. Chato? Sim. Catastrófico? Não. Clono de novo. Volto do remote. Refaço o que estava local. Se o .git corromper, apago tudo e clono de novo.

Secrets também têm cópia fora. .env, tokens, keys, tudo que importa fica no Bitwarden. Self-hosted em Vaultwarden, claro. Então se eu perder o diretório local, não perdi a chave do reino.

O risco mais comum não é o agente deletar tudo. É você vazar segredo no Git. Isso aconteceu comigo mais de uma vez. Você dá git add ., esquece um .env, empurra pro remote, parabéns. Acontece. Por isso tem que olhar git status, git diff --cached, e pensar antes de dar push.

Mesmo quando acontece, os LLMs são muito competentes pra ajudar a reescrever histórico. Peço pra limpar o segredo do Git, forçar push, revisar se sumiu, e depois eu rotaciono a key. Não é bonito, mas é administrável.

Então sim, recomendo usar Claude/Codex com permissões perigosas dentro do ai-jail. Existe a chance de 0,001% de acidente irrecuperável? Existe. Mas se você é bom engenheiro, isso não deveria te matar. Eu tenho camadas: snapshots automáticos em Btrfs, restic pro NAS, NAS arquivando offsite em AWS Glacier, Git remoto, Bitwarden. Ferramenta nenhuma substitui backup.

ai-memory: contexto que sobrevive ao harness

O segundo é o ai-memory, que expliquei em detalhes no post “Criei um Sistema de Memória pra Agentes de Código: ai-memory”.

A motivação é simples: harnesses perdem contexto. Claude Code compacta. Codex compacta. opencode compacta. Sessão acaba. Você abre outro agente e ele não sabe o que aconteceu nas últimas 4 horas. Se você usa só um harness, talvez isso não incomode tanto. Se você alterna entre Claude e Codex como eu, incomoda rápido.

Eu queria um consolidador de memória de longo prazo que funcionasse atravessando harnesses diferentes. Algo que permitisse handoff entre Claude, Codex e opencode sem eu ficar escrevendo HANDOFF.md manual toda vez. Algo que capturasse prompts, tool calls e eventos de sessão via hooks, consolidasse em páginas markdown, indexasse com SQLite/FTS5, e expusesse tudo via MCP quando o agente precisasse consultar.

Outro motivador foi o que expliquei no post “RAG Está Morto? Contexto Longo, Grep e o Fim do Vector DB Obrigatório”. Pra projeto de código, quase sempre texto simples resolve mais do que arquitetura afetada de vector DB. Markdown, grep, SQLite FTS5, contexto longo e bons arquivos em docs/ já levam você longe. O ai-memory segue essa linha: compila memória em texto, deixa no disco, indexa simples, e só chama LLM quando vale consolidar.

O ai-memory não foi feito pra ser uma knowledge base navegável por usuário final. Ele tem uma UI web read-only, sim, mas isso é pra auditoria e inspeção. A memória é otimizada pra LLM consumir. É um wiki interno que o harness pode consultar quando acha que precisa. É um lugar onde posso pedir explicitamente “salva isso pra próxima sessão” e esperar que sobreviva mais do que a compactação padrão do Claude ou do Codex.

O README resume bem: agentes de código perdem todo contexto quando a sessão termina; o ai-memory dá a eles um wiki persistente compartilhado. Cada prompt, tool call e decisão pode ser capturado automaticamente. No fim da sessão, páginas relevantes são reescritas como narrativa coerente. Na próxima sessão, outro agente pode receber um handoff já prepended no contexto.

Isso é útil quando você fecha Claude às 18h, abre Codex no dia seguinte no mesmo diretório, e quer que ele saiba que você estava testando session cookies porque rotação de JWT tinha dado problema. Ou quando você volta a um projeto seis semanas depois e não lembra por que descartou Redis.

Mas não confunda com documentação canônica. Se você fez uma pesquisa importante que não quer perder, peça pro agente escrever um markdown em docs/ dentro do projeto. Decisão arquitetural, benchmark, análise de biblioteca, runbook de deploy, tudo que precisa sobreviver com garantia deve virar arquivo explícito no repo. Isso é mais simples, auditável e versionado.

O ai-memory cobre a faixa intermediária: informação transitória que talvez importe depois. Um bug estranho que apareceu. Um raciocínio que levou a uma decisão. Um gotcha de ambiente. Um resumo de sessão. Coisas que você não quer transformar em doc oficial ainda, mas também não quer jogar fora.

Ele ainda é beta. Eu uso em produção pessoal, mas precisa de muito mais gente batendo nele. Tem integração com Claude Code, Codex e opencode mais polida. Gemini CLI, OpenClaw e clientes MCP exóticos ainda precisam de mais teste. PRs são bem-vindos. Bug report também. “Instalei e quebrou no meu setup” é exatamente o tipo de feedback que revela suposição errada.

ai-usagebar: saber quando trocar de cavalo

Como falei acima, eu prefiro usar os planos subsidiados da Anthropic e da OpenAI. O problema é que, se você faz Agile Vibe Coding de verdade, você bate limite. Limite diário. Limite semanal. Limite de sessão. Limite que muda. Limite que não aparece direito em lugar nenhum.

Eu usava o claudebar, que é bom, mas só cobre Claude. Eu queria ver os principais vendors num lugar só. Daí nasceu o ai-usagebar, que apresentei no post “Criei um Widget de Waybar pra Omarchy pra Monitorar Uso de Planos de LLM: ai-usagebar”.

É um widget de Waybar e uma TUI em Rust pra monitorar uso de Anthropic Claude, OpenAI Codex/ChatGPT, Z.AI GLM e OpenRouter. Pra Claude e OpenAI, ele lê as credenciais OAuth que os CLIs oficiais já gravaram. Pra Z.AI e OpenRouter, usa API key. Mostra porcentagem da sessão, reset, limites, saldo, e permite trocar o vendor principal.

O valor disso é banal e por isso mesmo útil: bato o olho na barra e sei se devo continuar no Claude, fazer handoff pro Codex, ou recarregar crédito no OpenRouter. Não quero descobrir que cheguei no limite semanal no meio de uma refatoração grande.

Também tem a TUI standalone:

Se você não usa Omarchy, Hyprland ou Waybar, ainda dá pra rodar ai-usagebar-tui em qualquer terminal. SSH, tmux, terminal normal, tanto faz. A barra é conveniência. A TUI é a forma universal.

ghpending: pendência de GitHub sem ritual

Depois da maratona, fiquei com dezenas de ai-* e frank-* no GitHub. Isso cria um problema chato: issues e pull requests começam a aparecer. Contribuidor abre PR. Alguém reporta bug. Outro manda sugestão. Se eu tiver que abrir o navegador, entrar repo por repo, filtrar aba por aba, eu vou adiar. E se eu adiar, fico semanas sem responder.

Sim, eu poderia usar gh, a CLI oficial do GitHub. Aliás, uso. Mas eu queria uma coisa mais burra e mais rápida: um comando curto pra imprimir um digest de tudo que está pendente nos repos que eu escolhi monitorar. Nasceu o ghpending, que descrevi no post “Criei um CLI pra Checar Pendências no Meu GitHub: ghpending”.

É só isso: ghpending add pra escolher repos, ghpending pra ver o digest, ghpending list, ghpending rm. Sem autenticação funciona com limite de 60 req/h do GitHub. Com GITHUB_TOKEN=$(gh auth token) ghpending, sobe pra 5.000 req/h.

O ponto não é substituir o GitHub. É reduzir atrito. Se eu consigo rodar um comando no terminal e ver “tem 3 PRs e 2 issues pra olhar”, eu olho. Se depende de ritual de navegador, notificações e abas, fica pra depois.

E Claude/Codex são muito bons nesse tipo de trabalho. Dá pra pedir:

“Checa os pull requests abertos, revisa o código, vê se compila, roda os testes, adiciona teste se faltar, faz rebase de master se precisar, mergeia e fecha.”

Ou:

“Checa as issues abertas, avalia se tem bug real, reproduz se der, propõe correção, responde o usuário.”

Eles leem o PR, entendem o diff, rodam teste, fazem rebase, resolvem conflito simples, escrevem resposta pro contribuidor. Não é pra desligar o cérebro. É pra terceirizar o trabalho mecânico que você já sabe fazer.

Refatoração: peça explicitamente, várias vezes

Claude e Codex são muito bons em refatorar, mas não presuma que vão fazer isso automaticamente do jeito que você faria. Eu costumo começar projetos ou features com instruções explícitas:

“Use as melhores práticas de Rust. Evite duplicação desnecessária. Modularize só onde fizer sentido. Adicione unit tests pra toda feature nova. Siga princípios de Clean Code. Não crie abstração antes de precisar.”

Depois de uma feature grande, uma correção grande, ou algumas horas de desenvolvimento, paro e peço:

“Agora que mexemos bastante no código, reavalie com calma. Delete código morto. Refatore duplicações óbvias. Adicione testes faltantes. Remova magic numbers. Veja se tem módulos grandes demais. Não mude comportamento sem teste.”

Antes de release:

“Antes de publicar essa versão, faça uma auditoria de sanidade. Procure vazamento de secrets, permissões perigosas, comandos destrutivos, path traversal, unwraps desnecessários, falta de validação, e qualquer coisa que pareça vulnerabilidade óbvia.”

Isso garante segurança? Claro que não. Nem perto. Mas remove muito erro besta. É mais uma camada. Eu gosto de rodar essa auditoria com Claude e depois com Codex, porque cada um acha coisas diferentes. Mesmo assim, bug passa. Segurança é processo, não ritual mágico.

Experimentos descartáveis: código ficou barato

Antes de escolher biblioteca, framework, arquitetura, modelo ou serviço, eu gosto de criar experiments/.

Exemplo:

“Antes de escolher entre Qwen e DeepSeek, cria um protótipo descartável em experiments/ pra A/B test. Documenta a análise em docs/ com resultado, custo, latência, qualidade e recomendação.”

Isso mudou meu jeito de decidir. Antes, muita decisão de engenharia virava opinião, feeling, fé em benchmark dos outros. Agora código é barato. Peço pro agente fazer duas ou três versões, rodar teste, medir, documentar, jogar fora o que não presta.

Prototipar ficou rápido de verdade. O Frank Karaoke é um bom exemplo: transformar YouTube num app de karaokê era o tipo de ideia que antes eu talvez deixasse numa lista mental por meses, esperando “um fim de semana livre” que nunca chega. Agora dá pra abrir um experiments/, pedir um protótipo tosco, testar o caminho técnico, e decidir se vale virar projeto. Olha meus outros posts de 2026 sobre os projetos frank-* e ai-*: quase todos começaram assim, como código descartável que provou alguma coisa antes de merecer nome.

Mas protótipo barato não significa one-shot. Já escrevi em “Por que as LLMs não te dão o resultado esperado”: prompt bom é conversa iterativa. Você dá contexto, mostra referência, aponta restrição, lê o resultado, corrige direção, manda refazer. Se você joga uma frase vaga e espera produto pronto, o erro é seu.

Também aprendi isso apanhando. No post do Frank Yomik contei meu primeiro fracasso real com vibe coding: quando a direção está errada, insistir no mesmo prompt só cava o buraco. Tem hora que precisa reduzir escopo, isolar o problema, criar teste, trocar estratégia. LLM não transforma plano ruim em engenharia boa.

E tem domínio onde você precisa estudar junto. No post de Driveclub e shadPS4, a IA quase me levou pra todo lado errado porque o problema exigia entender renderização, gamma, shaders, buffers. A ferramenta ajuda a explorar, mas quem decide se a explicação faz sentido ainda é você. Se você não entende o suficiente pra verificar, está só aceitando chute bonito.

Por isso também repito a ideia de “Software Nunca Está Pronto”: deploy não é linha de chegada. O protótipo vira produto quando aguenta bug report, manutenção, refatoração, docs, release, rollback, usuário reclamando. LLM ajuda muito nesse ciclo chato. Mas o ciclo continua existindo.

Se é testável, teste. Se dá pra medir, meça. Se não dá pra medir, pelo menos escreva as premissas. O importante é não escolher só porque “parece melhor”.

Código barato também significa desapego. Faça código pra jogar fora. Faça protótipo feio. Faça benchmark descartável. Peça pro agente documentar o que aprendeu em docs/decision-qwen-vs-deepseek.md, depois apague experiments/ se quiser. O documento fica. O aprendizado fica.

LLMs também são muito bons em documentação. Use isso. Peça pra documentar tudo. Por que escolhemos PostgreSQL em vez de SQLite nesse caso. Por que o deploy usa Docker image multi-stage. Por que o serviço roda atrás de Cloudflare Tunnel. Por que aquele sysctl existe. Mesmo que depois você delete metade, o custo de escrever caiu perto de zero.

Deploy automatizado ou você vai parar de manter

Todo projeto meu que importa tem build automatizado. Muitos rodam no meu homelab, como descrevi em “Migrando meu Home Server com Claude Code”. Quase todo projeto tem um bin/deploy que builda imagem Docker, faz push, rotaciona no servidor, aplica migração se precisar, e valida healthcheck.

Claude e Codex são excelentes em deploy. Eles leem o bin/deploy, entendem Dockerfile, editam GitHub Actions, ajustam release workflow, corrigem assinatura de binário, atualizam Homebrew tap, geram checksum. E sim, eu peço pra Claude/Codex dar SSH no meu homelab e redeployar container Docker. Eles são muito bons nisso. O ai-jail, por exemplo, tem GitHub Actions pra buildar binários assinados pra Linux e macOS.

Se você tem dezenas de projetos, quanto mais automatizado melhor. Eu raramente digito comando administrativo no terminal sozinho. Peço pro LLM fazer, observo, aprovo o que for perigoso, e depois peço:

“Documente o que foi feito e por que foi feito.”

Isso vale pro homelab e pra minha workstation. Meu Omarchy é customizado via Claude: ZSH, Hyprland, Waybar, scripts, atalhos, temas, integrações. Até meus setups de gaming/emulação entram nessa, como mostrei no post dos retrogames de corrida rodando no Distrobox. Esse é um caso onde normalmente não uso ai-jail, porque justamente quero mexer no host. Então olho comandos, leio diffs, aprovo devagar. Mesmo assim, nunca tive o agente quebrando meu sistema de um jeito irrecuperável. Pelo contrário. Meu PC nunca esteve tão estável e documentado.

Dias depois, quando esqueço por que configurei alguma coisa daquele jeito, o contexto está em markdown, Git, ai-memory, ou no próprio histórico do projeto. Eu posso perguntar e o agente tem de onde puxar.

Até este post foi escrito assim

Inclusive, é assim que escrevo estes posts agora. Eu jogo um bloco enorme e bagunçado do meu cérebro no Claude. Peço pra ler posts recentes pra calibrar estilo. Peço pra checar os projetos diretamente e elaborar as partes técnicas. Peço pra usar as screenshots mais recentes, subir pro S3 quando precisa, linkar os posts anteriores, revisar o tom.

Depois eu leio e edito. Corto o que ficou genérico. Troco frase que parece release note. Coloco minhas broncas de volta. O resultado ainda é meu texto, só que agora eu gasto energia no que importa: decidir o que dizer, corrigir nuance, cortar besteira.

“Mas você testou o Pi?”

Toda vez que falo de LLM ou ferramenta de LLM, aparece alguém nos comentários com a mesma pergunta: “mas você testou Pi?”, “mas você testou DeepSeek?”, “mas e o Qwen?”, “mas e o modelo novo que saiu ontem?”. Toda. Santa. Vez.

É irritante pra cacete. E quase sempre vem de três tipos de pessoa: quem não testou nada e quer terceirizar o trabalho, quem já escolheu uma ferramenta e quer que eu valide a escolha dela, ou fanboy que trata vendor de LLM como time de futebol. Todos soam iguais. NPC repetindo diálogo de tutorial.

Engenheiro de software não deveria decidir baseado em opinião dos outros. Nem na minha. Se você escolhe ferramenta porque “o Akita falou”, você entendeu errado. Eu defendo Claude Code e Codex porque usei centenas de horas, em projetos reais, publicando código e post-mortem do que funcionou e do que falhou. E mesmo assim eu não parei em opinião.

Eu criei meu próprio benchmark automatizado: llm-coding-benchmark. Atualizo quando vendor popular solta versão nova. Rodo cenários comparáveis. Publico resultado. Depois ajusto minha opinião baseado nos dados. É por isso que eu tenho segurança pra dizer que, no meu fluxo, Opus e GPT continuam vencendo. Não porque acordei com vontade de defender logo de empresa bilionária.

Se sua primeira reação foi “mas você testou Qwen?”, ótimo. Testa você. Roda o benchmark. Cria cenário melhor. Manda PR. Mostra número. Mostra custo. Mostra latência. Mostra onde falhou. Mostra onde ganhou. Traga dado novo.

Opinião solta é irrelevante. “Pra mim funciona” não escala. “Eu gosto mais” não interessa. “No meu prompt one-shot ele foi melhor” é anedota. Engenharia começa quando dá pra reproduzir, comparar e agir em cima.

Então fica simples: traga dado acionável ou fique quieto. Eu não preciso de torcida organizada de vendor nos comentários. Preciso de gente testando, medindo e contribuindo resultado novo.

Checklist final

Resumo curto, porque este post já ficou grande:

• Foque em Claude Code, Codex ou opencode. Pare de colecionar agente.
• Use Opus 4.7 e GPT 5.5 via planos Pro/Plus/Max quando produtividade diária importa.
• DeepSeek, Kimi e modelos locais são úteis, mas ainda não substituem o fluxo principal.
• Agile Vibe Coding é XP com LLM: testes, Clean Code, CI, pair programming e deploy.
• Use ai-jail quando quiser autonomia do agente com cerca no filesystem.
• Combine ai-jail com permissões perigosas do Claude/Codex quando o projeto estiver protegido por Git.
• Tenha backup de verdade: Btrfs snapshots, restic, NAS, offsite, Git, Bitwarden.
• Revise git add, git diff --cached e pushes pra não vazar secrets.
• Use ai-memory pra contexto transitório e handoff entre agentes.
• Escreva documentação canônica em docs/ quando a informação precisa sobreviver com garantia.
• Use ai-usagebar pra saber quando trocar de Claude pra Codex, ou quando recarregar OpenRouter.
• Use ghpending pra não abandonar issues e PRs.
• Peça refatoração explicitamente depois de features grandes.
• Rode auditoria de segurança antes de release, de preferência com mais de um modelo.
• Crie protótipos descartáveis em experiments/ antes de decidir por fé.
• Se discordar de benchmark, rode o llm-coding-benchmark e traga dado novo.
• Documente decisões em markdown. Código ficou barato. Documentação também.
• Automatize deploy. Se depender de ritual manual, você vai parar de fazer.

No fim, é o mesmo conselho de sempre: ferramenta muda, engenharia não. LLM aumenta a alavanca. Se você já tinha bons hábitos, vai produzir mais. Se não tinha, vai só produzir bagunça mais rápido.

E sim, isso muda a interface do trabalho. Já escrevi sobre isso em “VS Code é o novo Cartão Perfurado”: ficar polindo pixel em editor virou nostalgia de programador velho. A parte difícil agora é escrever intenção direito, revisar execução sem preguiça, medir resultado, jogar fora código barato, e não confundir opinião com dado.

O problema de ter vários planos é acompanhar quanto já gastei de cada um. Eu vinha usando o claudebar, um widget de Waybar que mostra o uso do plano da Anthropic. Gosto dele, mas queria ver todos os meus vendors num lugar só, pra bater o olho e saber onde estou. E não queria encher minha Waybar de widget separado pra cada vendor. Então resolvi fazer o meu: o ai-usagebar.

É um port em Rust do claudebar, drop-in compatível, estendido pra quatro vendors: Anthropic Claude, OpenAI Codex/ChatGPT, Z.AI (GLM) e OpenRouter. Mantém os mesmos parâmetros (--icon, --format, --tooltip-format, etc.), o mesmo tooltip minimalista com borda Pango, e a mesma auto-detecção do tema do Omarchy. A diferença é que agora os quatro vendors aparecem no mesmo lugar, em vez de 865 linhas de bash cuidando de um só.

Como ele autentica em cada vendor

Essa é a parte que vale explicar, porque cada vendor faz diferente. Claude e Codex usam OAuth: os CLIs oficiais (claude e codex) já escreveram as credenciais no disco quando você logou, e o ai-usagebar lê esses mesmos arquivos. Não precisa de variável de ambiente nenhuma, o token até se renova sozinho.

Z.AI e OpenRouter usam API key, então pra esses você precisa setar uma chave (via env var ou inline no config).

A interface além da Waybar

Além do widget na barra, tem uma TUI com abas (ai-usagebar-tui) pra ver tudo de uma vez. Navega com Tab / h / l entre os vendors, atualiza a cada 60s. Dá pra abrir clicando no widget da Waybar, ou rodar direto no terminal (mais sobre isso na próxima seção).

A aba do OpenRouter mostra saldo de crédito, gasto de hoje / semana / mês e o tier:

E tem um overlay de settings pra escolher o vendor primário e colar as API keys sem editar o config na mão:

Não usa Omarchy nem Hyprland? Roda como TUI standalone

O widget de Waybar é opcional. Os dois binários são independentes, então se você não usa Omarchy, nem Hyprland, nem Waybar (ou simplesmente prefere checar o uso de vez em quando em vez de ter na barra o tempo todo), o ai-usagebar-tui funciona como app de terminal totalmente standalone:

ai-usagebar-tui    # abre no seu terminal atual

Roda em qualquer emulador de terminal (Kitty, Alacritty, Foot, Ghostty, etc.), funciona até numa sessão SSH pura, e não depende de compositor nem de feature de window manager. Todos os controles e o overlay de settings funcionam igual. Os mesmos quatro vendors, as mesmas abas:

Uso típico fora do Omarchy: uma checada rápida antes de começar uma sessão longa (“será que tô perto do limite semanal do Claude?”), um monitor num painel de tmux enquanto você programa, ou uma ferramenta só de shell em máquina remota (instala o binário e pronto, sem dependência de Waybar ou Hyprland). A TUI é a forma canônica de ver os quatro vendors de uma vez, independente de você configurar o widget ou não.

Instalação

No Arch tem pacote no AUR, dois sabores:

yay -S ai-usagebar-bin    # binário pré-compilado do GitHub Releases (~5s)
yay -S ai-usagebar        # compila do fonte (~30-60s)

Ou do fonte direto:

cargo build --release
sudo make install                  # → /usr/local/bin
# ou
make install PREFIX=$HOME/.local   # → ~/.local/bin

A config de Waybar recomendada é um único módulo com scroll pra ciclar entre os vendors, e clique pra abrir a TUI:

"custom/aibar": {
    "exec": "ai-usagebar --format '{vendor_short} {session_pct}% · {session_reset}'",
    "return-type": "json",
    "interval": 300,
    "signal": 13,
    "tooltip": true,
    "on-click": "ai-usagebar-tui",
    "on-scroll-up":   "ai-usagebar --cycle-next",
    "on-scroll-down": "ai-usagebar --cycle-prev"
}

Se preferir ver os quatro vendors ao mesmo tempo, dá pra usar um módulo por vendor. O README tem o detalhe completo de config, placeholders de formato, e as variações.

Por que fiz

Esse parecia um projetinho de sábado à noite, então resolvi só fazer. E foi: portar o claudebar pra Rust e adicionar os vendors extras que eu queria foi tranquilo. Saí de uma noite com um widget que faz exatamente o que eu precisava e ainda é mais confiável (testado, modular) do que o shell script original.

Se você usa outros vendors que eu não cobri, ou achar bug, manda issue ou pull request: github.com/akitaonrails/ai-usagebar. É MIT.