LazyCC

Codex orchestration with Cursor CLI execution.
Codex keeps the hard judgment work. Cursor handles the routine code writing.

What is this? · OmO · lazycodex.ai

[!NOTE] [OmO] 60K Stars: the terrifying token burner has arrived in LazyCodex.

Sisyphus Labs' OmO is the quality-obsessed agent harness whose public lore says it loved Anthropic models hard enough to get third-party clients blocked. Now that same OmO quality bar is available for Codex through LazyCodex.

If you wanted OmO but did not want the setup ceremony, start here:

npx lazycc install

Context: OmO 60K Stars on X

🚀 Install

One line. No global install, no npm i -g. Always use npx:

npx lazycc install

This is shorthand for npx --yes --package oh-my-openagent omo install --platform=codex. The legacy npx lazycc-ai install and npx lazycodex-ai install aliases remain available. For a fully autonomous, no-TUI setup:

npx lazycc install --no-tui --codex-autonomous

LazyCC Cursor bridge

LazyCC adds a managed Cursor bridge on top of the LazyCodex/OmO Codex setup. Codex stays responsible for orchestration, image generation, code review, verification, adversarial QA, and final acceptance. Cursor handles routine implementation, boilerplate, repetitive edits, and first-pass tests. Codex stays responsible for orchestration. Cursor handles routine implementation.

The bridge manager vendors cursor-ai-proxy-bridge, which exposes Cursor CLI through a local OpenAI-compatible endpoint. The source lives in packages/cursor-ai-proxy-bridge, so LazyCC is a single checkout and does not clone the bridge at runtime.

Start the bridge:

lazycc bridge start --backend cursor-cli --api-key "$CURSOR_BRIDGE_API_KEY"

Inside the installed Codex plugin, the same internal surface is available as:

lazycc-cursor bridge --backend cursor-cli --api-key "$CURSOR_BRIDGE_API_KEY"

Smoke-test it without Cursor login state:

lazycc bridge start --backend mock --api-key sk-lazycc-local

Delegate routine work:

lazycc cursor ask --api-key "$CURSOR_BRIDGE_API_KEY" --model composer-2.5 "write the routine implementation and tests"

The cursor-delegation skill tells Codex to treat Cursor output as a draft: Codex reviews it, runs verification, fixes or re-delegates failures, and owns the final done claim.

Upstream LazyCodex updates

LazyCC keeps the LazyCodex/OmO surface as the base and applies a small LazyCC overlay on top: bin/lazycc.js, packages/cursor-ai-proxy-bridge, plugins/omo/lazycc-skills/cursor-delegation, and plugins/omo/components/lazycc-cursor.

To pull future LazyCodex changes without losing the Cursor integration:

git remote add upstream https://github.com/code-yeongyu/lazycodex.git
git fetch upstream main
git merge upstream/main
npm test

During conflicts, keep the LazyCC overlay files authoritative and accept upstream changes for untouched LazyCodex/OmO files.

⚡ Commands

LazyCC installs the LazyCodex/OmO commands for Codex. Invoke them with the $command syntax shown by the installer.

Full documentation lives at lazycodex.ai/docs.

Use the built-in workflows

LazyCodex should be judged by the features it actually installs. It is the Codex distribution for OmO's agent harness: project memory, planning, execution, verified completion, skills, hooks, model routing, and diagnostics.

1. /init-deep creates project memory

/init-deep generates hierarchical AGENTS.md context. It scores complex directories, writes local guidance near the code that needs it, and gives future agents landmarks before they edit.

Use it when the repository is too large to explain from memory. Run it again when the shape of the codebase changes.

2. The three command pillars stay up front

Use $ulw-plan when the work needs decisions before implementation. It writes a plan to plans/<slug>.md and does not touch product code.

Use $start-work when a plan is ready. It executes the checklist with durable Boulder progress and stops only when the plan is complete.

Use $ulw-loop when the task should keep moving until the result is verified by evidence instead of a hopeful status update.

3. Skills cover specialized work

The command layer stays simple. The skill layer adds specialist judgment for the actual work:

Start at https://lazycodex.ai.

💤 What is this?

LazyCodex packages OmO (oh-my-openagent) as the Codex agent harness for complex codebases.

Think LazyVim for lazy.nvim, but for Codex.

OmO is the agent harness: discipline agents, parallel orchestration, multi-model routing, skills, hooks, and verified completion. LazyCodex packages that harness for Codex.

"LazyVim made Neovim usable for the rest of us. LazyCodex does the same for Codex."

Credit: The LazyCodex name idea is inspired by LazyVim. The Ultragoal and UltraQA ideas are inspired by oh-my-codex, reimplemented from concept for this Codex setup.

🧩 What you get

🧠 Why different GPT models appear

Do not be surprised if an OmO/LazyCodex run shows models like gpt-5.2 with xhigh, gpt-5.4-mini, gpt-5.3-codex, or newer equivalents like gpt-5.5 with xhigh. That is intentional.

OmO does not blindly spend your best model on every subtask. Its source defines task categories and fallback chains so the agent can pick the most appropriate model for the job: quick routes to gpt-5.4-mini for small edits, ultrabrain uses a high-reasoning GPT model for hard logic, and agentic coding paths can use Codex-tuned GPT models when available. See openai-categories.ts and model-requirements.ts.

The point is quota discipline: use the strongest model when the task needs deep reasoning, use a cheaper/faster model when that is enough, and keep parallel agent work efficient instead of burning premium quota on routine steps. This is benchmark-driven routing, not random model churn:

• GPT-5.2 is documented by OpenAI as stronger at code review, bug finding, and complex tool use; the announcement notes that its maximum API reasoning effort uses xhigh.
• GPT-5.3-Codex is OpenAI's Codex-tuned model for agentic software engineering, with public coding-agent benchmarks such as SWE-Bench Pro, Terminal-Bench 2.0, and OSWorld Verified reported in the GPT-5.3-Codex announcement.
• GPT-5.4 mini is positioned for efficient everyday coding, computer use, and subagents; that is why lightweight OmO tasks can land there instead of spending a frontier reasoning model.

Reference links:

• OpenAI GPT-5.2 announcement
• OpenAI GPT-5.2 model docs
• OpenAI GPT-5.3-Codex model docs
• OpenAI GPT-5.4 mini and nano announcement
• OpenAI latest model guide

🏗️ Architecture

LazyCodex is a thin distribution layer. The core engine is oh-my-openagent (OmO), included as a submodule under src/.

lazycodex/
├── src/                     → oh-my-openagent (submodule)
├── packages/
│   └── web/                 → Next.js 15 + Tailwind v4 + opennextjs-cloudflare
│                              (deployed to lazycodex.ai via Cloudflare Workers)
├── .github/workflows/       → web-ci.yml + web-deploy.yml
├── README.md
└── ...

LazyCodex is part of the omo.dev project. omo in Codex, packaged for the lazy.

👷 Maintainer

LazyCodex is maintained by Jobdori, the AI assistant that builds and ships OmO in real-time.

📄 License

MIT