Claude Code vs Codex in 2026: Notes From a Team That Runs Both

We gave Claude Code and Codex two open GitHub issues, a Python feature and a TypeScript bug fix, three runs each, and graded every run with tests we had kept back from both. All twelve runs passed. On the first ticket, the defect that mattered turned up later, when Codex reviewed Claude Code's diff, and Codex's own code carried it too.

Here is the plain version. Claude Code, from Anthropic, and Codex, from OpenAI, are coding agents that work in your terminal: you hand one a task, it reads the repository, edits the files and runs your tests until they pass. On a well-written ticket, both now do that job. For a team, the useful question is which job goes to which agent, and what each one costs per merged change.

That is the question the pages ranking for this comparison mostly leave to the reader. On 4 November the top results were one developer's impressions, a plan table, or a benchmark from a company with something adjacent to sell, and several still named older models. The public leaderboard for terminal agents, Terminal-Bench 4.1, puts the two about five points apart on score and about seven times apart on cost, both rows at max effort.

We run both at 2muchcoffee, so we ran the comparison ourselves and kept the diffs. Below: the method, the numbers, the diffs, the review, a second ticket in another language, what a team pays, and how we would split the work.

The first ticket: one open issue, written up, tests we kept back

The task is a real feature request, issue #631 on python-dotenv: an opt-in strict mode, so a missing .env file or a malformed line raises an error where today the library logs a warning and carries on. It is small, clearly specified and still open, which makes it a fair first test. The natural change touches six files: the library, the command-line tool, two test files, the README and the changelog.

We wrote it up as a ticket with twelve acceptance criteria. Then we wrote 23 acceptance tests of our own and kept them away from both agents. Against the unmodified library, 19 of them fail and 4 pass, the four that check that the default behaviour stays as it is.

load_dotenv() and dotenv_values() take strict=False

strict=True and the path is missing   raise FileNotFoundError, name the path
strict=True and a line is malformed   raise ValueError with its line number
any strict-mode error                 os.environ stays exactly as it was
strict and verbose both on            raise, log nothing first
stream= input                         parse errors raise; a stream is never "missing"
empty .env file                       valid
strict=False                          today's behaviour, unchanged

dotenv run --strict                   parse error: non-zero exit, line number,
                                      and the command does not run

README section, CHANGELOG entry, tests in the existing test files,
full suite green

Each agent got a fresh copy of the repository, its own virtualenv, the same one-paragraph prompt, and ran unattended after launch. Claude Code ran headless on its account default, Claude Opus 5.5. Codex ran headless on GPT-6.1 Sol at medium reasoning effort, the model we have configured, which OpenAI describes as offering near-Astra performance at lower cost than its top model. Both ran on flat-rate plans we already pay for. Three runs each, all scored by one script.

Hold on to that model detail, because it explains a good part of the cost column. Each agent ran as it ships, or as we run it, which is the comparison a team faces, and the two configurations sit at different points on their vendors' price lists.

A tie on correctness, and a wide gap on tokens

On correctness, this ticket is a tie. Every run passed every test we kept back, and every run left the existing suite green.

On this ticket Claude Code finished first in all three pairs, by seven to thirty-one seconds; the second ticket evened that out. Codex used about half the input tokens and a little under half the output, and at list price a Claude Code run came to roughly five times a Codex run.

Two things sit inside that ratio, and both matter before you quote it. The first is model tier: Claude Code ran on Opus 5.5, the default on our account, and Anthropic prices Fable 5.2 above it, while GPT-6.1 Sol is OpenAI's cheaper near-top model. On the same public leaderboard, Codex on GPT-6 Astra matches Sol's score at about five times Sol's cost, so on Astra most of our gap would likely close. The second is the agent itself: over half of every Claude Code figure is writing its prompt cache with a one-hour lifetime, which pays back across a long session and costs extra on a two-minute one.

And on a flat-rate plan, tokens buy headroom. Claude Code draws from the same limits as your chats, and on the OpenAI side ChatGPT Work and Codex share usage. A leaner agent reaches a given limit later, but readers choose on quota, and the five-hour and weekly windows sit outside what we measured.

Where the two diffs differ

Both agents arrived at nearly the same design: a strict flag on the loader class, an error raised where the file turns out to be missing, another at the first unparseable line, and the whole file parsed before anything touches the environment. The differences are the kind a maintainer comments on, and each one repeated in all three runs.

Claude Code works to the file in front of it. It added a separate helper for the raising path, printed CLI errors to stderr and exited the way the neighbouring commands already do, and matched the changelog's link-reference style. It also left the README's table of contents untouched each time, so the new section sits outside the index.

Codex works to the framework. It threaded the flag through the existing warning helper, so a function named for warning now raises. It used Click's own exception for the CLI error, which is the idiomatic Click move, and added the table-of-contents entry every time. When the caller passes a pathlib.Path, its missing-file error prints the object itself, PosixPath('/x/.env'), where a reader expects a plain path.

# Claude Code: a new helper next to the old one
def _raise_for_invalid_lines(mappings, dotenv_path=None):
    for mapping in mappings:
        if mapping.error:
            raise ValueError(
                "python-dotenv could not parse statement starting at line "
                f"{mapping.original.line}{location}"
            )
        yield mapping

# Codex: the existing warning helper grows a flag
def with_warn_for_invalid_lines(mappings, strict=False):
    for mapping in mappings:
        if mapping.error:
            if strict:
                raise ValueError(
                    "python-dotenv could not parse statement starting at line "
                    f"{mapping.original.line}"
                )
            logger.warning(...)
        yield mapping

Codex wrote more test cases, mostly by parametrizing one test across several inputs. Claude Code wrote more source, 62 lines against 40 at the median, including its separate helper and longer docstrings. Our own comments on the diffs were about style, naming, messages and small edge cases, and every behaviour our tests checked was right in all six. Our tests, though, covered only what we had thought to ask.

The defect all six runs shipped, and the review that caught it

Then we swapped. Each agent reviewed the other's diff in a fresh session, with the ticket and a one-paragraph review prompt that asked for findings by severity and said Do not edit any files. Codex reviewed inside its read-only sandbox, which lets it run commands and blocks writes. Claude Code's first review had read-only tools, and its next three could run commands too, to keep the comparison level.

Codex found a real defect in every review. The ticket says a strict-mode error must leave the environment exactly as it was. A quoted key such as 'BAD=KEY'=value parses cleanly, so the strict parse passes, and then the operating system rejects that variable name after the lines above it are already set. Codex found it the same way each time: it wrote a short probe and ran it. One review also caught that a bad line after a blank line is reported one line early.

Both defects live in the unmodified library, so both agents inherited them, and our own held-back tests missed the first one as well. The ticket's wording is what makes them strict-mode defects, and Codex's own three diffs carry both. This is a finding about the review step, and it says little about which agent writes better code.

All six implementations passed. The defect surfaced in review, from a reviewer that ran the code.

Claude Code's reviews read like a maintainer's: the changelog, the error messages, the edge case of a directory passed as a path, the naming, the exception handling. We checked every one of those, and each held up, including a formatting failure in one Codex run that would have turned the CI lint job red. Across four reviews, the partial load stayed out of view.

One more detail from these reviews. Under a prompt that asked for a read-only review, one Claude Code review ran git stash to compare lint output against the clean tree, then restored the tree and said so. Every change came back, and the diff matched before and after. That is partly our configuration, since we had granted it the shell. It happened twice more on the second ticket, for a better reason.

The second ticket: a one-line fix in TypeScript

The first ticket was a Python feature across six files. To see what carries over, we ran a different kind of change in a different language: issue #566 on yargs-parser, the argument parser behind yargs. A bare -- marks the end of options. When it follows a short flag such as -b, the parser takes -- as that flag's value and keeps reading options after it. A maintainer traced it, on the issue, to a parser change in version 11.1.0.

The issue text names the fix. Our ticket gave the reproduction, the output the README documents and nine criteria, and left the cause for the agents to find. Nothing reached the network during the runs. We wrote 23 held-back tests again, and the unmodified parser fails 16 of them. Three of the seven that pass are traps for a fix that reaches too far, such as -b -, where a single dash must stay the value because command-line tools use it for standard input. Everything stayed in our sandbox, since the project takes pull requests by maintainer invitation.

All six runs passed all 23 tests and wrote the same one-line code fix, character for character, in the same place, and Claude Code's three runs added a one-line comment above it. Codex was faster in two of the three pairs this time, so across both tickets we saw no stable speed difference. The cost gap held: at list price a Codex run came to about a quarter of a Claude Code run.

The tests are where they parted, along the same lines as on the first ticket. Claude Code wrote seven to ten named examples, each with the exact output it expects, in a block of their own with a link to the issue. Codex wrote a matrix that compares each short flag's output with its long form across option types and settings, and filed it inside the existing tests for the populate-- setting; one run added 177 generated cases to a suite of 365.

Then the swap again. Codex read each Claude Code diff, ran the suite, the type check and the linter, and gave a clean verdict in under half a minute, three times out of three, which on this diff was the right call. Claude Code's three reviews of Codex agreed with each other on the tests: they sit under a heading about a different setting, they compare the short form with the long form without pinning what either should be, and the matrix asks a lot of a maintainer. We checked each point against the diffs, and each held.

Two of those reviews went further. They set the fix aside with git stash, rebuilt, watched the new tests fail, and put the fix back, which is the strongest check either reviewer made on this ticket. Across both tickets, three of the six Claude Code reviews that had the shell rewrote the working tree under a prompt that said to leave it alone, and every tree came back identical.

That is the clearest picture of the two defaults. Codex documents an OS-enforced workspace-write sandbox as the default for local work, while Claude Code's baseline is a permission layer and its OS-level Bash sandbox is something you switch on. When we asked Codex to run that same git stash inside its read-only review sandbox, the operating system refused the write: the tree stayed safe, and the check stayed out of reach. A prompt asks and a sandbox enforces, so the setup we would recommend gives a review agent its own throwaway copy of the branch inside a sandbox, where it can break things to prove a point and where a hostile diff can reach little: Anthropic's own security-review action warns it is not hardened against prompt injection.

This ticket has its limits too: the fix is a single line, so it tested finding a cause and testing it with care, and it leaves large changes to a later run. Both tickets were also well specified, so vague tickets stay untested here, and on Hacker News the reports run both ways.

What it costs a team in November 2026

Our runs are two small tickets, so they are worth setting beside a larger public measurement. On Terminal-Bench 4.1, which grades agents on long terminal tasks, Claude Code with Opus 5.5 holds the top score at 65.8 percent and Codex with GPT-6.1 Sol scores 60.9, at about a seventh of the cost. Both rows ran at max effort and ours at default and medium settings, so compare the ratios and leave the dollar totals aside. On harder work than ours, Claude Code buys points with tokens, and the cost ratio points the same way as ours.

The plans themselves start at the same place. Prices below were read from the vendors' pages on 4 November and change often.

Review is now a line item of its own. Anthropic's Code Review went generally available on 15 October for Team and Enterprise. Its launch post says most reviews finish in six to ten minutes, and its setup page puts the average at 20, billed on usage credits outside the plan at an average of $15 to $25 a review. Codex's GitHub reviews count as Code Review usage, while reviews run locally count toward general limits, and they flag only P0 and P1 issues, which matches the short, high-signal reviews we saw from Codex locally. One Hacker News reader calls the hosted price absurd; for scale, our local cross-reviews cost $0.05 to $0.36 each at list price, on small diffs and without that product's verification pass.

At real scale there is a third option on the table. Revolut told the AI Engineer conference in New York how it made a self-hosted model its default, and The Register reports roughly 90 percent lower AI-coding inference costs as a result, with commercial models kept for vision queries and the work the self-hosted one does not cover. For a team of ten, the useful number is still the per-seat plan and how often people reach its limit.

How we would split the work between them

On client work, Claude Code and Codex implement in parallel, each in its own branch, against a written ticket, and a senior engineer reviews every merge; that loop is on our AI page and in the spec-driven development piece. These two tickets add one step we think belongs in that loop: let each agent review the other's branch before the engineer does. Each review took under a minute and cost well under a dollar at list price. Across thirteen reviews, every real finding came from exactly one of the two reviewers: Codex's caught a behavioural defect that every implementation, and our own tests, had carried, and Claude Code's caught the naming, messages and test design a maintainer would send back.

From these runs, the split we would draw:

• Both agents on review, each reading the other's branch. Codex reviews short and runs the code: it found the behavioural defect every time on the first ticket and gave a correct clean verdict in under half a minute on the second. Claude Code reviews like a maintainer, down to the design of the tests, and checks its claims by running them.
• Codex for well-specified tickets where token cost adds up across a team: at list price it ran at a fifth to a quarter of Claude Code's cost, with the same results on our tests.
• Claude Code for changes where the codebase's own conventions matter: it matched the file's style on the first ticket and wrote the tests a maintainer would keep on the second. Claude Code is part of how our engineers deliver from the written spec through review.
• A senior engineer on every merge, still. Each reviewer caught defects the other passed over, and one slipped past our hand-written tests as well.

Cross-review has a failure our thirteen reviews are too few to show. One r/codex write-up counts 115 findings on 42 pull requests, real bugs among them, and the same missing sign-off flagged on eight in a row. The rule we would take from that thread: a repeated finding stays open until a won't-fix is written where the next reviewer reads it.

Run both from one instruction file. Codex reads AGENTS.md before any work; Claude Code can read AGENTS.md too, though by default a CLAUDE.md in the same tree takes precedence. In the repository behind our website, AGENTS.md holds the instructions and CLAUDE.md is a short file that imports it, so both agents read the same rules. The same habit keeps a team portable, which was also the point of the spec-driven development tools piece.

Run it on your own repository

Pick one open issue in a repository with a test suite. Write it up as a ticket with acceptance criteria, then write fifteen to twenty-five tests of your own and keep them out of the agents' reach. Run each agent headless on the same prompt three times in fresh copies, then have each review the other's diff with the ticket in hand. Check every review finding by running it. It is an afternoon, the tokens cost cents at list price, and you come away with numbers from your own stack, which beats any page on this subject, ours included.

FAQ

Which is cheaper, Claude Code or Codex? At the entry tier they cost the same, and both come inside a general chat plan. Per task at API list prices, Codex on GPT-6.1 Sol came to between a fifth and a quarter of Claude Code on Opus 5.5 across our two tickets, and the public Terminal-Bench leaderboard points the same way. Part of that gap is model tier: Codex on GPT-6 Astra costs several times more than on Sol.

Is Claude Code or Codex free? Claude Code comes with Anthropic's paid plans, from Pro up. Codex has a free tier for quick tasks in the desktop app, with Go, Plus and Pro above it. The Codex CLI is open source under the Apache 2.0 licence, and Claude Code is proprietary, so with either one you pay for the model through a plan or an API key.

Is there a Claude Code equivalent for Codex? Codex is that equivalent: OpenAI's coding agent, with a terminal CLI, an IDE extension, a cloud agent and a desktop app. Both read a project instruction file, both run your tests, and both offer a pull-request review product.

Which is better for code review? In our runs they reviewed differently. Codex wrote short reviews and ran the code: it found the partial-load defect in all three reviews of the first ticket and gave a correct clean verdict on the second. Claude Code wrote fuller maintainer reviews that caught naming, messages, changelog style, a lint failure and the design of the tests. Using both, and keeping a senior engineer on the merge, catches more than either alone.

Can Claude Code and Codex share one instruction file? Yes. Codex reads AGENTS.md. Claude Code reads AGENTS.md too, and where a CLAUDE.md exists it takes precedence, so keep that CLAUDE.md to a short file that imports AGENTS.md. Either way, one file holds the rules and both agents follow it.

Should a team standardize on one? Standardize the ticket, the tests and the review gate, and let the agent vary. On both of our tickets each agent delivered correct code, while they differed on price, diff style and how they review. Running both against the same tickets for a sprint shows which mix suits your codebase and your budget.

How 2muchcoffee runs both for clients

We build production software with both agents inside the loop described above: a written ticket with its tests, Claude Code and Codex in parallel branches, and a senior engineer reviewing every merge. If your team is choosing which agent to standardize on, or wants both running against the same tickets behind one review gate, that is a conversation worth having before the seats are bought.

The plain way in is the AI and engineering work we do.