Claudex Loop: cross-model plan review and build handoff for Claude Code and Codex

What problem Claudex Loop solves, and who it is for

A single model that writes a plan and then implements it grades its own homework. Claudex Loop exists to break that symmetry. The README states the intent plainly: the host handles requirements and coordination, the other provider challenges the plan with concrete evidence, and the host arbitrates findings, records decisions and keeps the loop bounded. The tagline on the repository is the same idea in one line: whoever built it never grades it.

The audience is narrow and specific. It is for engineers who already pay for and use both Claude Code and Codex, and who work on changes where a wrong plan is expensive. The README lists the full workflow as requiring both CLIs plus Python 3.10 or newer. There is a lighter companion skill, claudex-route, that only recommends a model or performs one scoped handoff and is described as self-contained with no Python dependency. So the repository covers two different appetites: a one-off routing question, and a full plan, review, build and inspection cycle.

What it is not: there is no server, no API key of its own, and no runtime pip packages. It is instruction content plus a Python adapter that shells out to CLIs you already have.

The four phases and the job swap that defines the loop

The README gives a mermaid flowchart and a numbered list that line up. Recon inspects existing code and relevant docs, or researches greenfield assumptions, and produces an assumptions ledger with sources. Requirements resolves decisions that change the outcome, batches independent questions and writes a plan with observable acceptance criteria and proof commands. Plan review has the other provider read the plan and relevant code and return evidence-backed findings, revisiting revisions in the same session, stopping at a round budget or an explicit verdict of APPROVED, REVISE or BLOCKED. Build and inspect authorizes the selected builder to work from the plan, runs proof checks independently, and has the other provider inspect the final changes in a fresh session.

The mechanism that makes this more than a prompt template is the swap. The README's table shows two entry points. Starting in Claude Code, the current Claude session handles requirements and plan, Codex reviews the plan, Claude is the default builder, and a fresh Codex session inspects. Starting in Codex, the roles invert. The builder is chosen with builder=claude or builder=codex, and the inspector always follows the builder choice by using the other provider.

That inversion has a consequence the README calls out directly: if the coordinator takes over fixes after inspection, those new edits need another independent inspection, and with mixed authorship the log records who wrote and reviewed each part. In other words, the loop does not treat the final inspection as a rubber stamp on a diff that later changed.

Two artifacts carry state across the phases. PLAN.md records what to build, and PLAN-REVIEW-LOG.md records findings, dispositions, models, proof and remaining uncertainty. The README says both paths are configurable, and that detailed CLI diagnostics live in a unique directory outside the target checkout, which keeps tool noise out of your repository.

Install and a first real run

The README requires both CLIs installed and authenticated for the full workflow, Python 3.10 or newer for the shared adapter, and no runtime pip packages or separate API keys. It names four commands to check before you start: codex --version, codex login status, claude --version and claude auth status. If any of those fail, the loop has nothing to call.

The primary path is the Claude Code plugin marketplace. Run these two commands inside Claude Code; the README shows them as slash commands, not shell commands.

/plugin marketplace add chaseai-yt/claudex-loop
/plugin install claudex-loop@claudex-loop

After installation the README lists four entry points: /claudex-loop:claudex-route for a lightweight recommendation or one-off handoff, and /claudex-loop:claudex-loop, /claudex-loop:codex-review or /claudex-loop:codex-build for the existing workflows. The README notes you can enable marketplace auto-update in the plugin menu.

For Codex, or for a manual install, the README says to clone the repository and copy all skill directories together, because the compatibility commands share the runtime inside claudex-loop and copying an alias alone is insufficient. If you want only the routing skill, the README gives a smaller path: copy skills/claudex-route/ into ~/.agents/skills/ for Codex or ~/.claude/skills/ for Claude Code, with no other skill required. The README's own bash snippet begins by creating both directories.

mkdir -p ~/.agents/skills ~/.claude/

Your first real use should be a plan you actually care about. Ask for the full loop, let the other provider return findings, and read PLAN-REVIEW-LOG.md before authorizing the build. The README is explicit that a request to review a plan does not authorize implementation, so the approval step is a real gate rather than a formality. The README does not document a rollback procedure for a build that goes wrong, so treat your normal version control as the safety net.

Where the loop breaks down

The hard dependency is the first limitation. The README states both CLIs must be installed and authenticated for the full cross-provider workflow. On a machine with only Claude Code, claudex-loop has no reviewer and no inspector. The routing skill still works, but a delegated run there also requires the selected CLI and account access, so even the light path can end at a login prompt.

The second constraint is the round budget. Plan review revisits revisions in the same session and stops at that budget or at an explicit verdict. Nothing in the README suggests the budget adapts to how contested the plan is. A plan with genuinely unresolved trade-offs can hit the ceiling with the verdict still at REVISE, and the README does not describe what happens next beyond the host arbitrating and recording the decision.

The third is model selection. The README tells you to use Claude Fable 5.1 and GPT-6 Astra when selected and available on your accounts, or to retain each CLI's configured model. It also warns that the host UI selection does not automatically change the other CLI's configuration, that requested and observed model information is recorded separately, and that there is no silent model or provider fallback. That is a good design for auditability and an annoying one in practice: if the other CLI is pointed at a model you did not intend, the loop will tell you rather than fix it, and you have to go configure that CLI yourself.

Finally, this is the wrong tool for small changes. A one-line fix does not need an assumptions ledger, a plan with proof commands, a cross-provider review and a fresh-session inspection. The README itself keeps claudex-route separate for exactly the cases where a recommendation or a single handoff is enough.

Claudex Route as the alternative inside the same repository

The most useful comparison is not against another product but against the other skill in the same repo. Claudex Route recommends a model and a role with a short reason: stay with the current agent, get a second opinion on a plan or implementation, investigate a blocker, or delegate a bounded task. It can perform one handoff when requested. The README is careful about what that means: recommendations alone do not launch another model or authorize edits.

The difference in approach is the amount of machinery. Route is a self-contained instruction skill with no Python dependency, and the README says it does not use the full loop's approval-binding runner. Loop is the opposite: it adds the runner, the round budget, the verdict vocabulary, the two log files and the requirement that edits after an inspection get inspected again. Route answers who should do this. Loop answers whether the plan is good, whether the build matches it, and who signed off on each part.

The README's example prompts show the granularity Route is built for, such as asking who should handle a CSV import feature with cost prioritized, or asking for a model to diagnose a failing test read-only. It also notes that staying with your current model is a valid result, which is the honest answer for a lot of tasks. If you find yourself running Route constantly and never Loop, that is a signal your changes are small enough that the full workflow is overhead.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-06. There are no releases listed, so there is no tagged version to pin and no changelog to read between upgrades. Installation is from the default branch: the plugin marketplace command, or a clone plus a copy of the skill directories. That means an update is whatever has landed on main since your last copy, and the README does not document a rollback path. If you install manually, keeping the clone under version control yourself is the only way to see what changed.

The licence situation needs care. The repository ships a LICENSE file and the README badge reads MIT, but the metadata reports NOASSERTION, meaning the licence could not be confirmed automatically. Read LICENSE directly rather than trusting the badge, and note that the README's install instructions copy skill directories into ~/.agents/skills/ and ~/.claude/skills/ on your machine, which is distribution of that content. Nothing here is legal advice; the point is that the badge and the metadata disagree, and only the file settles it.

Upgrade cost has two parts. The skill files are cheap to refresh. The expensive part is behavioural: a change to the verdict vocabulary, the round budget or the log format would invalidate PLAN-REVIEW-LOG.md entries you already wrote, and the README documents no migration for those files. The runtime reference at skills/claudex-loop/references/runtime.md is where tested CLI versions and permission boundaries live, so that is the file to diff first when the CLIs themselves update.

Editorial conclusion

Adopt Claudex Loop if you already run both Claude Code and Codex, want a written plan with observable acceptance criteria, and accept that the second model reviews the plan and inspects the code rather than writing it. Skip it if only one CLI is authenticated on your machine, or if you want a single agent to plan and build without a handoff, because the loop has no meaning without two providers. Before relying on it, check the four version and auth commands the README lists, confirm where PLAN.md and PLAN-REVIEW-LOG.md will be written in your checkout, and read skills/claudex-loop/references/runtime.md for the tested CLI versions and permission boundaries. The repository has no releases, so there is no versioned upgrade path to fall back on.

Frequently asked questions

Official sources

1. chaseai-yt/claudex-loop on GitHub
2. Issues
3. README