Claudex Loop starts from a premise that makes sense: the model that proposes a solution shouldn't be the only one evaluating it. It cross-references Claude Code and Codex to review decisions, pressure-test a plan, and inspect the resulting code. The key is knowing when that second opinion is worth the added time and token spend.
- The project bundles several skills: spot review, flow selection, planning, and build.
- The full flow requires both CLIs installed and authenticated, plus Python 3.10 or higher.
- Plugin installation uses commands prefixed with /claudex-loop:.
- Two models agreeing can still both be wrong. Results need tests.
This tool is part of the living roundup Skills for Claude Code, Codex and Other Code Agents →
What We Reviewed
We cross-referenced the current README, published GitHub issues, and Chase AI’s demo. We have not run our own productivity or cost comparison. The finding counts shown in project demos don’t tell you how much it will save on your repo.
Not Everything Needs the Full Loop
The docs distinguish claudex-route, which helps pick a path, from claudex-loop, which runs the full process. It also includes codex-review and codex-build. That distinction matters: swapping a text snippet and designing a data migration don’t call for the same ceremony.
In the full flow, context is inspected, requirements are resolved, the plan is written, the other provider reviews it, and it’s implemented with follow-up checks. The README ties approvals to the reviewed content via plan and code fingerprints. If what was approved changes, the previous review no longer validates the new version. Official documentation.
| Case | What to Try First | What to Measure |
|---|---|---|
| Small, well-defined change | A spot review | Extra time vs. useful bugs caught |
| New feature with multiple decisions | Acknowledgment and plan review | Assumptions that shift before coding starts |
| Migration, permissions, or sensitive data | Plan, acceptance tests, and final inspection | Reproducible failures and open criteria |
Installation: The Detail That Saves You From Commands That Don’t Exist
The plugin path the author publishes is this:
/plugin marketplace add chaseai-yt/claudex-loop
/plugin install claudex-loop@claudex-loopAfter that, the full-flow command is /claudex-loop:claudex-loop; the selector is /claudex-loop:claudex-route. Manual installation has different paths and aliases. Mixing instructions from both methods is a reliable way to lose half an hour.
The project states no separate API keys are needed: it uses the CLIs’ own authentication. That does NOT make the rounds free. They consume available usage from the accounts or billing configured in each tool. An earlier review confused these two things.
The Author Demos It on Video
The Chase AI demo, in English, starts at the 3:50 mark. It’s especially useful for seeing how the system asks questions before moving forward. Chase maintains the repo: this video explains his proposal, it is not an independent assessment.
What People Who’ve Used It on Real Projects Say
«The loop stops when Codex does.»
He describes an availability problem: running out of Codex usage can interrupt a review already in progress. He proposes alternatives from his fork. His experience is a useful reminder to check both providers’ usage limits before starting a long task, it doesn’t confirm that fix is in the main branch.
«Three issues found running claudex-loop on macOS»
The published report describes prerequisite and path problems during a macOS run. The author himself notes the diagnosis was drafted by Claude. We treat this as a pending report, not three bugs we’ve reproduced ourselves.
ujconsulting also published a review of a derived fork, with observations on restricting commands. Their first clarification matters: some of what they found belongs to that fork, not this repo. Carrying those conclusions over without reading the context would mean charging the project with code it doesn’t have.
What Can Go Wrong Even When Both Models Approve
If both receive a flawed requirement, they can perfect the wrong solution. If no one tests a real integration, they can rubber-stamp a simulation. And if any new objection counts as a win, the process can get longer without getting better.
That’s why I’d pick a task I already know well and track four things: the initial plan, the changes the review triggered, the tests that actually ran, and the token spend. Then I’d classify the findings: proven bug, useful decision, or style preference. The raw number of objections says far less than it looks like.
I also wouldn’t mistake a worktree for a security barrier. Isolating working files helps organize changes; process permissions determine what else they can reach. For an initial test, use a sample repo and check the effective configuration of both CLIs.
My Verdict
Claudex Loop is most convincing when it forces you to nail down what would have been expensive to discover later. A migration condition, a permission boundary, a requirement nobody had written down. There, a second look can pay for several rounds.
I wouldn’t make it a religion. For a small change, start with the spot review. For something significant, keep your own evidence and decide which findings deserve to change the plan. Two models debating don’t replace someone who actually understands the goal.
