Codex vs Claude Code: pick by task type, not the benchmark
Codex and Claude Code now score within a point of each other on SWE-bench. Three real-task tests show what actually decides it instead.
I used to shortcut the Codex versus Claude Code question by checking whoever had the better SWE-bench number that month. That stopped working around this August. Three separate write-ups landed within about ten days of each other, each testing the two agents on real repos and real tickets, and one of them cited independent SWE-bench Verified numbers sitting a single point apart: roughly 88.6 percent against 88.7. When the benchmark gap closes that far, it stops being a reason to pick either one.
Here is the split that actually showed up once people stopped scoring leaderboards and started scoring tasks. Claude Code wins the work that needs judgment: refactors that change behavior, bug hunts, code review. Codex wins the work that is mechanical: migrations, doc regeneration, anything with one obviously correct output. Codex is also cheaper at the tier most people buy. Three independent testers converged on close to the same split without comparing notes, which is a stronger signal than any one of their scorecards alone.
What Codex and Claude Code are actually built to do
Both are agentic coding tools: they read your repo, decide what to change, edit files themselves, and run your tests, rather than you pasting code back and forth. The difference is where they default to running and how much they check in before acting.
Claude Code runs in your terminal against your own machine and asks before it acts on anything risky. Codex defaults to a cloud sandbox and leans toward running the job and showing you the result, with a local CLI as the other option. Neither posture is objectively correct. One suits a developer who wants to watch the reasoning happen. The other suits someone who wants to hand off a ticket and check back later.
Both companies will have shipped newer models by the time this is read, which is the point, not a caveat. Chasing the newest release number is a losing habit. Task fit outlasts any single model generation.
Three tests, ten days apart, landed on the same split
Three testers, no shared notes, the same underlying split.
A 31-day test on 7 real tickets
The most granular one, run by developer Ken Imoto, pushed the same monorepo through both agents for 31 days on 7 real tickets: a refactor, a test-generation pass, a Playwright flake fix, a YAML-to-pyyaml migration across 14 call sites, a PR review on auth-adjacent code, a README doc sync, and a green-field scraper script. Claude Code won the refactor, the tests, and the bug fix outright, and won the PR review with 3 real findings and zero false positives against Codex’s 2 real findings and 4 false ones. Codex won the migration in 11 minutes with a fully clean diff, against Claude Code’s 18 minutes and one missed call site, and won the doc sync in one pass against Claude’s two. The green-field script tied. Final count: Claude Code 4, Codex 2, one tie, and the author’s own read was that the aggregate score hides the pattern more than it reveals.
A 100-hour benchmark across 47 tasks
A second write-up, from someone who logged over 100 hours shipping production code on both, ran a 47-task benchmark and a harness-only test using the same underlying model on each side. On the 47-task run, Claude Code’s pairing finished 47 for 47. Codex’s pairing finished 45 for 47, using about 19 percent fewer tokens and finishing marginally faster. On the harness-only test, 30 identical multi-app tasks through the same tool router, both agents passed exactly 16 of 30. Claude Code got there in a median of 123 seconds; Codex took a median of 245 seconds but the run cost 58 percent less, working out to about 8 cents per successful task against Claude Code’s 19 cents.
What breaks in long sessions and bad git states
The same piece documented a 26-hour build session where the model hit a macOS bug, fixed it on one panel, ran /compact to shrink 570,000 tokens of history down to roughly 10,000, and came back eight hours later still able to explain exactly what it had done and why the second panel still needed the same fix. That kind of context survival only shows up on long, messy sessions, and it is a real edge for the tool built to hold onto more of the conversation.
A third teardown flagged the git risk on the other side. Its author’s own words: “Codex did some nasty things like branch A targets branch B that targets main, and when I asked it to rebase, it rebased with main, which created some PR with 4000+ additions.” The same piece described Claude Code’s failure mode as the opposite problem, over-building with extra abstractions and type layers that solve problems nobody had yet. Different tools, different ways of being wrong.
Codex vs Claude Code, side by side
| Claude Code | Codex | |
|---|---|---|
| Default execution | Local terminal, asks before acting | Cloud sandbox by default, plus a local CLI |
| Best task profile | Judgment calls: behavior-changing refactors, bug hunts, review | Mechanical work: migrations, doc regen, one-shot scripts |
| Long-session memory | Held up across a documented 570K-to-10K token compaction | Drops the middle of long tool outputs |
| Entry-tier price | $20/mo, roughly 45 messages per 5-hour window | $20/mo, rarely hit in practice |
| Cost per completed task (harness test) | $0.195 | $0.081 |
| Observed failure mode | Over-builds: adds abstractions nobody asked for | Under-builds, or mishandles its own git state |
When Claude Code wins, when Codex wins
Reach for Claude Code when the correct output is not obvious before you start. Behavior-changing refactors, subtle bugs like race conditions rather than surface typos, and code review where a false positive costs someone’s afternoon all fit this. It also holds up better the longer a single session runs.
Reach for Codex when the task has exactly one right answer and speed matters more than exploring the problem: a library swap across every call site, a one-shot script with a known shape. It is also the better default when you are price-sensitive at the entry tier and do not want to think about a usage window.
What it actually costs to run either one
The 31-day monorepo test spent about 58 dollars on Codex against roughly 30 dollars of attributed Claude Code usage on an existing subscription, for a workload that skewed toward the judgment-heavy tickets Claude Code was already winning. The harness test flipped the framing: same success rate, and Codex still came in at less than half the cost per completed task. Neither number is universal, but the direction holds across both tests: Codex costs less for the same outcome on well-specified work, and the gap widens as the work gets more mechanical.
Same success rate, a very different bill.
The part worth budgeting around
A team running high volumes of mechanical migrations on Claude Code alone is paying a real premium for judgment it does not need on that workload. A team running ambiguous, multi-file feature work on the cheaper tool alone is more likely to pay it back in review time and a second pass, which never shows up on the invoice but shows up in the calendar.
Why my own work stays on Claude Code
Everything I ship for client automation work runs through Claude Code, and almost none of it looks like the mechanical column above. Lead-scoring logic that has to infer the right founder from three inconsistent data sources. A proposal pipeline that has to read a client brief nobody wrote the same way twice. A content pipeline holding house style across a dozen formats. None of that has one obviously correct output before the agent starts, which is exactly the profile these three tests say favors Claude Code, and it is why I have not felt the pull to switch.
That is not an argument that Codex is the weaker product. It is an argument that my own workload sits almost entirely on one side of the split these testers found, and most agency work does too, because you usually automate something in the first place because the correct path was not already obvious. If your week looks more like well-specified tickets than ambiguous ones, the calculus flips, and paying less for a tool that does not need to hesitate is the correct call, not a compromise.
The one call I would not make is choosing on subscription lock-in. Keep a login for both. Twenty dollars a month for the mechanical option on hand is cheaper than the hours lost running judgment-heavy tools against tickets that never needed judgment.
Frequently asked questions
Is Codex or Claude Code better for coding in 2026?
Neither wins outright. Three independent real-task tests published in August 2026 all found Claude Code stronger on judgment-heavy work like behavior-changing refactors and code review, and Codex stronger on mechanical, well-specified work like migrations and doc generation. Pick based on which category most of your work falls into.
Is Codex actually cheaper than Claude Code?
At the entry tier, yes, based on real usage logs rather than list price alone. One tester’s 5-hour Claude Code window ran out around 45 messages, while the equivalent Codex tier rarely came up as a constraint. A separate harness test found Codex costing less than half per successfully completed task at the same success rate.
Do SWE-bench scores still matter for choosing between them?
Not much anymore. Independent SWE-bench Verified comparisons put the two within about a point of each other, which means the benchmark gap that used to separate them has largely closed. Task type and failure mode are the more useful signal now.
Which one handles long, multi-file sessions better?
Claude Code has the better-documented track record. One long-session account describes it correctly recalling a fix from earlier in a 26-hour session after compressing 570,000 tokens down to roughly 10,000. Codex’s harness tends to drop the middle of long tool outputs instead.
Should I just run both?
That is what every one of the three testers ended up doing, and it is the practical answer. Default to whichever tool matches most of your actual workload, and keep the other one installed for the week your workload doesn’t match your default.