Three editions target OpenCode, Codex, and Senpi
oh-my-openagent has become a family rather than one plugin. Ultimate loads into OpenCode and supplies 11 agent roles, lifecycle hooks, commands, Team Mode, and built-in MCP services. Light installs a narrower set of Codex-native components, agents, hooks, and MCP policies. Senpi packages the extension with a standalone runtime, but the README labels that edition beta. Choosing the host comes before choosing models or agents.
This breadth has a visible cost. Our checkout contained 18,004 files, about 1,700,418 source lines, and 351.3 MB before installation. It is a workspace monorepo with 11 CI workflow files and a tests directory. There is no Dockerfile. The project is working through a package-layering refactor intended to separate core TypeScript, MCP servers, skills, adapters, platform launchers, and the web application across several harnesses.
Ultimate gives OpenCode the complete agent system
Ultimate is the path for users who want the full design. Sisyphus delegates to model-specific agents, Team Mode can place parallel workers in tmux, and ultrawork activates a persistent workflow. Other pieces add language-server actions, AST-based search, project-rule injection, background delegation, planning interviews, and MCP-backed web or documentation search. The value is coordination and opinionated model assignment, not a new model.
Installation begins with bunx oh-my-openagent install and requires OpenCode 1.4.0 or newer. The setup asks which subscriptions are available because each of 11 agents has its own provider fallback chain. Provider logins remain part of the host setup. The current naming transition adds friction: published packages still include old names, the short omo binary belongs to the beta Senpi edition, and an unrelated npm package also uses omo.
What happened when we ran it
Our sandbox installed 595 packages in 70 seconds and occupied 3,058 MB on disk. Building commit b48ab10 succeeded in 38 seconds. The test step did not complete before the 900-second limit, so the correct result is a timeout rather than a pass or a failed assertion. The environment was an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no provider secrets.
The final test lines were still green. They showed passing cross-process lock cases and passing memory compilation cases, including repeatable identity metadata and handling of a dirty persona edit. No failure appeared in that tail, and there was no complete suite count. It would be guesswork to blame a particular test or dependency. A buyer should budget for a long full-suite check and capture the eventual endpoint on its own CI hardware.
Codex Light writes hooks, agents, and permission settings
Light installs through npx lazycodex-ai install. It copies a versioned plugin into ~/.codex/plugins/cache, writes agent TOMLs under ~/.codex/agents, links component commands, and edits ~/.codex/config.toml. Those components cover rules, comment checks, Git Bash, language-server access, ultrawork continuation, telemetry, Team Mode, and several MCP policies. Native Windows also needs Git Bash discovery to succeed.
The optional autonomous setting deserves a separate decision. When accepted, the installer writes an approval policy of never, selects danger-full-access, and enables network access. It also configures multi-agent concurrency and trusted hook hashes. These settings let long jobs proceed with fewer interruptions, while increasing what a mistaken instruction or faulty hook can change. Review the generated diff and use an isolated account or container before granting those permissions to a production checkout.
Persistent work can keep spending without progress
Open issue 7392 describes a Codex Light ultrawork job that repeatedly created evidence and review work while its strict completion count stayed unchanged. The reporter says manual intervention was needed to stop the expansion. The report lacks a small deterministic reproduction, so it does not prove that every long run loops. It does show the failure mode that matters most for a system designed to continue after the user leaves.
Our own 900-second timeout concerned the repository test command, not an autonomous coding task. Still, both results argue for operating limits. Set a time budget, token or cost ceiling, maximum worker count, and a no-progress rule outside the agent's own plan. Require source changes and real test evidence before another review lane opens. Persistent execution is only useful when an independent mechanism can decide that persistence has stopped paying off.
The license rules out some commercial uses
GitHub did not identify a standard SPDX license. The repository's Sustainable Use License permits internal business, personal, and non-commercial use, but restricts distribution to free non-commercial purposes. A company planning to bundle, resell, or expose OMO as part of a paid product should obtain legal review or permission before adoption. OpenCode and Cline use standard permissive licenses and are easier starting points for that requirement.
The repository had 68,413 stars, 990 combined issues and pull requests, and a last push on August 27, 2026. Release v5.0.0-beta.19 arrived on August 24 during the refactor. Activity is abundant, though maturity is harder to claim while package boundaries, edition names, and installers are changing. For expert users, OMO offers unusually deep orchestration. Its 3,058 MB install, timed-out suite, license, and permission surface make a sandboxed trial mandatory.