Choosing and Combining Claude and Codex: A Real Side-by-Side on the Same Task, a Write-One-Review-One Mixed Workflow

Today's Goals

1. Run the same task on both Codex and Claude Code, and record comparable data across four dimensions
2. Explain how the two coding agents differ in project context, approval model, and verification habits, and justify a choice to a team
3. Set up a write-one-review-one mixed workflow, and know when it isn't worth it

Four days in, you know how the OpenAI contractor works. Today we invite the other firm's contractor into the same room, hand over the same job, and watch both of them work. There is only one problem to solve: when someone asks which one your team should use, you can give reasons they can verify rather than saying it feels good to you. Once you have read this and finished the work, scroll back to the top and tick off the three goals.

Plain-Language Walkthrough

Why measure for yourself instead of reading a leaderboard

The two contractors come from different firms and you want to know which suits your team. The lazy route is to read a leaderboard — but a leaderboard measures solving a standardized problem, while your team's work is changing an endpoint inside a repository with years of history, and the gap between the two is wide enough that the leaderboard is essentially uninformative. Worse, a leaderboard reports one score, while what you actually care about day to day is four very concrete things:

Those four have one thing in common: all of them can be measured in your own repository on your own task. So the last day of this course does not give you a conclusion; it gives you a way to measure. The task is the one we have used for five days: add input validation and matching unit tests to a TODO API written with Express or FastAPI — the same task D3 through D5 of the companion Claude course does with Claude Code, so readers of both courses can compare data directly.

Set the rules before measuring, or the data will not be comparable: the same repository starting point (the same commit), the same requirement text, the same content in each side's project instruction file, default permissions on both, and both asked to run the tests before reporting. Those rules are in the lab's record template, and you just fill it in.

The same task through Codex: AGENTS.md, workspace-write, /review, end to end

You already know this side well, and stringing the first four days together gives the whole flow.

Briefing: put the AGENTS.md you wrote on D1 in the project root (validation with zod, tests with vitest, the error response shape), then give codex a requirement:

Add input validation to POST /todos (title a non-empty string of 1-200 characters, done
optional and boolean, a failure returning 400 with { error: string }), and add unit tests
for the POST, GET, and DELETE routes. Use the validation library and test framework from
AGENTS.md. Run pnpm test afterwards and, once green, report in one sentence which files
you changed.

Note the length of that requirement and the length of AGENTS.md — that is your briefing cost.

Approval: the default Auto (workspace-write plus on-request). Reading files, editing files, and running pnpm test are all inside the sandbox and raise nothing; if it decides to install a new dependency, npm install needs the network and raises one prompt. Record how many prompts appeared and why each one did.

Verification: watch whether it really ran pnpm test and whether the output carries the number of passing tests; if the tests went red, did it fix them itself or come back to ask you? This dimension shows the difference between a partner and a typist better than any other.

Cost: wall-clock time from start to report, plus the token usage it reports when the session ends. Afterwards run /review to have it review its own work, and record the number of review comments and how many you agreed with — that is the data the next section needs.

The same task through Claude Code: CLAUDE.md, Plan Mode, permission modes, end to end

Over to the Anthropic contractor. If you have not taken the Claude course, only a few confirmed features are used here, and they are enough to finish the comparison.

Briefing: Claude Code's project instruction file is CLAUDE.md in the repository root, corresponding exactly to AGENTS.md; copy the same content across (/init can generate a draft, but for comparability use the identical text today). The requirement text is unchanged, word for word.

Approval: Claude Code's permission model authorizes by tool type — reading files is allowed by default, while editing files and running commands ask each time by default, and /permissions can allowlist a class of command (pnpm test, say). It also has something with no direct counterpart in Codex: Plan Mode (toggled with Shift+Tab, or started with --permission-mode plan). In that mode it only reads, giving you a plan of how it intends to change things, and starts work only after you approve. For comparability today both sides use default permissions; but in the lab you can do an extra run with Plan Mode to see what the plan-first step does to the number of approvals and the amount of rework.

Verification: again, watch whether it runs the tests on its own initiative. How closely Claude Code follows a rule such as "always run the tests after a change" in CLAUDE.md, against how closely Codex follows the same rule in AGENTS.md, is something you can compare directly.

Cost: again, record wall-clock time and tokens. Claude Code has /context for current context usage, and a usage summary at the end of a session. Afterwards run /code-review to have it review its own work, recording the same data.

With both runs done you hold two run records. Fill them into the JSON template from the lab, and the comparison script generates the table for you.

How to read the comparison: most differences come from ways of working

With the table in hand, the most common misreading is "whoever wrote more tests is stronger." Slow down and read it in this order.

First, check comparability. Is the requirement text identical on both sides? Is the content of the project instruction file identical? Is the starting point the same commit? If any one of those differs, the source of every later difference becomes unexplainable.

Then look at the structural differences, which have nothing to do with model strength. A different number of approvals is mostly the two vendors' different default permission models: Codex draws the boundary with an operating-system sandbox and asks nothing inside it; Claude Code asks per tool type and lets you allowlist. That is not one being safer but two designs — one entrusting safety to runtime limits, the other to a human confirming each time. Different verification behavior mostly comes from where the "always run the tests" sentence sits in the instruction file and how explicitly it is written. For different costs, look first at how much of the token count is input — high input means it read more files, which may mean more caution, or may mean the instruction file never told it where to look.

Only last, look at capability differences. Given the same requirement, if one side's tests cover the edge case of a title longer than 200 characters and the other's do not, that is a capability-level difference — and it takes several runs to confirm, because a coding agent's output is inherently random and one run settles nothing.

The passage below is the core of the lab's comparison script: turning two records into one table. It calls no model, and both versions teach the same thing — normalize the data first, compare second.

interface RunRecord {
  tool: 'codex' | 'claude-code'
  promptChars: number
  instructionsChars: number
  approvals: { count: number; reasons: string[] }
  verification: { ranTests: boolean; testsPassed: number; testsFailed: number }
  cost: { minutes: number; inputTokens: number; outputTokens: number }
  filesChanged: number
}
 
function row(label: string, pick: (r: RunRecord) => string | number, runs: RunRecord[]): string {
  return `| ${label} | ${runs.map(pick).join(' | ')} |`
}
 
export function renderTable(runs: RunRecord[]): string {
  const header = `| Dimension | ${runs.map((r) => r.tool).join(' | ')} |`
  const sep = `| --- | ${runs.map(() => '---').join(' | ')} |`
  return [
    header,
    sep,
    row('Briefing: requirement + instruction file characters', (r) => r.promptChars + r.instructionsChars, runs),
    row('Approval: interruptions', (r) => r.approvals.count, runs),
    row('Verification: ran the tests itself', (r) => (r.verification.ranTests ? 'yes' : 'no'), runs),
    row('Verification: passed / failed', (r) => `${r.verification.testsPassed} / ${r.verification.testsFailed}`, runs),
    row('Cost: minutes', (r) => r.cost.minutes, runs),
    row('Cost: tokens (input + output)', (r) => r.cost.inputTokens + r.cost.outputTokens, runs),
    row('Files changed', (r) => r.filesChanged, runs),
  ].join('\n')
}

from dataclasses import dataclass
from typing import Callable
 
 
@dataclass
class RunRecord:
    tool: str
    prompt_chars: int
    instructions_chars: int
    approvals: int
    ran_tests: bool
    tests_passed: int
    tests_failed: int
    minutes: float
    input_tokens: int
    output_tokens: int
    files_changed: int
 
 
def row(label: str, pick: Callable[[RunRecord], object], runs: list[RunRecord]) -> str:
    return f"| {label} | " + " | ".join(str(pick(r)) for r in runs) + " |"
 
 
def render_table(runs: list[RunRecord]) -> str:
    header = "| Dimension | " + " | ".join(r.tool for r in runs) + " |"
    sep = "| --- | " + " | ".join("---" for _ in runs) + " |"
    return "\n".join(
        [
            header,
            sep,
            row(
                "Briefing: requirement + instruction file characters",
                lambda r: r.prompt_chars + r.instructions_chars,
                runs,
            ),
            row("Approval: interruptions", lambda r: r.approvals, runs),
            row("Verification: ran the tests itself", lambda r: "yes" if r.ran_tests else "no", runs),
            row("Verification: passed / failed", lambda r: f"{r.tests_passed} / {r.tests_failed}", runs),
            row("Cost: minutes", lambda r: r.minutes, runs),
            row("Cost: tokens (input + output)", lambda r: r.input_tokens + r.output_tokens, runs),
            row("Files changed", lambda r: r.files_changed, runs),
        ]
    )

The table draws no conclusions; the conclusions are the few lines you write in the report template. One column of that template is labeled "does this difference come from the way of working or from capability," and every row of difference has to be filled in — a difference you cannot fill in is a place you do not yet understand.

Write one, review one: chaining the two tools into a daily workflow

D2 left a thread hanging when it covered code review: review and generation from the same vendor's model cannot catch a misunderstanding of the requirement, because both share the same understanding. The fix is to review with the other vendor. Both contractors are in the room today, so this is the moment to build that workflow.

The flow has three steps. Step one, A writes: complete the task with whichever you find handier (say Codex) and get the tests green. Step two, B reviews: hand the diff, the original requirement, and the acceptance criteria to the other one (Claude Code), asking it to find problems without changing code and to output structured review comments — file, line, problem, severity. Step three, a human decides: read the comments one by one and decide which go back to A for fixing and which get dismissed. You can run another review round after the fixes, but one is usually enough.

Both have an unattended mode, so this flow can be a script: codex exec for Codex, and claude -p with --output-format json for Claude Code (plus --allowedTools to hold the reviewer to read-only). What the reviewer receives matters greatly — always give it the original requirement, since with only the diff it degenerates into a linter; and always demand structured output, or you cannot automatically track which comments were accepted.

# Step one: A writes (Codex unattended mode)
codex exec "$(cat task.md). Run pnpm test afterwards and stop once green."
git diff > /tmp/change.diff
 
# Step two: B reviews (Claude Code unattended, read-only, structured output)
claude -p "The requirement is in task.md and the acceptance criteria in acceptance.md. Review only, change nothing, and output a JSON array of file, line, issue, severity." \
  --allowedTools "Read,Grep,Glob" --output-format json < /tmp/change.diff > /tmp/review.json
 
# Step three: a human decides, and accepted comments go back to A

When is this not worth doing? Three cases. First, when the task is small enough that reviewing costs more than the task — fixing a typo does not need two firms in session. Second, when the team only bought one vendor's allowance, since cross-vendor review means two bills and you have to weigh whether the extra problems found are worth the money. Third, when nobody reads the review comments — if the team habitually accepts everything in one click, the second vendor's opinion is just another layer of noise. All of this workflow's value comes from the human in step three, and with no human present the first two steps are waste.

Conversely, its highest-value cases are equally clear: the change affects several callers, the requirement itself is ambiguous, or this change is going to production. In those three, one independent opinion from a different model pays for itself the first time it catches a misreading.

Where to go next: from using tools to building them

Over five days you learned to get work done with the tools on the OpenAI side: having Codex change code locally and in the cloud, having it review code, writing your own small agents with the Responses API and the Agents SDK, and finally comparing and combining the two vendors' tools. This course is positioned at using them, and what it deliberately did not touch is building them.

Three directions, depending on your situation.

To get fluent with the other vendor too: take Mastering Claude, five days, structured day for day against this course and using the same TODO API task. Finish both and you hold a complete two-tool comparison.

To learn how Codex and the Agents SDK are built underneath: take From Frontend Engineer to Agent Engineer in 30 Days. It starts on day one with the LLM API and hand-builds the agent loop, the tool system, and multi-agent orchestration all the way to a production-grade gateway and worker pool. The run function, handoffs, and guardrails you used today all get implemented by hand there.

To go deep on one layer: how to write the MCP server you wired up on D2, and how to design the skills from D2 into reusable capabilities, are the subjects of the upcoming specialist courses mcp-7days and agent-skills-7days. Both start from the assumption that you can already use Codex or Claude Code, which places them right after today.

Finally, back to this course's analogy. The two contractors work differently, but the way you manage them is the same: write a clear onboarding handbook, draw clear permission boundaries, require them to run the verification before reporting, and have the other one review anything important. That method belongs to no vendor. It belongs to you.

Source Reading

Hands-On Lab

The code is in labs/codex-mastery/day-05-dual-tool-compare, with four exercise points cut out of starter/ and complete answers in solution/. The script calls no model at all, and MOCK=1 substitutes built-in sample records for your own two JSON files so you can see the shape of the table first.

1. Prepare an identical starting point: commit the TODO API from D1, note the commit id, and git worktree add two working copies, one per tool.
2. In the Codex copy, place AGENTS.md, run the task, run /review, and fill out runs/codex.json per the fields of runs/template.json.
3. In the Claude Code copy, place a CLAUDE.md with the same content, run the same requirement, run /code-review, and fill out runs/claude-code.json.
4. Run MOCK=1 pnpm start to see the sample table, then pnpm start runs/codex.json runs/claude-code.json to generate your own.
5. Paste the table into report-template.md, label every row as way of working or capability, and finish by writing your tooling conclusion and one mixed workflow.

Interview Questions

Today's 3 questions are in the question bank below, weighted toward the comparable dimensions for choosing a coding agent, the benefit and cost of a mixed workflow, and how to explain the trade-off to a team. Expand each one and read the analysis before the key points — practicing the derivation beats memorizing bullets.

Checklist and Tomorrow

• Run the same task on both Codex and Claude Code, and record comparable data across four dimensions
• Explain how the two coding agents differ in project context, approval model, and verification habits, and justify a choice to a team
• Set up a write-one-review-one mixed workflow, and know when it isn't worth it
• For any row of difference in the comparison, say whether it comes from the way of working or from capability
• All 4 acceptance criteria of the lab pass
• Answer at least 2 of the 3 interview questions without looking at the key points

This is the course's last day. Look back at yourself on D1: you were installing Codex then, and now you can put two vendors' tools in the same table and know where the differences come from. Next, go fill in the other side with Mastering Claude, or go build what you used today by hand in the 30-day course.