Published: 2026-08-14
Comparison & results

Codex vs Claude Code on the same app: 11× slower, 6.6× pricier, and it still lost

Chapters / key moments (click to jump — plays here on the page)

Nate Herk gave Codex and Claude Code the identical /goal prompt — build a production-ready Typeform alternative, orchestrating specialised agents across research, build and verify phases — and then let both run to completion without intervening. Codex worked for roughly 62 hours and burned about $3,000; Claude Code finished in 5½ hours for a few hundred. The interesting part is not that the cheap run won, it is why: the two harnesses want to be prompted differently, and this prompt was written the way Claude Code likes.

Source video

"I Made Codex and Claude Code Build the Same App. One Clearly Won." by Nate Herk — Watch on YouTube →

The one-line takeaway you can act on today

Claude Code responded well to a high-level goal plus a definition of done — tell it what you want, what good looks like, and when to stop. Codex, on the same prompt, over-built: it treated an open-ended goal as licence to pursue every capability it could think of. Herk's read is that Codex wants explicit decomposition — step one, step two, step three — and that giving it a vague goal is what wasted most of the $3,000. Same prompt, two harnesses, opposite failure modes.

The prompt both agents were given

He ran /goal inside both tools with the same text. The shape of it matters more than the wording:

The build target: "build a production-ready, originally branded Typeform alternative" — deliberately a clone of a well-understood product, so the output could be judged on execution rather than on concept.
The orchestration instruction: "orchestrate specialized agents throughout three phases: the research phase, the build phase, the verify phase."
The stop condition, verbatim: "do not stop at a prototype or first successful build, continue researching, building, testing, breaking, fixing, and retesting until the app is genuinely complete."

That last clause is the load-bearing one — it is what kept both agents running for hours instead of handing back a prototype. If you copy anything from this experiment, copy the explicit definition of done.

What he would change: insert a fourth phase — planning and mapping the whole flow — between research and build. His own assessment is that both outputs would have been materially better for it, and that the missing planning phase explains a lot of the UI incoherence in both apps.

The measured results

Metric	Claude Code	Codex
Wall-clock time	5½ hours	~62 hours (2½ days)
Cost at API billing	~$832 by session stats (~$447 in the generated report)	~$3,000
Output tokens	~2 million	~11 million
Orchestrators / sub-agents	1 / 35	1 / 126
Tool calls	~2,800	~32,500
Unit tests written	296	2,300
Test cases	199	341
Browser tests	102	391
Models used	Fable 5, Opus 4.8, Opus 5 (mixed)	GPT-5.6 Soul on high, throughout
App produced	"Formora"	"Realform"

Note the cost discrepancy Herk flags himself: the summary report his review pass generated said roughly $447, while the session's own /usage stats across the orchestrator and all sub-agents came out nearer $800. He treats the report figure as a likely hallucination and trusts the session stats — a useful reminder that an agent summarising its own run is not a billing source.

The model-routing surprise

Worth knowing if you run long unattended sessions: he started the Claude Code session on Fable 5 and gave it the /goal prompt — but the session logs show Opus 4.8 as the main orchestrator, which then spun up Fable 5 sub-agents to do the work. He did not choose that, and his guess is that some safeguard check triggered the switch. Whatever the cause, the operational lesson is that the model you launch with is not necessarily the model that ends up orchestrating a multi-hour run, so read the session breakdown before attributing a result to a model.

What each app got right and wrong

Both apps shipped with visible bugs despite thousands of tests — which is the most transferable finding here.

Codex's build ("Realform") — better looking, worse product

Credible marketing site with a hero image, section anchors and a clean sign-up flow. But the form builder was overwhelming: too many controls competing on one screen, no obvious way to delete an inserted element, the confirm dialog rendering off to the left, an uploaded welcome-screen image reporting "image preview unavailable", and theme colour pickers that did not visibly change anything. It also decided the whole thing was a demo workspace and never wired up real functionality — despite being told to build something genuinely complete.

Claude Code's build ("Formora") — plainer, but it worked

A visibly AI-generated landing page, but past sign-up the product was the better one: multiple workspaces you can create and switch between, conversational-vs-stacked display modes, progress bar / question number / keyboard hints / autosave / partial-response capture as real toggles, a field-type list (short text, email, phone, website, dropdown, picture choice, NPS, opinion scale, rating, ranking), branching logic, uploadable themes, publish-to-link, and a results view with summary and per-response drill-down that recorded a real submission end to end. Its bugs were navigational: no reachable log-out, a selected field not highlighting until you click away and back, question numbers all stuck at "1" while the page counter read 1 of 3, and no back button out of the design, share and webhook views.

How the independent review scored them

He consolidated both full session traces and had Codex judge them blind, as agent A and agent B. Codex picked Claude Code — against interest — but the per-category split is more useful than the verdict:

Product judgment and scope → Claude Code. It made explicit must-have / defer decisions and focused on differentiators. Codex pursued 135 capabilities, several of them expensive operational features, with little restraint.
Architecture and execution → Codex. Claude Code's contract-first waves produced zero merge conflicts, but Codex built the more operationally mature system: immutable revisions, offline recovery, migration safety, concurrency handling and clearer boundaries.
Testing and reliability → Codex, by a wide margin. Claude Code did solid security and data-correctness testing; Codex added cross-browser testing, property tests, fault injection and mobile coverage that Claude Code simply did not attempt.
Efficiency → Claude Code, 9.0 against 5.5. Roughly 11× faster and 6.6× cheaper for a product the judge rated higher overall.

The workflow split this suggests

Herk does not conclude "use Claude Code" — he says he currently drives about 80% of his knowledge work with Codex. The split he actually recommends maps onto the category scores above:

Planning, brainstorming, product decisions, finding the path → Claude Code. Give it the goal and the definition of done, and get out of its way.
Security reviews, bug hunting, edge cases, adversarial checking → Codex. He specifically calls out the Codex plugin for Claude Code and its adversarial review, which in his experience "almost always" finds things his Claude Code workflow missed.

Run them in sequence rather than choosing between them: build with one, audit with the other.

Commands and mechanisms used

/goal — the slash command he invoked in both Codex and Claude Code to kick off the phased, orchestrated build from a single high-level prompt.
/usage — the session stats he trusted for real cost and token accounting across the orchestrator and every sub-agent, in preference to the agent's own written summary.
Codex plugin for Claude Code — adversarial review. Named as the practical way to get Codex's stronger testing and bug-finding onto work that Claude Code built.

Caveats before you generalise from this

Single trial, one prompt. Herk says repeatedly that the prompt shape favoured Claude Code, and that in his earlier tests Codex was the more token-efficient and faster of the two. This is one data point, not a ranking.
The models are new and moving. GPT-5.6 Soul and Fable 5 were both recent at the time of recording; a result on this pairing does not transfer to the next release.
"Production ready" survived neither. Both apps shipped user-visible bugs after hundreds to thousands of automated tests. Agent-written tests cover what the agent thought to test — if you are not driving the test plan, expect gaps exactly where a human would have clicked.
Take advice from people doing your job. His closing point, and a fair one: creators and tool authors optimise for their own workflows, so treat their defaults as evidence rather than instruction and run your own small experiments.

Key Takeaways

Same prompt, same task: Claude Code finished in 5½ hours for a few hundred dollars; Codex took ~62 hours and ~$3,000 and produced the weaker product.
Claude Code wants a high-level goal plus a definition of done; Codex wants explicit step-by-step decomposition. A vague goal is what made Codex over-build.
An explicit stop condition — "do not stop at a prototype, keep testing and fixing until genuinely complete" — is what kept both runs going for hours instead of returning a demo.
Add a planning-and-mapping phase between research and build; its absence showed up as UI incoherence in both apps.
More sub-agents, tool calls and tests did not mean a better result — Codex used 3.6× the sub-agents, 11× the tool calls and 7.8× the unit tests, and lost on product judgment.
The model you launch with may not be the one orchestrating: a session started on Fable 5 ran with Opus 4.8 as orchestrator.
Trust session usage stats over an agent's own written cost summary — the two disagreed by roughly 2× here.
The productive pattern is sequential, not competitive: plan and build with Claude Code, then run Codex's adversarial review over the result.