Two Models, One Branch

Two models on one branch. Claude writes the code and ships the PR; Codex reviews with fresh eyes. No agent framework, no MCP plumbing — just one CLI call from inside the editor. The simplest agent orchestration that actually works.

Two Models, One Branch — AI

A fresh reviewer can catch assumptions the author carries into a change. That is the value of peer review: a separate examination of the same requirements and implementation, with enough context to test the author’s conclusions.

The same principle is useful for AI-assisted development. Self-review can help, but a fresh context or a different model may find other errors. Neither separation nor agreement establishes statistically independent failure modes.

The fix is unsexy and one CLI call long: when Claude finishes a change, hand the diff to a different model running in a different process. Then read what comes back and apply the parts that matter.

The setup

Two pieces, no agent framework:

The writer implements the change, runs the relevant tests and prepares a reviewable diff. This example uses Claude Code, but the handoff does not depend on a particular writer model.

The reviewer uses a separate context and a constrained tool policy. The following illustrative Codex configuration uses a read-only sandbox; choose a supported model and reasoning setting explicitly.

model = "gpt-6-astra"
model_reasoning_effort = "ultra"
approval_policy = "never"
sandbox_mode = "read-only"

The reviewer’s intended role is not a permission boundary. Restrict tools and credentials to the evidence it needs, because repository text can contain untrusted instructions. Approval policy never means a required approval will not be granted; it does not make otherwise forbidden actions permitted. Capture the answer through the controller rather than granting broad write access.

The handoff

Claude Code's slash command system makes the bridge trivial. A skill file at .claude/commands/codex-review.md defines the trigger phrases ("do codex review", "second opinion from codex", "/codex-review") and the workflow steps. When the user types any variant, Claude composes a focused review prompt and runs:

codex exec \
  --model gpt-6-astra \
  -c 'model_reasoning_effort="ultra"' \
  -c 'approval_policy="never"' \
  --sandbox read-only \
  --output-last-message "$OUT" - < "$PROMPT"

Put the complete review brief in PROMPT, including the exact base and head revisions, the diff and the requirements. Reading a file through stdin avoids shell interpolation of the prompt. Heredocs are another valid stdin mechanism; this example does not imply that multiline prompts inherently hang the CLI.

The controller starts a fresh process, checks its exit status and captures the final answer in OUT. Retain the model configuration and exact input revision with the report. Review duration depends on the workload; a completed model invocation is not proof that the change is correct.

No MCP server. No HTTP plumbing. No agent framework with role definitions and inter-agent message buses. Just two CLIs and a markdown file as the contract between them.

The format

Require each finding to state severity, the exact file and lines, triggering conditions, failure behavior, impact and a proposed correction.

Where a CLI handoff fits

Agent frameworks can help with complex state and coordination. A one-shot review handoff may need only a defined input, a separate review context and a structured result.

Choose the orchestration mechanism that makes those boundaries easy to inspect. A framework and a shell controller can both preserve separate contexts; neither creates independence by its name.

  • A fresh review context receives complete authorized evidence.
  • The input identifies requirements and exact revisions.
  • The result identifies concrete failures and supporting reasoning.
  • The accountable reviewer verifies findings before deciding.

One CLI call and a report file can provide that interface for a bounded task. A more complex workflow may justify queues, persistent state or another orchestration system. Evaluate that complexity against actual requirements.

A different model or provider can add diversity, but correlated errors remain possible. Ask the reviewer to identify concrete failure cases, then verify each finding against the code and acceptance criteria.

What it actually feels like

An illustrative handoff looks like this:

1. Claude finishes a feature, runs tests, opens a PR. Reports the summary.

2. You type "do codex review" — three words, no menu, no UI.

3. The controller prepares the complete evidence packet and starts a separate review with the required permissions.

4. The reviewer returns findings with locations, triggering conditions and supporting reasoning. The author verifies them before making changes.

5. The author addresses accepted findings, runs relevant checks and submits the changed revision for any required follow-up review.

6. CI re-runs. You read the concise summary. You merge or you push back.

The interface can be brief while the evidence and validation remain substantial.

Total context switches: zero. You never left the editor. You never opened a second tool. The reviewer is literally another process on the same machine, called by the writer, returning a file. The orchestration layer is the operating system.

Reviewing other people's PRs

The codex-review skill reviews work I just wrote. The natural next move is reviewing work I did not write — pull requests by other people on the team.

A team PR queue is a real bottleneck. Five PRs at fifteen to thirty minutes of focused reading each is over an hour of attention. Most of that hour is reading unfamiliar code, comparing it against the spec, and looking for the failure modes the author and CI both missed.

A second skill file at .claude/commands/review-prs.md handles this. Trigger phrases: "review these PRs <list>", "review this PR <link>", "review PRs 187 191 192", or "/review-prs <list>". The skill takes a list of PR numbers or URLs and fans out independent reviews.

For each PR, two reviews run in parallel:

🤖
Claude agent — reads the diff, walks affected files in the local checkout, and writes findings in the same severity-cited-fix format. Independent context per PR.
🧠
Codex CLI — same diff, same prompt shape, different model, different process. Runs concurrently with the Claude agent in the background.
⚡
Parallel reviews can reduce elapsed time when capacity permits. Limit concurrency, retain one evidence packet per revision, and report failed or incomplete review jobs instead of silently treating them as passes.

After the fan-out finishes, the orchestrator consolidates per PR. Findings both reviewers raised at the same file:line count once (sharper wording wins). Severity disagreements default to higher, then verify the claim against the actual code before accepting. Drop noise-tier suggestions. Skip anything an existing reviewer already raised verbatim in the PR thread.

Choose the PR verdict only after checking the requirements and resolving material questions. For an authorized publication step, gh pr review --comment --body-file "$REPORT" reads the prepared report file; use --approve only when approval is justified. A lack of high-severity findings does not by itself establish readiness.

Write the review in clear technical prose with concrete evidence and locations. Follow the team’s disclosure policy for AI assistance. Do not word a report to create a false impression that someone manually performed checks they did not perform.

The accountable reviewer remains responsible for validating findings and the final verdict. Helpful automation reduces collection and analysis work; it does not transfer that responsibility to a model.

Keep a record of the reviewed revision, actual checks and unresolved limits. Before submitting an approval, confirm that the report still applies to the current PR head and that the publishing action is authorized.

Where this leaves you

The principle generalizes far beyond code review. Any task where you want a fresh independent perspective from a different model — security audit, design critique, copy editing, architecture review, math verification, translation cross-check — fits the same pattern:

  1. Define the trigger phrase as a Claude Code skill
  2. Configure the second model's CLI globally with the right defaults (reasoning effort, sandbox mode, approval policy)
  3. Have the skill compose a focused prompt and write it to disk
  4. Invoke the second CLI with the prompt, capture markdown output to a file
  5. Read the file, prioritize, act
  6. Report back to the user in a single concise summary

Master agent + worker agent over CLI. The master is the orchestrator that the human talks to. The worker is the specialist that does the cold task. The handoff is a markdown file. The protocol is the prompt. The framework is the operating system.

This is not a startup. It is not a framework. It is not even a library. It is a hundred-line skill file that anyone using Claude Code can write tonight. The unsexy version of multi-agent that actually ships.

The shape of the thing

The temptation when you have a hammer that is this powerful — Claude Code Opus 4.7 max effort with full agentic permissions — is to make it do everything. Write the code. Review the code. Test the code. Decide if the code is good enough. Merge the code.

A fresh review is an additional check, not a correctness certificate. Give the reviewer complete evidence, constrain its tools, and reconcile its conclusions with tests and the requirements.

Two models. One branch. One CLI call between them.

That is the shape of the thing.

Related Reading

  • Evaluating Opus 4.7 and Claude Code Quality Reports — Separate model behavior from client regressions, verify reported failures, and measure completed-task quality using the April 2026 postmortem and reproducible evidence.
  • The Loop Files Its Own Work — How an autonomous coding loop can discover missing work, track dependencies and verify live behavior. A hypothetical architecture with explicit authority, budgets and completion checks.
  • The Review Is Automated — the Decision Isn't — Two independent model passes consolidated into one PR comment, review queues that run on a schedule, and human judgment moved earlier — to the spec. How I actually review code now.
  • Opus 4.8 Would Rather Tell You It Failed — Opus 4.8 made reliability and self-reporting part of the launch story. How to evaluate those claims alongside workflow orchestration, latency and cost.
  • Sinapt: One Cockpit for the AI-Native Operator — A product concept for connecting coding agents, an editor and a shared knowledge layer. The article explores integration requirements and the boundaries a prototype would need to test.
  • The Cockpit — A separate workspace can hold personal agent configuration and coordinate several repositories. Keep authoritative team knowledge in approved shared storage and respect each repository’s rules.
  • KISS Your AI Workflow — Keep the AI workflow as simple as its requirements allow. Add orchestration, retrieval and automation for demonstrated needs while preserving useful checks and review.
  • The Re-Soloing — AI can help an individual complete broader implementation tasks. Evaluate that benefit alongside integration, review, ownership and the collaboration a project still requires.
  • The Architect's Protocol — A practical architecture for AI-assisted engineering: maintained Markdown knowledge, explicit task context, versioned decisions, and review of generated work.
  • Grok Build — Evaluate Grok Build through model quality, native configuration, planning limits and parallel-task coordination. Shared file discovery does not prove identical behavior.
  • Codex Mobile — Use Codex remotely from a paired mobile device. Host-level access uses the selected environment’s tools and permissions; isolation depends on configuration.
  • When a Review Comment Becomes an Agent Action — A review comment can suggest work without authorizing it. How to distinguish scope errors from prompt injection and enforce an agent’s action boundary.
  • Fable 5: Mythos on a Leash — Fable 5 exposed Mythos-class capability with additional safeguards. Understand retention, opt-in API fallback, model routing and the difference between launch terms and current access.
  • Mythos on a Federal Leash — The June 2026 Fable 5 suspension exposed an engineering dependency: hosted-model access can change abruptly. What happened, what remains unproven, and how to design continuity.
  • The Human Is Not the Runtime — Automating PR-review handoffs through repository-state reconciliation while retaining human acceptance.
  • The Slash Is Load-Bearing — claude agents and /agents are different products solving opposite problems, and the slash command stopped doing what every tutorial says. Five ways Claude Code runs more than one thing at once, what each really costs, and the one cleanup behaviour that will delete someone's work.

Read more