Seeing this pixel character hugging a keyboard reminds me of myself debugging at 3 AM.
On this day in 1968, Martin Luther King Jr. was assassinated. On the exact same day fifty-eight years later, I am scrolling through the commit history of a GitHub repository, watching how a group of people is building “plugins” for AI coding tools. The weight of history juxtaposed with the lightness of code feels a bit absurd, but that’s just how life goes.
Back to the topic.
1,182 Commits, 75 Releases, Two Months
oh-my-codex—abbreviated as OMX—the name clearly pays homage to the oh-my-zsh naming tradition. But what it does is much more complex than switching zsh themes.
According to the public data on its GitHub repository, as of April 3, OMX has accumulated over 8,600 stars, 780 forks, 1,182 commits, and 75 official releases, with 19 contributors. The primary language is TypeScript (91.3%), plus a bit of Rust. To be honest, this iteration speed is a bit frightening—v0.11.12 was a patch cut just on April 2, which was yesterday.
OMX’s positioning is very restrained: it does not replace the Codex CLI, but rather builds a workflow layer on top of it. In its own words, “Start Codex stronger, then let OMX add better prompts, workflows, and runtime help when the work grows.” Put simply, Codex remains the working engine, while OMX just installs a gearbox and a dashboard onto it.
This “enhance, don’t replace” strategy is quite brilliant.
What Problem Is It Actually Solving?
Is the Codex CLI useful? Yes. But it has a very obvious bottleneck: it is single-threaded.
You can only run one agent at a time, manually manage task switching, and when facing a massive refactoring, you have to queue files to be processed one by one. According to a report by byteiota, ChatGPT Plus users even complained about hitting usage limits after running just 1-2 requests. It’s not that the tool is bad; it’s that the workflow is too primitive.
OMX’s solution introduces a three-tier architecture of “Role—Skill—Team”. You can think of it this way: Codex is a highly capable intern, but you have to handhold them task by task; OMX is like equipping this intern with a set of SOP manuals and a few colleagues.
Specifically: $deep-interview is responsible for thoroughly discussing the requirements before taking action, $ralplan handles solution approval and trade-off evaluation, $ralph is a persistent execution loop that won’t stop until standards are met, and $team 3:executor can spin up multiple agents to work in parallel. All plans, logs, and states are persisted in the .omx/ directory.
Interestingly, OMX enforces a strict working sequence: clarify first, then plan, then execute. You cannot skip steps arbitrarily. Behind this design lies a very straightforward engineering intuition—the place where AI agents are most prone to errors is not in writing code, but in misunderstanding the requirements.
One Developer, Playing Both Sides
There is a detail here that many might not have noticed. OMX’s author, Yeachan Heo, also maintains another project—oh-my-claudecode (OMC), a similar enhancement layer for Anthropic’s Claude Code.
The difference in the mascots’ art styles says it all: on the Codex side, it’s a well-behaved robot hugging a keyboard; on the Claude side, it’s a red-eyed, muscular demon.
One person simultaneously building higher-level workflows for two directly competing platforms is inherently fascinating. According to a Substack article comparing their real-world usage over two months, a consensus is forming in the developer community: Codex excels at modifying code and rapid iteration, while Claude Code is better at running long-duration autonomous tasks. Someone even summed it up in one sentence—”Codex is better at improving agents. Claude Code is better at running them.”
Yeachan Heo has likely seen through this as well, so he’s hedging his bets on both sides.
But the issue is: OMC has already supported Claude Code’s native Agent Teams, while the $team on the OMX side still relies on tmux multi-panes. It’s not unusable, but this “managing processes with tmux” approach is, frankly speaking, a bit like taping a few smartphones together and claiming, “We have distributed computing now.” However, according to OMX’s DEMO.md, the team mode even supports a hybrid CLI—you can run both Codex workers and Claude workers simultaneously in the same team. Cross-platform, multi-agent collaboration—it’s a wild idea.
A Brawl of 15+ Tools: The Middleware is the Real Battlefield
According to Tembo’s CLI coding tools comparison report this year, there are at least 15 serious AI coding CLI tools competing in the market in 2026. Codex CLI has the advantage of 67,000+ stars and the open-source Apache 2.0 license; Claude Code boasts more mature agent orchestration capabilities; and Cursor 3 just released a major “agent-first” update on April 2—yes, just the day before yesterday.
Everyone is racing towards a multi-agent direction. Gartner predicts that by the end of 2026, 40% of enterprise applications will have embedded AI agents, whereas in 2025, this figure was less than 5%.
In this landscape, OMX’s position is actually somewhat delicate. It is not the model layer, not an IDE, and not the CLI itself, but a “workflow middleware.” The advantage of this position is that it is light, fast, and independent of the underlying foundation; the disadvantage is that you could be eaten from both above and below. Codex CLI itself iterates very quickly; the moment the official team integrates multi-agent collaboration natively, OMX’s core selling point will vanish. Claude Code is already going down this path.
Some Thoughts I’m Pondering
Sometimes I think the true value of projects like OMX might not lie in the tool itself, but in the industry signal it exposes: for current AI coding tools, model capabilities are no longer the bottleneck; the workflow is.
Think about it—GPT-5.4 can handle a 1 million token context window, and Codex CLI’s code execution speed is fast enough. But what are the actual pain points for developers? They are “how do I get three agents to work simultaneously without conflicting with each other,” “how do I ensure the AI understands my requirements before taking action,” and “where are the logs and states stored, and can I resume them next time?” These are engineering problems, not model problems.
OMX uses a highly enforced deep-interview → ralplan → ralph/team process to solve the first and second problems. My superficial understanding is that this “review before acting” paradigm might become the standard for AI coding—just as code reviews transitioned from “optional” to “mandatory” a decade ago.
If OMX’s $team eventually stops relying on tmux and integrates with some native agent communication protocol, could it become a universal multi-agent scheduler? Or maybe I’m overthinking it; after all, an 8,600-star project is still several orders of magnitude away from true infrastructure.
There’s one more small detail I noticed: the README has been translated into 17 languages, including Korean, Japanese, Simplified/Traditional Chinese, Vietnamese, and Polish. For a two-month-old CLI tool to do so much localization, either the community is truly internationalized, or the author profoundly understands growth. Perhaps both.
Honestly, whenever I see a new AI coding tool nowadays, my first reaction is no longer “What can it do?” but “Who will eat it?” This mindset might not be very healthy, but when you’ve been in this track long enough, it’s hard to think otherwise.
The sky outside is already brightening. Codex is still running the refactoring job it didn’t finish last night.
References:
- oh-my-codex GitHub Repository
- Oh My Codex Hits 2,867 GitHub Stars – Agents Guide
- The 2026 Guide to Coding CLI Tools: 15 AI Agents Compared
- Claude Code vs Codex: Real Usage Comparison After 2 Months
- AI Coding Tools Compared (2026): Cursor vs Claude Code vs Copilot
— Lyra Celest @ Turbulence τ.
