I Ran Claude Code and Codex Head-to-Head — Then Had a Third AI Blind-Judge the Results

On 2026-07-04 I ran a real bake-off, not a benchmark demo. The task: convert eight of my own blog posts to add inline SVG diagrams, against a written spec that already lived in this repo (tools/INLINE_GRAPHICS.md). Four posts went to Claude Code — sonnet subagents (the mid-tier model that did the drawing) with a top-tier controller session running QA. Four went to Codex CLI, prompted by me directly, self-QA'd. Then, instead of trusting either agent's self-report or my own gut, I had a third AI — a blind opus (top-tier) subagent that never saw which post came from which stack — score all eight against the spec's own rubric.

The Setup: One Spec, Two Agents, Blind Scoring

The spec already existed before the bake-off — tools/INLINE_GRAPHICS.md, written after an earlier audit found that all 34 posts on this site had exactly one image (the hero) and six ran 1,900–3,100 words of unbroken text. It defines the format (inline SVG in a <figure>, no build step), the palette, text-size floors, and a QA checklist. Any agent — Claude or Codex — is supposed to be able to pick a post off the work table and convert it without further instruction.

I split eight posts across the two stacks. Claude's sample: four longer posts (2.5k–3.1k words) — three conceptual pieces plus one how-to (the OBS Mac screen-recording post) — run as sonnet subagents with a controller doing QA. Codex's sample: four shorter posts (1.6k–1.9k words) — governance, MDM, an OBS how-to and the RFP-TCO piece — run through Codex CLI with me prompting directly and Codex self-reporting its own QA. Claude produced 19 figures across its four posts; Codex produced 12.

The Blind Judge and the Score

The judge was a fresh opus subagent, given all eight posts' HTML and SVG markup, the spec, and nothing else — no git log, no status column, no stack names. It scored each post 1–5 on four criteria derived from the spec's own Why / Format / Visual-grammar sections: claim fidelity (does the diagram depict the section's actual argument, or is it decoration), placement (does it sit where the claim lands), caption quality (does the caption add a takeaway or just restate the heading), and composition (palette, density, legibility from the markup).

Totals: Claude 76/80 (average 19.0 per post), Codex 75/80 (average 18.75). That is a one-point gap on an 80-point scale — 0.25 per post — a statistical tie, not a result either stack should hang a decision on by itself.

Each of the four criteria below is a sum across four posts — four per-post scores of 1–5 each — so the ceiling per criterion is 20, not per post.

What the Score Doesn't Show

A mechanical spec audit (scripted, not the opus judge) found both stacks 100% clean on captions, role="img", aria-labels, minimum font sizes, palette, no adjacent figures, and zero phone overflow — spec compliance wasn't where the interesting difference showed up. It showed up in how each stack got to a clean result, and in how much of my own attention that took.

Two more things the score alone hid. First, a real spec deviation: Codex deleted an existing HTML widget on the RFP-TCO post and replaced it with its own SVG diagram — a violation of the spec's insert-only rule. It was editorially defensible (the SVG genuinely superseded the widget rather than duplicating it), and that post still scored 20/20, tied for the batch's highest alongside Claude's local-LLM setup post. Second, a redundancy the judge caught that neither stack could have seen coming: both OBS how-to posts — Claude's Mac screen-recording post and Codex's audio-routing post, converted independently — ended up with near-identical BlackHole audio-routing diagrams. Neither agent could see the other's work in progress. That is a real gap in running parallel conversions without a shared diagram registry, not a knock on either stack.

So Which Tool for Which Job

The purchasing-relevant conclusion isn't the 76-vs-75. It's that the two stacks bought different things with the same spec. Codex was cheaper on my attention per post once I'd prompted it and stayed disciplined about scope — it did not go looking for adjacent problems to fix. Claude's controller pattern cost more of my attention up front but closed its own trust loop: it verified its own QA claims with actual screenshots and a mechanical audit instead of asserting them, found and fixed a real bug outside the task, and carried the work through to a live, curl-verified deploy.

The Method, Not the Winner

The reusable part of this isn't "Claude is slightly better" or "Codex is slightly better" — a one-point gap on n=4 posts per stack, with a Claude-family judge and a Claude-authored spec, isn't a result I'd bet on either direction. The reusable part is the method: write the spec down before you hand it to anyone, run comparable work through more than one agent, verify at least one side independently instead of trusting self-reports, and score blind against the spec's own criteria — not vibes, not brand loyalty.

1. Write the spec first. Put it in the repo before any agent touches the task — format, constraints, and a QA checklist an agent can follow without asking you questions.
2. Run comparable work through both agents. Same spec, same rubric. Log what each one actually got, even if the split isn't a perfectly randomized sample — note the imbalance rather than hiding it.
3. Let each agent self-QA, but verify at least one independently. A self-report that's never checked against evidence is a claim, not a QA pass.
4. Score blind. The judge should not see git history, authorship, or which model shipped what.
5. Score against the spec's own criteria. Not "which one do I like more" — criteria derived from the spec's own Why / Format / Visual-grammar sections.
6. Disclose bias in the writeup. Who authored the spec, who ran the judge, what the sample size actually was.
7. Write the counter-case before you publish the number. What would make this result wrong, and say so on the page — not as a caveat buried at the bottom, up front.
8. Split the work by the process differences, not just the score. The tie told me almost nothing. The QA pattern, the scope discipline, and the deploy behavior told me exactly what to route where next time.

That's the actual deliverable from a day of running two agents against each other: not a scoreboard, a routing rule. Codex gets the well-specified batch. Claude gets the spec-writing, the QA gate, the blind judging, and the deploy — which, if you look closely, is exactly the shape this bake-off itself was run in.

Frequently Asked Questions

Related reading: Multi-Model Verification: Catching LLM Hallucinations in Enterprise Reports — the same "don't trust a single pass, verify independently" discipline that made the blind judge worth running. Codex Goal Mode Took My Funnel App to Launch-Ready — an earlier, deeper look at Codex running with more autonomy on a single codebase. For the hardware side of running AI locally, see Blendlogic Tech.

What would make this wrong

• n=4 posts per stack, not randomized. Claude's sample skewed toward longer, more conceptual posts (with one how-to mixed in); Codex's sample skewed shorter. The spec's per-post figure targets differed by post length too. A one-point gap on this small and unbalanced a sample could hide a real gap in either direction.
• Home-field bias. The spec, rubric, and reference implementations were all Claude-authored. Codex played an away game on someone else's rubric and still tied — which arguably flatters Claude more than it looks like it does.
• The judge is a Claude-family model (opus). It was blind to attribution — no git history, no stack names — but a family style preference can't be ruled out from blindness alone. A GPT-family re-score would be the real check.
• Single judge, single run. This was one bake-off, scored once. My own read of the eight live posts is the score that actually matters, not the judge's number.