Claude Code vs Codex: Same Question, Different Proposals

Monochrome line art: a stack of plates and a cluster of cubes placed apart

AI & Software · 2026-07-20 · 7 min

Give two AIs the same task and do they converge? The contest started before a single line of code.

Hand two AIs the same problem, and do they arrive at similar answers? Or do they take different roads from the very first step?

At MIF, we decided to build our guidance on choosing and adopting AI coding tools out of records of actually putting them on the same job, rather than out of spec-sheet comparisons. In this series, “Claude vs Codex Arena,” we give two AI CLIs — Claude Code (model: Fable 5) and Codex (model: GPT-5.6-Sol, reasoning effort: ultra) — the same assignment and have them compete from proposal through implementation to evaluation.

Episode 1 happens before a single line of code is written. The contest had already begun at the stage of deciding what to build. The same question produced completely different proposals, a human rejected both, the follow-up proposals split the project in two, and in the end one AI’s peer review corrected the other’s mistake — all of it on the record.

This article records one assignment and one run (n=1). It does not establish which model is better in general. Quoted exchanges are based on records cleaned up for publication.

How the experiment works — Claude Code and Codex never talk to each other

First, picture the setup. The two AIs run in separate windows and have no direct knowledge of each other. The only thing connecting them is me.

The author sits between Claude and Codex, relaying questions and answers The author in the center sends questions to Claude on the left and Codex on the right, and each answer passes back through the author to reach the other side. The direct path between the two AIs is blocked with an X. Claude Code Me (human) Codex Model: Fable 5 Separate session Sends questions, pastes answers across, judges Model: GPT-5.6-Sol reasoning effort: ultra No direct link between the AIs — peer review passes through me too

If I want Codex to see Claude’s proposal, I copy it and paste it. Every “debate” between the two AIs happens through that manual relay. So I am not a spectator. Which answer I show to the other side, where I reject an idea, what constraints I add — my judgment in the middle changes the direction of the project. That matters later.

Step 1: I assigned the first project — then scrapped it

My first request to both AIs was to build “repo-pulse,” a CLI tool that analyzes multiple git repositories and produces a weekly report on development activity, under identical conditions.

But as preparation went on, I killed the idea myself. It would be useful to developers, yet a reader would struggle to see what was actually being contested. So I changed the assignment. Instead of deciding what to build, I asked the AIs to compete on proposing what should be built. Something practical, something that would inform our future tool choices, and something that would make a good article — the same request went to both AIs.

That was not a small pivot. What had been a contest of implementation skill now included a contest in finding the right problem.

Step 2: Claude Code and Codex both proposed — and a human rejected both

The flow was this: I collect both proposals, relay each one to the other side, watch the reactions, and then judge. Here is how the first round lined up.

Round 1Claude’s proposalCodex’s proposal
Ideasession-viewerDownloads Rescue
What it doesConverts AI conversation logs into clean HTML for viewingSafely organizes and restores a cluttered Downloads folder
Starting instinctHow to show the experiment itself (a self-referential punchline: “the log viewer in this article was generated by the winning tool”)A situation readers hit every day (“which AI would you trust with your own folder?”)
VerdictRejectedRejected

From the same question, Claude chose a tool for displaying the comparison process, and Codex chose a tool for taking a familiar chore off your hands. The proposals had already diverged sharply. Both were defensible. Even so, my reaction as judge was, I admit, blunt.

Honestly, neither of these feels interesting.

Both rejected. What happened next is the interesting part: each rejected AI diagnosed its own loss. Claude analyzed that “the weak point is that the climax of the contest is a human filling in a scorecard,” and Codex diagnosed that “the stakes readers can expect from the outcome are too low. It should shift from ‘what got built’ to ‘what got discovered.’” A useful tool and a contest worth following are not the same thing — a vague one-line rejection, run through the AIs’ own analysis, turned into concrete criteria for the next round.

Step 3: The second proposals were an “AI arena” and an “EC Copilot” — both accepted

The second round of proposals jumped in opposite directions.

Round 2Claude’s new proposalCodex’s new proposal
IdeaAI arenaEC Action Copilot
What it doesHave both sides build game-playing bots, then pit the finished bots against each other under a referee programPropose “what to do this week,” with supporting evidence, from inventory, order, and customer data
How the winner is decidedNot a human scorecard — a match on the boardDetection accuracy on synthetic data plus practical evaluation
VerdictAccepted (Round 1)Accepted (Round 2)

Claude changed the frame of the contest itself, moving the climax of the article from scoring to playing. Codex picked up on the business context I had given — that we are launching our own e-commerce operation — and dug toward supporting real operational decisions. Its design even split the roles: deterministic code handles the number crunching, and the AI only supplies the explanation and the recommended actions.

When I relayed each proposal, this time the two AIs’ assessments converged: “these two ideas don’t compete. Their opposite characters are exactly what makes a series.” What was meant to be a contest to pick one ended with two arenas, because the two proposals were too different in character to rank. Accepting both was not a compromise. It was a decision to preserve the difference between the proposals and turn that difference into the structure of the series. From the start of the project to this point: about one hour and thirty-four minutes.

Step 4: The AIs corrected each other — a URL was verified, and an error admitted

On the way to those acceptances, something happened that captures the spirit of this experiment.

Codex had cited the URLs of two existing services (Agent Arena and Hugging Face Agent Traces) as evidence for its new proposal. When I relayed that, Claude pushed back: “I doubt those URLs exist. They should be opened and checked before being cited in an article.” Codex countered that it had checked both and that they were live. What Claude did next is the highlight of this episode. Rather than take “already checked” at face value, it verified the URLs itself.

The result: both existed.

First, a correction — I was wrong about the URLs.

Claude raised the doubt; Codex was right. Claude admitted the error along with its verification result and recorded the correction in the project document. No human arbitrated. One AI’s claim was verified by the other, and a correction went through — peer correction number one.

What made this valuable was not just who turned out to be right. The doubt was not treated as fact, the rebuttal was not swallowed whole, and the matter was settled against the primary source. Only with all three steps — doubt, verify, admit the error — did this become a fact usable in an article. A URL attached to an AI’s answer is not itself a reason to consider something checked, and neither is another AI saying it checked. Peer review works, but it does not let you skip the final fact check.

Step 5: The assignment was locked in — and the two AIs started building

With that, the stage was set. In the same peer review, the game changed from the original Othello to Connect Four (Codex pointed out that the board reads better in an article, and Claude accepted), a shared rule set and referee program were prepared, and both sides began from writing a specification in fresh sessions where they could not see each other’s work.

The difference in character that showed up in the proposal phase — Claude reasoning from narrative structure, Codex reasoning from practical value and the gap against existing tools — how will it show up in implementation? That is the main event, starting next time.

Three things the Claude Code vs Codex comparison showed

  • The proposals from the same question split along clear lines of character. But it would be premature to lock in “Claude is for entertainment, Codex is for business” from the opening move alone; this is one observation, from one conversation, under one set of conditions
  • The human rejection was not wasted. From the single remark “neither feels interesting,” both sides diagnosed their own loss, and the second proposals were distinctly better. Putting a vague sense of unease into words and handing it back was the most effective input I gave either AI
  • A “fact” produced by an AI was corrected by the other AI plus first-hand verification. Building a structure where models doubt and check each other proved safer than trusting a single AI outright

When you bring AI into your work, the speed of adopting the first answer is not the only source of value. A human sets the criteria, has multiple proposals compared, updates the constraints, and verifies the evidence at the end. This proposal showdown began with exactly that operating design.

What’s next

Next time: the live run of the Connect Four arena. The winner is decided not by human scoring but by 100 games played under a referee program. We start with the results.

This series (6 parts)

  1. Same Question, Different Proposals (this article)
  2. 100 Connect Four Games Head-to-Head
  3. Claude Code vs Codex on Real EC Data
  4. Does Merging Beat the Best Solo Run?
  5. Can Claude Opus Run the Lane? Opus vs Fable as Controller
  6. Three Controllers Compared, and ModelOrcs
Back to articles