Oi, eu sou a Lena. Não estava tentando avaliar nada na primeira vez que li a documentação do oh-my-codex. Eu estava procurando algo mais simples — se o Codex CLI poderia delegar tarefas da mesma forma que eu havia visto em outras configurações de agentes. E me peguei lendo a mesma linha duas vezes: "Seu codex não está sozinho."
Isso é algo estranho de colocar no topo do README de uma ferramenta. Mas acho que é, na verdade, a descrição mais honesta do que oh-my-codex (OMX) tenta ser.
O que o oh-my-codex (OMX) faz
Camada de orquestração para Claude Code e Codex CLI
OMX atua como uma camada de orquestração para o OpenAI Codex CLI, superando suas limitações de execução ao integrar-se com as capacidades do Claude Code. Ele resolve problemas como tempo limite de chamadas de ferramentas através de um sistema de tarefas assíncronas, permitindo que tarefas de longa duração sejam concluídas de maneira confiável. Ao fornecer fluxos de trabalho estruturados para tarefas como desenvolvimento em piloto automático, TDD, revisão de código e planejamento estratégico, o OMX ensina o Codex a delegar efetivamente operações complexas para o Claude Code, facilitando a execução autônoma.
Essa descrição vem do enquadramento da versão v1. A versão 2 do OMX, que é a atualmente ativa, mudou significativamente a arquitetura. OMX v2 é nativo do Codex. O Codex é o executor de primeira linha na v2, e não há ponte Claude nesta versão. O modelo de delegação Claude-para-Codex das versões anteriores foi substituído por uma configuração onde o Codex executa a sessão nativamente, e o trabalho multi-agente acontece por meio de trabalhadores tmux gerados — que podem ser painéis Codex, Claude ou Gemini rodando em paralelo.
Ainda não tenho certeza de como me sinto em relação a essa mudança arquitetural. O apelo original do OMX, para muitas pessoas, era a delegação assíncrona para o Claude Code em tarefas de longa duração. A v2 é um produto diferente em alguns aspectos.
Recursos principais — delegação, piloto automático, integração TDD
O fluxo de trabalho canônico no OMX passa por três pontos de entrada: $deep-interview para esclarecimento antes de qualquer construção, $ralplan para planejamento por consenso com revisão de trade-offs, e $ralph ou $team para execução. O OMX fornece habilidades canônicas invocadas com a sintaxe $skill-name: $team para execução paralela coordenada, $ralph para modo de persistência que continua funcionando até que os objetivos sejam verificados como completos, $ralplan para planejamento por consenso (Planner → Architect → Critic), e $autopilot para execução totalmente autônoma da ideia até o QA.
Vale a pena pausar na camada de estado persistente. O OMX vem com cinco servidores MCP para estado persistente e memória, um HUD ao vivo para monitorar a atividade dos agentes e um sistema de hooks para estender o comportamento em pontos-chave do ciclo de vida. Ele suporta equipes com provedores mistos, onde trabalhadores Codex, Claude e Gemini executam lado a lado, cada um em sua própria árvore de trabalho.
Voltei e olhei a estrutura de diretórios .omx/ que a documentação descreve: planos, logs, memória, sessões, estado, artefatos da equipe. Isso é muito requisito estrutural para entender antes da primeira execução real.
Como o OMX muda o fluxo de trabalho do agente
Delegação de tarefas — dividindo o trabalho em partes do tamanho do agente
É aqui que a filosofia de design do OMX se torna mais clara. Em vez de dar ao Codex uma tarefa grande e esperar que ele permaneça coerente através de dezenas de edições de arquivos, o OMX decompõe o trabalho em partes estruturadas e revisáveis antes de iniciar a execução.
O pipeline de fluxo de trabalho central, conforme mostrado nas demonstrações oficiais, começa com a classificação de intenção e uma entrevista profunda para reduzir a ambiguidade antes da execução. A orquestração de múltiplos agentes via tmux gera trabalhadores paralelos em árvores git isoladas em .omx/team/<n>/worktrees/worker-N, prevenindo conflitos de escrita durante edições simultâneas.
O detalhe do isolamento da árvore de trabalho importa mais do que parece. Qualquer pessoa que já teve execuções paralelas de agentes sobrescrevendo as alterações uns dos outros — especialmente em grandes refatorações — reconhecerá isso como uma escolha de engenharia genuína, não um ponto de marketing.
O efeito prático: em vez de uma única sessão do Codex tentando manter contexto em toda a mudança de código, você obtém trabalhadores especializados com branches isoladas, cada um responsável por uma fatia delimitada. O agente líder integra seus resultados e lida com conflitos.
Modo piloto automático — quando usar e quando não usar
O piloto automático continua automaticamente através de etapas claras, de baixo risco e reversíveis, perguntando apenas quando a próxima etapa representa um desvio significativo, destrutivo ou dependente de preferência.
Essa declaração de política do autopilot SKILL.md é uma das descrições mais honestas de como esses modos devem funcionar. Não é "o piloto automático roda para sempre" — é "o piloto automático roda até atingir um ponto de decisão que requer julgamento humano."
Na prática, isso significa que o piloto automático é bem adequado para implementação de funcionalidades onde a especificação é clara e a base de código é familiar. É menos adequado para trabalho exploratório, requisitos ambíguos ou bases de código que você nunca viu. **Se a etapa da entrevista profunda revelar muitos desconhecidos, isso é um sinal de que o piloto automático não é o ponto de entrada correto ainda.
Percebi — e posso estar interpretando demais — que as ferramentas parecem projetadas para empurrar os usuários em direção ao $deep-interview primeiro, mesmo quando eles acham que sabem o que querem. A classificação de intenção acontece antes da execução. Essa pausa forçada é deliberada.
TDD como limite para agentes — testes antes do código
A integração TDD no OMX não é apenas uma sugestão de fluxo de trabalho. Está mais próxima de uma restrição rígida. A habilidade de desenvolvimento orientado a testes (TDD) reforça o ciclo clássico RED-GREEN-REFACTOR — escreva um teste que falhe, veja-o falhar, escreva o código mínimo, veja-o passar e então faça o commit. Se o Claude tentar escrever código antes dos testes, a habilidade faz com que ele apague o código e recomece. Sem exceções.
Esta é realmente a parte que mais me surpreendeu quando olhei cuidadosamente para o OMX pela primeira vez. A maioria das configurações de agente trata o teste como algo que acontece após a implementação. O OMX trata os testes como a camada de especificação que restringe a implementação. Isso é uma diferença arquitetural significativa, não apenas uma preferência de fluxo de trabalho.
A implicação prática: se você estiver trabalhando em uma base de código sem infraestrutura de testes, a aplicação do TDD pelo OMX cria atrito. Se você já tiver um conjunto de testes, ele se torna um verdadeiro controle de qualidade, e não uma ideia secundária.
OMX vs Superpowers
Escopos diferentes — orquestração vs restrições de comportamento
Esta é a pergunta que eu continuava vendo surgir nas discussões de desenvolvedores, e acho que merece uma resposta direta em vez de um vago "são ferramentas diferentes".
Superpowers, o plugin Claude Code de Jesse Luehrs, foca em restringir o comportamento do agente dentro de uma sessão. O Plugin Superpowers introduz uma fase de planejamento antes da execução — em vez de deixar o modelo começar imediatamente a escrever código, ele primeiro produz um plano estruturado de quais arquivos será alterados, quais mudanças serão feitas e em que ordem. Você revisa e aprova esse plano antes de qualquer código ser escrito.
OMX, por outro lado, foca na infraestrutura de execução. O HUD, o isolamento do worktree, os servidores de estado MCP, a criação de times multi-provedores — estes são recursos do ambiente de execução, não recursos de restrição de comportamento.
Uma forma de pensar sobre a diferença: Superpowers torna um agente único mais inteligente e disciplinado dentro de uma sessão. OMX faz um sistema multi-agente funcionar de forma confiável através de sessões com estado persistente.
Eles podem funcionar juntos?
Provavelmente sim, em princípio. Não há nada estruturalmente incompatível. Mas vale ser honesto: combinar duas camadas de orquestração adiciona complexidade que pode não ser necessária para a maioria dos fluxos de trabalho. Se seu ponto de dor é um único agente seguindo na direção errada, o Superpowers resolve isso diretamente. Se seu ponto de dor é coordenar trabalho paralelo entre múltiplos agentes com estado isolado, o OMX resolve isso. Usar ambos simultaneamente significa entender os dois, o que por si só já é um overhead.
Ainda não estou pronto para emitir um veredito. Eu gostaria de observar o comportamento em mais sessões antes de recomendar uma configuração combinada.
O Que a Orquestração Não Resolve
Delegação sem memória — tarefas concluídas, aprendizado evapora
Aqui está a parte que chamou minha atenção de uma forma que eu não esperava.
O OMX possui estado persistente — o diretório .omx/ armazena gráficos de tarefas, artefatos de sessão, arquivos de memória. Mas estado persistente não é o mesmo que herança de capacidade. O estado registra o que aconteceu. Ele não embala como um problema difícil foi resolvido em algo que um agente diferente — ou o mesmo agente em um projeto diferente — possa herdar.
Um trabalhador conclui uma reformulação complexa de autenticação. A tarefa é marcada como concluída. Os artefatos são registrados. O próximo agente que enfrentar um problema de autenticação similar, em outro projeto ou mesmo na mesma base de código três meses depois, começa de uma posição aproximadamente igual à do primeiro. O caminho de raciocínio arduamente conquistado não é preservado como um ativo reutilizável. Ele está nos logs, se é que está em algum lugar.
Sem herança de capacidade entre agentes delegados
Esta é a lacuna que está fora do que o OMX, ou a maioria das ferramentas de orquestração, atualmente resolve. A orquestração controla como o trabalho é executado. A herança de capacidade abordaria como a solução de problemas bem-sucedida se acumula ao longo do tempo.
A documentação do protocolo EvoMap GEP descreve essa distinção explicitamente — empacotando caminhos de execução bem-sucedidos como ativos verificáveis e compartilháveis que outros agentes podem adotar, em vez de deixá-los nos logs de sessão. Se essa abordagem se mostra durável na prática ainda é uma questão em aberto para mim. Mas o problema que ela aponta é real.
O OMX é honesto sobre seu escopo: é melhor roteamento de tarefas, melhor fluxo de trabalho, melhor execução. Essa definição, diretamente do repositório oh-my-codex no GitHub, é precisa. Não afirma resolver transferência de aprendizado. Afirma tornar a execução mais confiável e coordenada. São problemas diferentes.
Limites e Compromissos
Algumas coisas importantes a saber antes da instalação:
Restrições da plataforma. O OMX é projetado principalmente e ajustado ativamente para macOS ou Linux com o Codex CLI. Windows nativo e o Codex App não são a experiência padrão, podem apresentar falhas ou comportamentos inconsistentes e atualmente recebem menos suporte.
A curva de aprendizado é real. O requisito do tmux, a estrutura de diretórios .omx/, a sintaxe de skill, os papéis dos agentes — esta não é uma ferramenta que você aprende em dez minutos. A documentação é detalhada, mas detalhada não é o mesmo que acessível.
Sobrecarga de contexto. Injetar AGENTS.md, prompts de skill e contexto do servidor MCP em cada sessão consome tokens antes de qualquer trabalho real começar. Para tarefas simples e contidas, essa sobrecarga pode custar mais do que a orquestração economiza. O OMX se justifica em trabalhos complexos e multi-arquivo.
Diferença de arquitetura entre v1 e v2. Se você leu textos antigos do OMX descrevendo Claude Code como o motor principal de execução com o Codex delegando a ele — esse é o modelo v1. A versão atual inverte essa relação. Vale a pena conferir a documentação oficial do OMX sobre a arquitetura atual antes de investir tempo na configuração.
FAQ
O que é oh-my-codex (OMX)?
OMX é uma camada de orquestração open-source para o OpenAI Codex CLI. Ele adiciona coordenação de equipe multi-agente, estado persistente via servidores MCP, fluxos de trabalho estruturados (autopilot, TDD, planejamento) e um HUD de monitoramento ao vivo sobre o Codex padrão. Ele mantém o Codex como motor de execução em vez de substituí-lo.
Como o oh-my-codex funciona com Claude Code?
Na v2, a relação é diferente da v1. Em vez de delegar tarefas de longa duração do Codex para Claude Code via um sistema de jobs assíncronos, o OMX agora suporta equipes de fornecedores mistos, onde trabalhadores Claude (ou Gemini) operam em painéis tmux separados ao lado de trabalhadores Codex. Cada trabalhador recebe um worktree git isolado. A arquitetura é compatível com Claude Code através do projeto irmão oh-my-claudecode, que aplica o mesmo padrão de orquestração especificamente ao Claude Code.
Qual é a diferença entre oh-my-codex e Superpowers?
Superpowers restringe o comportamento do agente durante uma sessão — planejamento antes de codificar, aplicação de TDD, ciclos de revisão estruturados. OMX fornece infraestrutura em tempo de execução — isolamento de worktree, coordenação multi-agente, estado persistente, monitoramento via HUD. Superpowers torna um agente mais inteligente. OMX faz um sistema de agentes funcionar de forma confiável. Os escopos são diferentes o suficiente para que compará-los diretamente perca o sentido.
O oh-my-codex dá suporte a fluxos de trabalho TDD?
Sim. A habilidade TDD aplica o ciclo red-green-refactor como uma restrição rígida, não como uma sugestão. Os testes devem ser escritos antes do código de implementação. Se o agente tentar escrever a implementação primeiro, a habilidade força a exclusão e o recomeço. Isso se aplica especificamente no caminho de fluxo de trabalho $tdd.
Os agentes do oh-my-codex podem lembrar o que aprenderam?
OMX mantém estado persistente — logs de sessão, artefatos de tarefas, arquivos de memória de projeto em .omx/. Um agente pode recuperar o contexto de sessões anteriores dentro do mesmo projeto. O que ele não faz é empacotar caminhos de resolução de problemas bem-sucedidos como capacidades transferíveis que possam ser herdadas por diferentes agentes em diferentes projetos. Essa distinção — entre persistência de estado e herança de capacidades — é onde as ferramentas de orquestração atuais geralmente param.
Continuarei observando como a arquitetura v2 se estabiliza. Há uma parte de mim que ainda está um pouco incerta se a mudança do modelo de delegação Claude foi a troca certa — ou apenas a necessária.
Postagens anteriores:
👉 Se você quer um modelo mental mais claro de onde a orquestração se encaixa na pilha de agentes, leia: OpenHarness e GEP: As Três Camadas da Pilha de Agentes
👉 Para um olhar mais profundo sobre por que sistemas de execução não resolvem a transferência de aprendizado: ARC-AGI-3 e a Lacuna de Aprendizado dos Agentes: O Que Ainda Falta
👉 Se você está comparando estado persistente vs reutilização real de capacidades entre agentes: Habilidades de Agentes vs Ativos GEP: O Que Realmente É Transferido Entre Agentes
👉 Para entender como sistemas de memória diferem do verdadeiro aprendizado entre sessões: Agente Hermes vs EvoMap: Memória vs Herança de Capacidades
👉 E se você está explorando se os agentes podem evoluir além das camadas de orquestração: EvoSkills: Os Agentes Realmente Podem Se Melhorar ao Longo do Tempo?
