Codex vs Claude Code: what 18 months of AI coding agents taught me

While I was building Lyra PPC, a tool that runs on the Google Ads API, I kept having to step in. Claude Code and I would agree on a plan, and then it would drift from it: an API version Google had already retired, a field that doesn’t exist, a function that returned sample numbers where the plan said “call the API”. What fixed that wasn’t switching tools. It was having Codex read Claude’s plans before any code existed.

So here’s my answer to Codex vs Claude Code. For writing code, Claude Code is ahead for me today, and every new job starts there. Codex is the one I trust to read Claude’s plans and diffs and find what’s missing. I’ve used Claude Code for about a year and a half, and Codex heavily for the last four months. I’d stop looking for a winner and start using them together.

Claude Code vs Codex at a glance

	Claude Code	Codex
Cheapest plan that includes it	Claude Pro, $20 a month in the US. Not in Claude’s free plan	ChatGPT Free, for quick tasks in the desktop app (still rolling out). The CLI, IDE extension and web start with Plus, $20 a month
Top individual plans	Max, from $100 a month (5× or 20× Pro’s usage)	Pro at $100, $200 or $500 a month
Usage limits	One pool with the rest of your Claude plan, chat included	Shared with ChatGPT Work
Where it runs	Terminal; VS Code, Cursor and JetBrains; desktop app; web; Claude app on iOS and Android	Terminal; VS Code, Cursor, Windsurf and JetBrains; ChatGPT desktop app; web; iOS
Runs tasks in the cloud	Yes: cloud sessions and scheduled routines	Yes: Codex Cloud
Windows	Native (PowerShell or CMD), or WSL	Native (PowerShell, with a Windows sandbox), or WSL2
Project instructions file	CLAUDE.md; also reads AGENTS.md	AGENTS.md
Skills	Yes	Yes
MCP servers	Yes	Yes
Subagents	Yes	Yes
Hooks	Yes	Yes
Automatic PR review on GitHub	Team and Enterprise plans only (research preview, billed separately). On any plan, /code-review reviews a diff locally	Yes, from Plus

On paper they’re near twins. The differences that matter are below, and they’re about how each one behaves.

Sources: Claude pricing, Claude Code overview, CLAUDE.md and AGENTS.md, cloud sessions, Code Review; Codex pricing, Codex CLI, IDE extension, Windows, customization, hooks, Codex Cloud, code review. I left out models, context windows and speed: they change with every release.

How I ended up paying for both

I started with Claude Code. It was the first agent that worked in my terminal, on my repositories, the way I wanted to work, and for months it was the only one I used.

I added Codex for two reasons. The first was limits: on long days I ran out of Claude, and a second subscription meant I could keep going. The second was plain curiosity. Anthropic and OpenAI keep releasing frontier models in turn, and each release makes one or the other the reference for a few days or weeks. I wanted to try each new one on my own work, not read about it.

That’s still true. If you read a Codex vs Claude Code comparison that names a clear winner, check its date. The answer may have changed since.

Where Claude Code is ahead for me

Today, for writing code, I reach for Claude Code first. Three reasons, in order of how much they matter to me.

My context lives there. My CLAUDE.md files, my skills and Claude’s memory of past sessions all sit in Claude Code (memory, skills). After a year and a half they hold a lot: how I name things, what I never want touched, the mistakes I don’t want to see twice. Codex reads AGENTS.md and supports skills too (AGENTS.md, skills), so this is partly habit: I wrote mine in Claude first.

It plans better. When I hand Claude Code a vague idea, it comes back with a plan I can argue with: steps, files, the order to do them in. That’s where every job of mine starts now, so it matters more than raw coding speed.

It’s nicer to use. That’s not a technical argument, and I won’t pretend it is. Part of it is the planning above. The rest is its terminal output: it’s easy to read what it’s doing and what it did. I spend hours a day in it, and how it feels counts.

“Ahead” is a small gap

On public numbers, the two are close. On SWE-rebench, which tests agents on fresh tasks from real repositories, Claude Code resolves 60.4% and Codex 58.0% of the same 111 tasks collected between May 15 and July 1, 2026 (leaderboard checked October 4, 2026, each with an error margin of about one point). That’s one benchmark and one window. It says what my experience says: neither tool is far ahead, and a new model can flip it.

What Codex does best: finding what Claude’s plans missed

Here’s what surprised me. I added Codex to review code, and it does that well. But the place it adds the most is earlier: reading Claude’s plan before anything is built.

Codex often improves, refines or completes Claude Code’s plans by spotting special cases and edge cases the first author missed. In my projects those fall into two groups:

• Concurrency and ordering. Two jobs touching the same data, a step that assumes another has already run, a retry that writes something twice.
• Security and permissions. Who can reach what, with which credentials, stored where.

Those are exactly the things a plan written in one go leaves out. The author is thinking about the happy path, and the steps read well. A second reader, with no stake in the plan, asks “what happens if this runs twice?”

Here’s what that looks like, on the kind of job I do every week:

CardSync MB Adv’s Google Ads spend into the dashboard

Not started

What you want Every morning the dashboard shows yesterday’s Google Ads spend for each MB Adv client account, read from the real API.

Plan with two AIsClaude proposes

1. 1
   Install the google-ads client and target API v21.Install the google-ads client for the current API version and put its sunset date in the README.

   F1 · Serious — API v21 is past its sunsetOpenv21 is no longer in Google’s version table: it has been switched off. Target the current version and write down when it ends.Step 1 targets the current version.
2. 2
   Authenticate with MB Adv’s OAuth refresh token, saved in config.yaml.Keep the refresh token in the secret store. Its Google user has read-only access to MB Adv’s manager account; every request sends login-customer-id.

   F2 · Serious — Who reaches the client accounts, and with whatOpenThe accounts sit under MB Adv’s manager account, so requests need login-customer-id set to the manager’s ID. The token can’t live in the repo, and its user only needs read-only access.Step 2 adds the header, the secret store and read-only access.
3. 3
   For each client account, query metrics.cost for YESTERDAY.Per account, one SearchStream query for the last 3 days: segments.date, customer.currency_code, metrics.cost_micros. Divide micros by 1,000,000.

   F3 · Serious — There is no metrics.costOpenThe field is metrics.cost_micros: millionths of the account’s currency. YESTERDAY is in each account’s own time zone, and the accounts may not share a currency.Step 3 reads cost_micros with the currency; step 6 totals per currency.
4. 4
   Insert one row per account per day into ad_spend.Upsert into ad_spend on (account_id, date), so a day written twice stays one row.

   F4 · Serious — Two runs can write the same dayOpenA slow hourly run can overlap the next one and insert a day twice. Google also updates recent days after the fact (late conversions, invalid clicks).Step 4 upserts; step 3 re-reads the last 3 days.
5. 5
   Run it hourly with cron. Until the credentials work, use sample data.Hourly, one run at a time (a lock). Retry RESOURCE_TEMPORARILY_EXHAUSTED with backoff and jitter. No sample data.

   F5 · Should fix — Sample data would look like real spendOpenWhen the API fails, the dashboard should say when it last synced, not show invented numbers. Quota errors are retryable with backoff.Step 5 locks, retries and drops the sample data.
6. 6
   Show the total spend on the dashboard.Show spend per account and a total per currency, with “last synced at”.

Codex critiques · round 2 of 2 · Verdict: ready

The plan (Claude, after 2 rounds). Codex: ready.Use this planAnother round…Edit…Discard

Use this plan: the build starts from it. Codex reviews the diff when Claude is done.

You write what you want in plain words, then start Plan with two AIs.Claude proposes a plan: six steps, before any code.Codex critiques it, read-only, round 1 of 2: what is missing or wasn’t foreseen, under the step it concerns.Claude revises the plan. Each point is closed by a step that changed.Codex critiques the revised plan, round 2 of 2: ready. The decision is yours.You press Use this plan, and only now does the build start. The diff gets its own review later.

CardProposeCritiqueReviseReadyBuild

In words: the card asks for yesterday’s Google Ads spend for each MB Adv client account. Claude’s first plan pins a retired API version, reads a field that doesn’t exist, keeps the token in the repo, inserts rows a second run can duplicate, and falls back to sample data. Codex critiques the plan in two rounds, adding five points under the steps they concern; Claude revises; in round 2 Codex finds the plan ready; you press Use this plan, and only then does the build start.

Updated for Plyloft 1.168.1 on October 23, 2026: the scene shows Plan with two AIs, the way the app plans a card since 1.165.

On Lyra PPC, the tool I build on the Google Ads API, the misses were always the same kind. A plan pinned an API version Google had already retired. It read spend from a field that doesn’t exist (the real one is cost_micros, in millionths, so forget to divide and a €40 day shows as €40,000,000). It forgot that agency accounts need a manager ID on every call, and that “yesterday” ends at a different hour for each client. None of these are hard. They’re just invisible to an author thinking about the happy path, and obvious to a second reader. I wrote up the full list, with Google’s docs for each, in what coding agents get wrong about the Google Ads API.

Why I’d rather fix a plan than a diff

A finding on a plan costs a sentence. The same finding on a finished diff costs a rebuild, and sometimes a schema change. When Codex says “step 4 can write the same day twice” before anything exists, Claude changes one line of the plan and builds it right the first time.

The other reason is subtler. Once code exists, a reviewer tends to review what’s there. A plan is short enough that the reviewer can see what isn’t.

Where each one annoyed me

Eighteen months ago, these were my three biggest time-wasters. Claude Code did most of my building, so it produced most of them:

1. It said “done” too early. Tests not run, a step quietly skipped, a TODO left in the middle of the job.
2. It touched things I hadn’t asked for. A refactor of a file next door, a renamed variable, a “small improvement”.
3. It repeated the same mistakes. The fix from Monday was forgotten by Wednesday.

On Lyra PPC there was a fourth, specific to working with an API that changes often: wrong versions and fields, sample data in place of real calls, and shortcuts I hadn’t agreed to, where a step of the plan was simplified or skipped.

Job: plans with me, then builds.

Better at: turning a rough idea into a plan I can argue with; writing the code; carrying my context (CLAUDE.md, skills, memory).

Annoyed me: drifting from an agreed plan; old Google Ads API versions and fields; sample data instead of real calls; skipping a step to reach “done”.

Job: reads Claude’s plans and diffs, read-only, and says what’s missing.

Better at: cases the plan didn’t foresee: concurrency, ordering, permissions, security.

Annoyed me: I have fewer stories here, because I build much less with it.

Skills changed more than any model release

Today those annoyances mostly don’t happen. After a year and a half of refining skills, memory, how I manage the work and how I plan it, they’ve gone. If I had to pick the one thing that changed it most, it’s skills: short written instructions the agent loads before it starts, like “run the checks before you say done” or “don’t touch files the plan doesn’t name”. Every time an agent repeated a mistake, the fix went into a skill, and the mistake stopped coming back.

I owe you a caveat here. Two recent studies found that context files like AGENTS.md and CLAUDE.md don’t measurably raise the rate at which agents solve tasks. One found no general gain in success and more than 20% more inference cost (Gloaguen et al., arXiv 2602.11988, revised September 29, 2026). Another, by Khatri, on 17 real-repository tasks and 288 runs with Claude Code and Codex, found no measurable effect on correctness for either agent (Khatri, arXiv 2607.27250, July 28, 2026).

I believe them, and I don’t think they contradict me. They measure whether a task gets solved. What my skills fixed is behavior around the task: stopping early, wandering out of scope, repeating last week’s mistake. That’s what cost me hours, and it’s not what a pass rate counts. The first study’s own conclusion points the same way: context files help most with practices a project does differently from the norm.

The one controlled study on cross-review points the other way

If you search “Codex vs Claude Code”, you’ll find plenty of people saying “use both, let Codex check Claude”. I found one controlled study that measures it, and its result is not what I’d have guessed.

Xiang et al. (arXiv 2607.21656, July 22, 2026) gave both agents 116 recent medium and hard LiveCodeBench problems. One wrote a solution, the other reviewed it without being able to run tests.

Codex wrote it

71.6%

89.7%

84.5%

Claude wrote it

91.4%

82.8%

91.4%

Share of problems solved, by who wrote and who reviewed

Item	Alone	Reviewed by the other	Reviewed by itself
Codex wrote it	71.6%	89.7%	84.5%
Claude wrote it	91.4%	82.8%	91.4%

Show the numbers

Share of problems solved, by who wrote and who reviewed

	Alone	Reviewed by the other	Reviewed by itself
Codex wrote it	71.6%	89.7%	84.5%
Claude wrote it	91.4%	82.8%	91.4%

Source: Xiang, Zhang, Zhang and Xu, “Cross-Model LLM Code Review”, arXiv 2607.21656, July 22, 2026; 116 LiveCodeBench problems, reviewer could not run tests

Claude reviewing Codex helped a lot. Codex reviewing Claude made Claude’s solutions worse: 91.4% down to 82.8%.

That’s the opposite of how I work, so I took it seriously. The paper was accepted at a KDD’26 workshop, and its own conclusion is plain: use Claude to review Codex, not the other way round. Three things separate their setup from mine, and each one is something you can copy.

1. They reviewed finished code. I review plans first. Claude’s solutions were already right 91.4% of the time, so most of what a reviewer could change was working code. My guess is that’s where the drop comes from: a “fix” to a correct solution can only break it. That’s my reading, not something the paper measured. A plan is different: the reviewer adds a missing case before anything is built, and there’s nothing correct yet for it to break.
2. Their reviewer had the last word. Mine doesn’t. In my loop, Claude answers each finding and can push back with a reason. When they disagree, I decide. A wrong finding costs a sentence, not a regression.
3. Their reviewer couldn’t run anything. My checks run after every round. If a “fix” breaks the build or the tests, I see it before I ship.

And if you only take one thing from the study: the direction it does support, Claude reviewing Codex, is the one most people skip. Try both directions on your own work. It’s a one-line change in who builds and who reviews.

What most comparisons get wrong

I read a lot of these before writing my own. Most fall into one of four traps.

They look for a winner. The winner changes every few weeks. A post that crowns one tool is a snapshot of the month it was written.

They ignore setup. The same agent with no instructions and with a year of skills, memory and a working process behaves like two different tools. Most comparisons test the bare install, which nobody who uses these daily actually runs.

They test on toy projects. A to-do app or a single-file game shows how fast an agent types. It doesn’t show what happens on a codebase with history, an external API that changes, and conventions written down nowhere.

They make you choose. Most people who are serious about this end up paying for both. The useful question isn’t which one, it’s which one does what.

Plans and limits: what I pay, and where I still hit the ceiling

I pay for Claude Max and ChatGPT Pro. On intense days, many hours in a row, I hit the weekly limits of both. When one runs out, I switch to the other.

For the cheaper plans, the facts as of October 4, 2026:

• Claude Code is included in Claude Pro ($20 a month in the US) and Max (from $100 a month), and it shares limits with your use of Claude in the chat app (Claude pricing).
• Codex is included in every ChatGPT plan, the free one too. Plus is $20 a month and Pro starts at $100. OpenAI’s pricing page describes Plus as enough for “a few focused coding sessions each week” (Codex pricing).

Both vendors change these numbers often, and both say limits depend on the model and the size of the task. I’m not going to guess how many hours each $20 plan gives you. The honest answer from my side is this: at $20, neither covers a full working day of agents. At the top plans, I still run out on the hardest days.

Plan by plan, with what you can do without paying, it’s in Is Claude Code free?. To set up the second agent, see how to install Codex CLI and sign in with ChatGPT.

If you can only pay for one

I’d tell a friend to start with Claude Code. And I’d be honest about why: it’s purely a feeling for the platform and the software, nothing more. I don’t have a technical argument that would survive the next model release. One exception: if the friend already pays for ChatGPT, I’d tell them to start with Codex. It’s already included.

With one plan, you can still get a second read. Open a fresh session, give it the plan or the diff with “find what’s missing or wasn’t foreseen, change nothing”, and take its findings back to the first session. A different vendor is better at this, because it doesn’t share the author’s blind spots, but a fresh session beats no review. (Plyloft does the same with a single plan: the reviewer runs as a separate session of the same tool, and the card says so.)

What I do now

Plyloft started from something smaller. I was working on two separate projects with six different terminals open, and at some point I said to myself: enough. I needed one place per project that kept its terminals together, and that’s where Plyloft started.

The review loop came later. Once Codex was reviewing Claude’s plans, my setup was two terminals side by side. Claude Code wrote a plan; I copied it into Codex and asked what was missing; I copied the findings back to Claude. Then the same with the diff. It worked. It was also tedious, easy to get wrong, and I was the bottleneck in every round. So the app grew to do the copying too.

The loop itself is simple:

1. 1PlanClaude
2. 2Plan reviewCodex · read-only
3. 3Revised planClaude
4. 4BuildClaude
5. 5Code reviewCodex · read-only
6. 6ShipMe

builds reviews, changes nothing decides. A review that asks for changes goes back one step: the plan, or the build.

In Plyloft, each job is a card. One agent is the Builder and the other the Reviewer: by default Claude builds and Codex reviews, and you can swap them per card, which is also how you’d test the study’s direction on your own repo. Before the build, both can read the brief and challenge the plan. After it, the Reviewer reviews the diff read-only and its findings go back to the Builder, round after round, until nothing blocking is left. Then I decide whether it ships. Each card works in its own copy of the repository, and the review follows the same skills the Builder does. The how it works page walks through one card from start to finish.

It runs the claude and codex command-line tools, in real terminals on your computer, on a plan you already pay for: Claude Pro or higher, or ChatGPT Plus or higher. Plyloft never sees your credentials and doesn’t sell model access. Its server never receives your code, your prompts or even your file names.

What I haven’t tested yet

This version is built on experience, so it has limits I want to be clear about.

• No controlled tests. Everything about which tool is “ahead” is my experience on my projects. I’m running both on the same tasks: first-try success, rounds to green checks, and how many real problems each finds in the other’s plans and code. I’ll add the numbers here when I have them, with the date.
• My projects, my setup. A handful of real codebases in Rust, Python and TypeScript/React, with a year and a half of skills behind them. Your results on a different stack, or with a fresh install, may differ.
• Models change. Both vendors ship often. Something in here will be out of date within weeks, and I’ll update the post when it is.

If you want to try the loop without copying between terminals, download Plyloft and try it one card at a time, free.