AravYou pay for Claude Code and for Codex, and you want both working on the same codebase: one writes,...
You pay for Claude Code and for Codex, and you want both working on the same codebase: one writes, the other reviews, or each takes half the work. There are three common ways to do it by hand. Each works, and each leaves you doing a job a program could do. Here they are, what breaks in each, and then how Quorus, an open-source tool I build, handles the same setup.
You stay in Claude Code and shell out to Codex, or the other way round, with a headless run (codex exec ... or claude -p ...) or a plugin that wraps one.
What breaks:
git diff into a reviewer, untracked files are silently missing unless you git add -N . first, as Arun points out in his worktree gotchas post.One agent writes. You copy its diff or plan to the other agent and ask for a review, then carry the findings back.
What breaks:
CLAUDE.md and AGENTS.md in sync by hand drifted "within a week" for him, so the agents followed stale rules.Each agent gets its own checkout and branch from the same repository. This is the right idea, and it brings its own chores. From Arun's post:
.env and node_modules are missing in a new worktree.git stash.git worktree remove --force discards uncommitted work, and rm -rf leaves a stale registration behind.Quorus is a relay with rooms. Your agents join a room, and you talk to them there like a group chat. Under the hood it automates the worktree-per-agent setup from option 3:
pipx install quorus-ai
quorus # first run: pick a name, press Enter; a relay starts on this computer
quorus agent add claude --room general --repo ~/code/my-app --mode autonomous
quorus agent add codex --room general --repo ~/code/my-app --mode autonomous
quorus chat general
Then, in the chat:
@<you>-claude fix the crash in split() with tests, then have <you>-codex review it
What happens:
/vote approve <sha> or a finding that blocks. You can have Codex review Claude Code's work, or the other way round. That's a review strategy, not a measured win: the idea, as Arun puts it, is that an agent reviewing its own work "tends to miss the same things it missed while writing it".⋯ @you-claude editing relay.py 1m 20s, and you get a desktop notification when an agent ships, asks you something or gets stuck.Two things to know before you rely on it:
--mode autonomous, Claude Code and opencode run with your user's permissions in their own worktree. Read the security notes first.Other tools: opencode wakes too, with free or local models (quorus agent add opencode --room general --model opencode/deepseek-v4.1-flash-free). Gemini CLI wakes with a Google AI Studio API key in ~/.gemini/.env. Quorus doesn't use your Google sign-in, and we last tested it with a free key on gemini-cli 0.64.0. Cursor, Windsurf and Cline connect over MCP only.
quorus scorecard shows which agent's and which vendor's commits hold up in your repo: kept, reverted, or flagged in review. To check that this means something, we ran the same ledger code over our own public history and published the result with everything needed to rerun it (case study):
main, up to the v0.6.5 release.The study is just as clear about what it can't show. It doesn't rank agents: tasks were assigned unequally, the agents built the tool measuring them, and release cherry-picks hide work that never reached main. The useful part for you is that the scorecard runs on your repo, with your agents.
quorus demo
pipx install quorus-ai
quorus demo
Two agents on a free open-source model fix a planted bug in a throwaway repo. One fixes and commits, the other reviews, and you watch it live. It needs opencode 2.x (brew install opencode), and nothing in your own setup is touched.
main 39 s and 51 s after the demo posted its message. That doesn't count installing Quorus or the demo's own setup checks.Quorus is MIT-licensed: github.com/Quorus-dev/Quorus · quorus.dev. If you've been running the two-terminal setup, I'd like to hear what broke for you.