Claude Codex Duo: saving Claude tokens for planning while Codex does the heavy lifting.

The Problem: Claude tokens burn on the wrong part of the SDLC

Claude Code reasons well. It can convert a vague requirement into a clean architecture decision, catch the edge case that will break production, and write acceptance criteria precise enough to test against.

The problem starts when Claude also implements. Each file read, rewrite, error log, and test run fills the context. In a large task, the session becomes implementation noise - and the original requirement drifts out of focus.

The fix is not to use Claude less. It is to use Claude differently: keep it on planning, supervision, and review, and hand the implementation to a model built for that job.

Use Claude as the engineering lead, not the entire engineering team.Field note · 2026

The 6-step workflow

Preview

Step 1 - Claude Plans. Claude receives the requirement and produces a structured technical plan: scope, architecture decisions, acceptance criteria, and subtask breakdown. This is where Claude's reasoning value is highest.

Step 2 - Developer Reviews (Iterative). The developer reads the plan and pushes back. Assumptions get challenged. Scope gets tightened. Claude refines until the plan is approved. No code is written at this stage.

Step 3 - Claude writes the Plan document and Implementation Tracker. Claude produces two artifacts: a Plan document the Codex subagent will read as its source of truth, and an Implementation Tracker listing each subtask, its assigned subagent, and its current status.

Step 4 - Claude spawns Codex subagents. Claude creates or resumes the appropriate Codex subagents, passes the Plan document as context, and assigns specific subtasks from the tracker. Each subagent gets a scoped instruction set.

Step 5 - Claude supervises. As Codex returns work, Claude runs tests, checks output against the acceptance criteria, updates the tracker, and requests corrections if the implementation drifted from the plan.

Step 6 - Claude delivers the final summary. Once all subtasks are verified, Claude gives the developer a structured handoff: what was built, which criteria passed, what decisions were made, and any open risks.

Step 2: The developer review loop

Most AI-assisted workflows skip this step. Claude generates a plan and immediately starts coding. That feels fast, but it shifts risk forward - scope assumptions get baked into code before anyone challenged them.

The review step is a deliberate pause. Reviewing a planning document costs almost nothing in Claude tokens compared to fixing a misunderstood implementation. It prevents the most expensive failure mode: building the right code for the wrong requirement.

The loop is intentional. The developer may send the plan back two or three times before approving it. The goal is to make the Plan document specific enough that when Codex reads it, there is no ambiguity left to fill with a guess.

This step also keeps the developer in control. They approved the plan. They know what will be built. If something goes wrong, the root cause is traceable back to a specific decision in the approved document.

Step 3: Plan document and Implementation Tracker

The Plan document is not a summary - it is a specification: goal, scope boundary, architecture approach, expected file changes, and acceptance criteria. This is what Codex reads as its source of truth. A vague plan produces a guessing subagent.

The Implementation Tracker is a companion file. It lists each subtask, the Codex subagent responsible for it, and its status: pending, in-progress, verified, or blocked. Claude updates it as work completes. At any point during the workflow the developer can check it to see exactly where the implementation stands.

Both documents live in the project alongside the code. They are the coordination layer between Claude and Codex - and the audit trail if anything goes wrong.

Step 4: Setting up Codex subagents

Start by installing the Codex skill in your Claude Code session:

Then define subagents under `./.codex/agents/`. Each agent file is a TOML config that gives Codex its role, model, and instruction set. The example below is a backend developer agent - it receives Claude's approved plan and owns all backend file changes. Note the model field: `gpt-5-codex` is Codex's implementation-optimised model, which is significantly cheaper per token than Claude.

The critical constraint in the instructions is the last line: return a summary, do not make autonomous architecture decisions. If a subagent hits a blocker it cannot resolve within its scope, it escalates - it does not redesign.

/plugin marketplace add skills-directory/skill-codex
/plugin install skill-codex@skill-codex

name = "backend-developer"
description = "Implements backend changes from Claude's approved technical plan."
model = "gpt-5-codex"

instructions = """
You are responsible for implementation only.

Follow Claude's technical plan exactly.
Do not redesign the architecture.
Do not expand scope without instruction.
Update relevant tests.

Return:
1. Files changed
2. Key implementation decisions
3. Tests added or updated
4. Any blockers or assumptions
"""

Step 5: CLAUDE.md as the orchestration contract

Without a persistent instruction source, Claude can drift back into direct implementation mode mid-session. A CLAUDE.md file at the project root fixes this - it tells Claude how to behave as an orchestrator across every session, not just the first one.

The contract below defines Claude's role, what to avoid, what Codex subagents are responsible for, and the exact six-step default workflow. Drop this into your project root and Claude will reference it every time a new task starts.

# Claude + Codex Orchestration Rules

## Claude's primary role
- Plan the implementation
- Preserve the original requirement
- Break work into scoped subtasks
- Delegate implementation to Codex subagents
- Review Codex output against acceptance criteria
- Request corrections when output does not match the plan
- Deliver a final summary to the developer

## Claude should avoid
- Large direct implementation loops
- Rewriting many files manually in a single session
- Spending context on repetitive code edits
- Losing the original plan inside logs and diffs

## Codex subagents should
- Implement scoped tasks only
- Follow the provided Plan document exactly
- Avoid architecture changes unless explicitly instructed
- Update tests as part of the implementation
- Return concise summaries: files changed, decisions made, blockers

## Default workflow
1. Claude receives the requirement and creates the technical plan.
2. Developer reviews and approves the plan (iterate until approved).
3. Claude writes the Plan document and Implementation Tracker.
4. Claude spawns Codex subagents and assigns subtasks.
5. Claude reviews each Codex output, runs tests, updates the tracker.
6. Claude delivers the final summary to the developer.

Overengineering Warning: the tradeoffs of orchestration

This pattern is not always necessary. For a small bug fix, Claude alone is faster. The overhead of planning documents and subagent setup pays off on larger feature work: multi-file changes, new modules, refactors with broad scope.

The common failure modes are predictable. A vague Plan document produces a guessing subagent. A subagent given too wide a scope changes more than requested. A shallow Claude review misses implementation drift. Starting with more than two subagents creates unnecessary coordination complexity.

The discipline that prevents all of them is the same: Claude plans with enough detail that Codex has no reason to guess, Codex executes within scope, and Claude verifies against acceptance criteria - not just that the build passes.

• Keep subagent scope narrow - one clear responsibility per agent.
• Plan with enough specificity that Codex has nothing left to interpret.
• Always verify against acceptance criteria, not just build success.
• Start with one subagent. Add more only when the first two work cleanly.
• If Codex hits a blocker, it escalates to Claude - never lets the subagent redesign.

Conclusion: right model, right part of the SDLC

Claude tokens are expensive because they carry high-level reasoning: requirements, architecture decisions, tradeoffs, and acceptance criteria. Spending them on file edits and test reruns is the wrong allocation.

Codex tokens are cheaper and built for implementation. Let them handle the file changes, refactoring, test generation, and repetitive code work.

The Claude Codex Duo pattern puts each model in its strongest position. Claude orchestrates. Codex executes. The developer approves the plan before the first line of code is written and receives a clean structured summary after the last one is verified.

That is the practical takeaway: not one AI assistant doing everything, but a supervised two-model system where the developer stays in the loop at the two moments that matter most - plan approval and final review.