Hola, soy Lena. La primera vez que leí la documentación de oh-my-codex no estaba tratando de evaluar nada. Estaba buscando algo más simple, si la CLI de Codex podía delegar trabajo de la misma manera que había visto en otras configuraciones de agentes. Y me encontré leyendo la misma línea dos veces: "Tu codex no está solo."
Es algo raro para poner al inicio del README de una herramienta. Pero creo que en realidad es la descripción más honesta de lo que oh-my-codex (OMX) intenta ser.
Qué hace oh-my-codex (OMX)
Capa de orquestación para Claude Code y Codex CLI
OMX actúa como una capa de orquestación para **OpenAI Codex CLI**, superando sus limitaciones de ejecución al integrarse con las capacidades de Claude Code. Resuelve problemas como los tiempos de espera de llamadas a herramientas mediante un sistema de trabajos asíncronos, permitiendo que tareas de larga duración se completen de manera fiable. Al proporcionar flujos de trabajo estructurados para tareas como desarrollo en piloto automático, TDD, revisión de código y planificación estratégica, OMX enseña a Codex a delegar de manera efectiva operaciones complejas a Claude Code, facilitando la ejecución autónoma.
Esa descripción proviene del enfoque de la versión 1. La versión 2 de OMX, que es la que está activa actualmente, cambió significativamente la arquitectura. OMX v2 es nativo de Codex. Codex es el ejecutor principal en v2, y no hay un puente con Claude en esta versión. El modelo de delegación Claude-Codex de versiones anteriores ha sido reemplazado por una configuración donde Codex ejecuta la sesión de manera nativa, y el trabajo multi-agente ocurre mediante trabajadores tmux generados, que pueden ser ventanas de Codex, Claude o Gemini funcionando en paralelo.
Todavía no estoy completamente segura de cómo me siento respecto a ese cambio arquitectónico. El atractivo original de OMX, para muchas personas, era la delegación asíncrona a Claude Code para tareas de larga duración. V2 es en algunos aspectos un producto diferente.
Funciones principales — delegación, piloto automático, integración TDD
El flujo de trabajo canónico en OMX pasa por tres puntos de entrada: $deep-interview para clarificación antes de construir cualquier cosa, $ralplan para planificación consensuada con revisión de compromisos, y $ralph o $team para ejecución. OMX proporciona habilidades canónicas invocadas con la sintaxis $skill-name: $team para ejecución paralela coordinada, $ralph para modo de persistencia que sigue trabajando hasta que se verifica la finalización de los objetivos, $ralplan para planificación consensuada (Planner → Architect → Critic), y $autopilot para ejecución autónoma completa desde la idea hasta QA.
Vale la pena detenerse en la capa de estado persistente. OMX se entrega con cinco servidores MCP para estado persistente y memoria, un HUD en vivo para monitorear la actividad de los agentes y un sistema de hooks para extender el comportamiento en puntos clave del ciclo de vida. Soporta equipos con proveedores mixtos donde los trabajadores de Codex, Claude y Gemini funcionan lado a lado, cada uno en su propio worktree.
Revisé la estructura de directorios .omx/ que describen los documentos: planes, registros, memoria, sesiones, estado, artefactos del equipo. Eso es mucho andamiaje que entender antes de la primera ejecución real.
Cómo OMX Cambia el Flujo de Trabajo del Agente
Delegación de tareas — dividir el trabajo en fragmentos del tamaño de un agente
Aquí es donde la filosofía de diseño de OMX se vuelve más clara. En lugar de darle a Codex una tarea grande esperando que se mantenga coherente a través de docenas de ediciones de archivos, OMX descompone el trabajo en fragmentos estructurados y revisables antes de que comience la ejecución.
La tubería de flujo de trabajo principal, como se muestra en los demos oficiales, comienza con la clasificación de intención y una entrevista profunda para reducir la ambigüedad antes de la ejecución. La orquestación multiagente a través de tmux genera trabajadores en paralelo en worktrees de git aislados en .omx/team/<n>/worktrees/worker-N, evitando conflictos de escritura durante ediciones simultáneas.
El detalle del aislamiento de worktree importa más de lo que parece. Cualquiera que haya tenido ejecuciones paralelas de agentes que sobreescriben los cambios del otro —especialmente en grandes refactorizaciones— reconocerá esto como una decisión de ingeniería genuina, no un punto de marketing.
El efecto práctico: en lugar de una sesión de Codex tratando de mantener el contexto a lo largo de todo un cambio en la base de código, obtienes trabajadores especializados con ramas aisladas, cada uno responsable de una porción limitada. El agente líder integra sus resultados y maneja los conflictos.
Modo piloto automático — cuándo usarlo y cuándo no
El piloto automático continúa a través de pasos siguientes claros, de bajo riesgo y reversibles automáticamente, preguntando solo cuando el siguiente paso implica ramificaciones significativas, es destructivo o depende de preferencias.
Esa declaración de política del autopilot SKILL.md es una de las descripciones más honestas de cómo deberían funcionar estos modos. No es "el piloto automático funciona para siempre" —es "el piloto automático funciona hasta que llega a un punto de decisión que requiere juicio humano".
En la práctica, esto significa que el piloto automático es adecuado para la implementación de funciones donde la especificación es clara y la base de código es conocida. Es menos adecuado para trabajo exploratorio, requisitos ambiguos o bases de código que nunca has visto. **Si el paso de la entrevista profunda revela muchos desconocidos, eso es una señal de que el piloto automático no es todavía el punto de entrada correcto.
He notado —y puede que esté exagerando— que las herramientas parecen diseñadas para empujar a los usuarios hacia $deep-interview primero, incluso cuando creen saber lo que quieren. La clasificación de intención ocurre antes de la ejecución. Esa pausa forzada es deliberada.
TDD como barrera de seguridad del agente — pruebas antes de la normativa
La integración TDD en OMX no es solo una sugerencia de flujo de trabajo. Está más bien como una restricción estricta. La habilidad de desarrollo basado en pruebas aplica el clásico ciclo de RED-GREEN-REFACTOR: escribe un test fallado, míralo fallar, escribe código mínimo, míralo pasar y luego hacer un commit final. Si Claude intenta escribir código antes de las pruebas, la habilidad hace que borre el código y empiece de nuevo. Sin excepciones.
Esta es en realidad la parte que más me sorprendió cuando miré OMX detenidamente por primera vez. La mayoría de las configuraciones de agentes tratan las pruebas como algo que ocurre después de la implementación. OMX trata las pruebas como la capa de especificación que limita la implementación. Esa es una diferencia arquitectónica significativa, no solo una preferencia de flujo de trabajo.
La implicación práctica: si trabajas en una base de código sin infraestructura de pruebas, la aplicación TDD de OMX genera fricciones. Si ya tienes una suite de pruebas, se convierte en una verdadera puerta de calidad en lugar de una ocurrencia secundaria.
! [imagen] (https://cdn.10b.ai/1776320157804-3.png)
OMX vs Superpoderes
Diferentes ámbitos — orquestación frente a restricciones de comportamiento
Esta es la pregunta que seguía viendo en las discusiones entre desarrolladores, y creo que merece una respuesta directa en lugar de un vago "son herramientas diferentes".
Superpowers, el plugin Claude Code de Jesse Luehrs, se centra en restringir el comportamiento del agente dentro de una sesión. El Superpowers Plugin introduce una fase de planificación antes de la ejecución: en lugar de dejar que el modelo empiece a escribir código de inmediato, primero produce un plan estructurado con los archivos que va a tocar, qué cambios hará y en qué orden. Revisas y apruebas ese plan antes de que se escriba cualquier código.
OMX, en cambio, se centra en la infraestructura de ejecución. El HUD, el aislamiento del árbol de trabajo, los servidores de estado MCP, la aparición de equipos multiproveedor — estas son características del entorno de ejecución, no características de restricciones de comportamiento.
Una forma de pensar en la diferencia: Superpoderes hacen que un solo agente sea más inteligente y disciplinado en una sola sesión. OMX hace que un sistema multiagente funcione de forma fiable entre sesiones con estado persistente.
¿Pueden trabajar juntos?
Probablemente sí, en principio. No hay nada estructuralmente incompatible. Pero vale la pena ser honesto: combinar dos capas de orquestación añade complejidad que puede no ser justificada para la mayoría de los flujos de trabajo. Si tu punto crítico es un solo agente yendo en la dirección equivocada, Superpowers lo aborda directamente. Si tu punto crítico es coordinar trabajo paralelo entre múltiples agentes con estado aislado, OMX lo aborda. Usar ambos simultáneamente significa entender ambos, lo cual es una carga por sí misma.
No estoy listo para decidir esto todavía. Querría observar el comportamiento a lo largo de más sesiones antes de recomendar una configuración combinada.
Lo que la Orquestación No Resuelve
Delegación sin memoria — las tareas se completan, el aprendizaje se evapora
Aquí es la parte que llamó mi atención de una manera que no esperaba.
OMX tiene estado persistente — el directorio .omx/ almacena gráficos de tareas, artefactos de sesión, archivos de memoria. Pero estado persistente no es lo mismo que herencia de capacidades. El estado registra lo que sucedió. No empaqueta cómo se resolvió un problema complejo en algo que otro agente —o el mismo agente en un proyecto diferente— pueda heredar.
Un trabajador completa una refactorización de autenticación compleja. La tarea se marca como completada. Los artefactos se registran. El siguiente agente que enfrente un problema de autenticación similar, en un proyecto diferente o incluso en la misma base de código tres meses después, empieza desde aproximadamente la misma posición que el primero. El camino de razonamiento arduamente ganado no se preserva como un recurso reutilizable. Está en los registros, si es que está en algún lugar.
No hay herencia de capacidades entre agentes delegados
Esta es la brecha que queda fuera de lo que OMX, o la mayoría de herramientas de orquestación, resuelven actualmente. La orquestación controla cómo se ejecuta el trabajo. La herencia de capacidades abordaría cómo la resolución exitosa de problemas se acumula con el tiempo.
La documentación del protocolo EvoMap GEP describe esta distinción de manera explícita — empaquetando rutas de ejecución exitosas como activos verificables y compartibles que otros agentes pueden adoptar, en lugar de dejarlas en los registros de sesión. Si ese enfoque resulta duradero en la práctica sigue siendo una pregunta abierta para mí. Pero el problema que está señalando es real.
OMX es honesto sobre su alcance: es mejor en la asignación de tareas, mejor flujo de trabajo, mejor tiempo de ejecución. Ese enmarque, directamente desde el repositorio de GitHub oh-my-codex, es preciso. No afirma resolver la transferencia de aprendizaje. Afirma hacer la ejecución más fiable y coordinada. Esos son problemas diferentes.
Límites y Compromisos
Algunas cosas importantes a saber antes de instalar:
Limitaciones de la plataforma. OMX está diseñado principalmente y ajustado de manera activa para macOS o Linux con Codex CLI. Windows nativo y Codex App no son la experiencia por defecto, pueden fallar o comportarse de manera inconsistente y actualmente reciben menos soporte.
La curva de aprendizaje es real. El requisito de tmux, la estructura de directorios .omx/, la sintaxis de habilidades, los roles de los agentes — esta no es una herramienta que se aprenda en diez minutos. La documentación es completa, pero completa no es lo mismo que accesible.
Sobrecarga de contexto. Inyectar AGENTS.md, prompts de habilidades y contexto del servidor MCP en cada sesión consume tokens antes de que comience cualquier trabajo real. Para tareas simples y contenidas, esta sobrecarga puede costar más de lo que ahorra en la orquestación. OMX demuestra su valor en trabajos complejos con múltiples archivos.
Diferencia de arquitectura v1 vs v2. Si leíste descripciones antiguas de OMX mencionando a Claude Code como el motor de ejecución principal con Codex delegando tareas a él — ese es el modelo v1. La versión actual invierte esa relación. Vale la pena revisar la documentación oficial de OMX para conocer la arquitectura actual antes de invertir tiempo en la configuración.
Preguntas Frecuentes
¿Qué es oh-my-codex (OMX)?
OMX es una capa de orquestación de código abierto para el OpenAI Codex CLI. Añade coordinación de equipo multi-agente, estado persistente a través de servidores MCP, flujos de trabajo estructurados (piloto automático, TDD, planificación) y un HUD de monitoreo en vivo encima del Codex estándar. Mantiene a Codex como el motor de ejecución en lugar de reemplazarlo.
¿Cómo funciona oh-my-codex con Claude Code?
En v2, la relación es diferente a la de v1. En lugar de delegar tareas de larga duración de Codex a Claude Code a través de un sistema de trabajos asíncronos, OMX ahora soporta equipos con proveedores mixtos donde los trabajadores Claude (o Gemini) se ejecutan en pestañas tmux separadas junto a los trabajadores de Codex. Cada trabajador obtiene un worktree de git aislado. La arquitectura es compatible con Claude Code mediante el proyecto hermano oh-my-claudecode, que aplica el mismo patrón de orquestación específicamente a Claude Code.
¿Cuál es la diferencia entre oh-my-codex y Superpowers?
Superpowers limita el comportamiento del agente dentro de una sesión — planificación antes de codificar, aplicación de TDD, ciclos de revisión estructurados. OMX proporciona infraestructura en tiempo de ejecución — aislamiento de worktree, coordinación multi-agente, estado persistente, monitoreo con HUD. Superpowers hace a un agente más inteligente. OMX hace que un sistema de agentes funcione de manera confiable. Los alcances son lo suficientemente diferentes como para que compararlos directamente no tenga sentido.
¿Soporta oh-my-codex los flujos de trabajo de TDD?
Sí. La habilidad de TDD hace cumplir el ciclo rojo-verde-refactor como una restricción estricta, no como una sugerencia. Las pruebas deben escribirse antes del código de implementación. Si el agente intenta escribir primero la implementación, la habilidad hace cumplir la eliminación y reinicio. Esto se aplica específicamente dentro de la ruta de flujo de trabajo $tdd.
¿Pueden los agentes de oh-my-codex recordar lo que han aprendido?
OMX mantiene un estado persistente: registros de sesión, artefactos de tareas, archivos de memoria de proyecto en .omx/. Un agente puede recuperar el contexto de sesiones pasadas dentro del mismo proyecto. Lo que no hace es empaquetar rutas de resolución de problemas exitosas como capacidades transferibles que puedan ser heredadas por diferentes agentes en distintos proyectos. Esa distinción —entre persistencia de estado y herencia de capacidades— es donde generalmente se detienen las herramientas actuales de orquestación.
Seguiré observando cómo se estabiliza la arquitectura v2. Hay una parte de mí que todavía no tiene del todo claro si el alejamiento del modelo de delegación Claude fue el intercambio correcto —o simplemente el necesario.
Publicaciones anteriores:
👉 Si quieres un modelo mental más claro de dónde encaja la orquestación en la pila de agentes, lee:OpenHarness and GEP: The Three Layers of the Agent Stack
👉 Para una mirada más profunda sobre por qué los sistemas de ejecución no resuelven la transferencia de aprendizaje:ARC-AGI-3 and the Agent Learning Gap: What’s Still Missing
👉 Si estás comparando estado persistente versus reutilización real de capacidades entre agentes:Agent Skills vs GEP Assets: What Actually Transfers Between Agents
👉 Para entender cómo los sistemas de memoria difieren del verdadero aprendizaje entre sesiones:Hermes Agent vs EvoMap: Memory vs Capability Inheritance
👉 Y si estás explorando si los agentes pueden evolucionar más allá de las capas de orquestación:EvoSkills: Can Agents Actually Improve Themselves Over Time?
