Oh My OpenAgent: quais casos de uso reais ele resolve?

Fala aí, beleza? Tem um depoimento circulando nos materiais do projeto que diz o seguinte: 8.000 warnings do ESLint derrubados em UM dia

É o tipo de frase que ou te faz revirar os olhos ou te faz abrir o backlog pra conferir se você tem uma pilha parecida esperando 😀

O Oh My OpenAgent se apresenta como um harness de agente para bases de código complexas, e os cenários que ele divulga não são "escreva uma função pra mim", são tarefas de volume e de duração

Então bora percorrer os casos que o próprio projeto coloca na vitrine, com o que dá pra checar na documentação por trás de cada um, pra você comparar com o que já está parado no seu repositório

O que é o Oh My OpenAgent antes dos casos de uso

Antes dos cenários, o mínimo de contexto, senão nada faz sentido

O projeto vive no repositório code-yeongyu/oh-my-openagent e se descreve assim, na descrição oficial: "omo/lazycodex: The coding agent for tokenmaxxers; the one and only agent harness for complex codebases. For your Codex, for your OpenCode"

Se liga na palavra harness: ele não é um agente solto que você abre e conversa, ele é a camada que empacota agentes, hooks e modos em cima de um host que você já roda

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Se você conhece plugin de editor, a ideia é próxima disso: o host continua sendo o Codex ou o OpenCode, e o omo entra por cima organizando a bagunça

O pacote no npm se chama oh-my-openagent, está na versão 4.19.4, tem licença MIT e traz code-yeongyu como autor

E ele vem em três edições do mesmo produto:

Os comandos, direto:

# edição Light, pro Codex CLI
npx lazycodex-ai install

# edição Senpi (nativa), ainda em beta
npm i -g omo-ai@beta

Também dá pra instalar de dentro do próprio Codex: digita /plugins, abre a aba Add Marketplace, informa https://github.com/code-yeongyu/lazycodex e instala o omo pelo marketplace sisyphuslabs

Tome cuidado! A documentação avisa pra NÃO instalar o pacote npm chamado só "omo": ele é de outro autor e não tem relação nenhuma com o projeto

Um detalhe que muda o cálculo dos casos de uso: o projeto roteia tarefas entre vários provedores de modelo em vez de ficar preso a um só, e cita oficialmente Claude, GPT, Gemini, Kimi, GLM e Minimax

Os casos de uso que o projeto apresenta

Agora sim, os cenários

Um aviso antes, porque isso importa: dois dos três casos abaixo são relatos reais de uso divulgados pelo projeto, e relato não é benchmark

Ou seja: dá pra ver o que a pessoa diz que fez, mas não tem repositório público, log ou medição que permita reproduzir os números do lado de cá

Lint em massa: os 8.000 warnings do ESLint

O depoimento é atribuído a Jacob Ferrari: "Knocked out 8000 eslint warnings with Oh My Opencode, just in a day"

Por que justo lint virou o caso-vitrine? Porque é o formato mais amigável que existe pra um agente autônomo

Cada warning é pequeno, tem localização exata, tem critério objetivo de sucesso (o linter passa ou não passa) e nenhum deles depende do outro

Isso é o oposto de "refatore a arquitetura": aqui não tem decisão de produto no meio, tem repetição

E repetição é o terreno do modo ultrawork, que a documentação descreve como execução paralela agressiva de todos os agentes disponíveis até a conclusão da tarefa, com disciplina "outcome-first, evidence-bound"

Traduzindo a disciplina: o resultado é que manda, e cada afirmação precisa estar amarrada em evidência, não no "acho que arrumei"

Se você já brincou com casos de uso reais do OpenClaw, a lógica de fundo é a mesma: tarefa fatiável e verificável é onde agente rende

Migração: o app Tauri de 45 mil linhas

O segundo depoimento é mais ambicioso: "I converted a 45k line tauri app into a SaaS web app overnight using Ohmyopencode and ralph loop"

Ou seja, um app desktop de 45 mil linhas convertido em SaaS web durante a noite

De novo: isso é relato de usuário publicado pelo projeto, não é medição nossa e não tem código aberto pra você conferir

Mas dá pra entender por que esse cenário aparece na vitrine

Migração é uma mudança que atravessa a base inteira, com padrão repetido em centenas de arquivos e um critério de pronto que existe (compila, roda, os testes passam)

O trabalho não é difícil arquivo a arquivo, ele é grande no total

E grande no total é exatamente o que não cabe numa sessão de chat com você babá do agente

Tarefas longas: ulw-loop, goals.json e o /goal

Aqui a gente sai do depoimento e entra na documentação, que é o pedaço mais verificável dos três

O componente ulw-loop mantém arquivos de estado pra sustentar tarefa longa:

• .omo/ulw-loop/goals.json guarda critérios de sucesso e objetivos
• .omo/ulw-loop/ledger.jsonl é uma trilha de auditoria append-only de cada pass, fail, block e checkpoint

Para que serve isso? Pra tarefa longa não virar amnésia

O agente sabe o que é "pronto" porque está escrito, e deixa rastro do que tentou, do que falhou e do que travou

Tem ainda o /goal, que segura um objetivo persistente por sessão: quando ligado e iniciado, ele reinjeta um prompt de continuação a cada ociosidade, até uma auditoria de conclusão confirmar que o trabalho acabou

Detalhe que muita gente vai esbarrar: goal.enabled e goal.auto_start têm valor padrão false

Ou seja, isso não está ligado na sua instalação por acidente, você liga de propósito

Como saber se o seu backlog se parece com esses cenários

Agora a parte útil: como usar esses casos como régua de triagem em vez de hype

Olhando os três cenários, o padrão que se repete é este:

1. Volume alto e repetitivo: muitos itens iguais, cada um pequeno, com critério objetivo de pronto (o caso do lint)
2. Mudança que atravessa a base inteira: mesmo padrão aplicado em dezenas ou centenas de arquivos, sem decisão nova a cada arquivo (o caso da migração)
3. Tarefa que não cabe numa sessão: precisa de estado persistido pra sobreviver ao tempo, e é aí que entram goals.json e ledger.jsonl

Se a sua tarefa não cai em nenhuma das três, sinceramente? Você provavelmente resolve mais rápido na mão do que montando harness

O que a edição Ultimate coloca à disposição nesses cenários são 11 agentes, mais de 54 lifecycle hooks, 5 MCPs embutidos, todos os slash commands e o Team Mode

Os 11 se dividem assim: os primários são Sisyphus (orquestrador principal), Hephaestus (worker autônomo), Prometheus (planejador) e Atlas (orquestrador de todo-list)

Os subagentes são Oracle (arquitetura e debug), Librarian (busca em docs e código externo), Explore (grep rápido na base), Multimodal-Looker (visão e PDF), Metis (consultor de pré-planejamento), Momus (revisor de plano) e Sisyphus-Junior (executor delegado)

E COMO você dispara os modos? Por palavra-chave no prompt

O IntentGate é um injetor por regex que detecta ultrawork ou ulw, team mode (nas variantes team-mode, team_mode, teammode), hyperplan e a combinação hyperplan-ultrawork, e injeta as instruções do modo correspondente

Isso é bem prático e tem um efeito colateral óbvio: escrever a palavra errada significa rodar sem o modo que você achava que tinha ligado

Vale a mesma leitura fria que a gente faz em o que o Hermes Agent resolve: a lista de recursos é grande, mas o que decide é o formato da SUA tarefa

Onde esses casos de uso ainda tropeçam

Bora pro lado chato, porque entrar cego nisso dói

O primeiro ponto é o mais importante pra quem se empolgou com o cenário de tarefa longa: existem issues abertas relatando que o loop autônomo nem sempre para sozinho

A issue #2489 diz "ulw-loop sometimes doesn’t stop, even when the agent’s task is already completed", e a #3362 diz "In ULW mode, the model may continuously loop"

Ou seja, o mesmo mecanismo que sustenta a tarefa longa é o que pode continuar rodando depois que ela terminou

O segundo ponto é histórico do projeto: ele nasceu como oh-my-opencode e foi renomeado para oh-my-openagent na versão 3.11.0, cujas notas de release dizem "This is a first release as an oh-my-openagent"

A renomeação quebrou configurações existentes de usuários e virou a issue #2823, "Package rename from oh-my-opencode to oh-my-openagent breaks existing configurations"

Se você seguir tutorial antigo achando que é a mesma coisa, esse é o erro que vai te pegar

O terceiro ponto é simples: a edição Senpi, a nativa, ainda está em beta

Então o veredito honesto fica assim

Vale o risco em tarefa repetitiva, verificável e de baixo custo de erro, aquela em que o linter, o compilador ou o teste te dizem na cara se deu certo

Não vale em mudança crítica sem cobertura de teste, em produção, ou em qualquer coisa onde "o loop rodou a mais" custe caro pra desfazer

Conclusão

Os casos que o Oh My OpenAgent divulga têm um denominador comum: são tarefas de VOLUME e de DURAÇÃO, não tarefinha pequena

8.000 warnings do ESLint num dia e um app Tauri de 45 mil linhas virando SaaS web durante a noite são relatos de uso publicados pelo projeto, não benchmark reproduzível, e é justo tratar os dois com essa régua

O que é documentado e checável é a maquinaria por trás: ultrawork em paralelo, o ulw-loop com critérios em goals.json e trilha em ledger.jsonl, e o /goal que vem desligado por padrão

Próximo passo concreto, se você quiser experimentar sem se ferrar:

1. Escolha UMA tarefa repetitiva e de baixo risco do seu backlog, de preferência com critério automático de pronto (lint, formatação, teste que já existe)
2. Instale a edição que combina com o host que você já roda, tipo npx lazycodex-ai install pro Codex, ou a instalação pelo marketplace via /plugins de dentro do próprio Codex
3. O erro comum deste passo: instalar o pacote npm chamado só "omo", que é de outro autor e não tem relação com o projeto
4. Acompanhe o ledger.jsonl enquanto a coisa roda, pra ver o que passou, o que falhou e onde travou, ANTES de soltar o loop em algo crítico

Depois volta aqui e conta se o seu backlog se pareceu com os cenários da vitrine ou não =)

até o próximo post!