# Codex vs Claude Code: What Each Is Good At, and When You Would Pick the Other
> Two coding agents measured on the same work queue for three months: how a turn runs, how the usage windows behave, what one subscription of each actually delivered, and which circumstances favour Codex, Claude Code, or both.
- Canonical: https://jedarden.com/guides/codex-vs-claude-code/
- Published: 2026-11-01
- Last verified: October 31, 2026 (2026-10-31)
- Tested with Claude Code 2.1.316 and Codex CLI 0.166.0 — telemetry through October 31, 2026. (2026-10-31)
- Tags: claude-code, codex, agents, subscriptions, fleet-ops
---
**Codex and Claude Code are the same loop in two different wrappers, and the
wrappers are what you are paying for.** Both read an instructions file, run
shell commands, patch files, verify, and report. Both now sell the same
ladder of plans: an entry tier at $20 with a five-hour window and a weekly
cap, and top tiers at $100 and $200 where the five-hour window goes away.
The question people are actually asking when they search this comparison is
which $200 to spend, or whether $400 for both is defensible. I have run both
against the same queue of work since August 2026, from a terminal and from a
fleet of unattended workers, and the logs answer that question better than
another afternoon of impressions would.
> **TL;DR** — Pick **Claude Code first** if you work in the terminal and
> steer, if a team has to share conventions, or if you need a hook that can
> block *or rewrite* a command before it runs. Pick **Codex first** if you
> hand off tasks and come back, if continuity matters more than a tidy quota
> boundary, or if you already pay for ChatGPT. Buy **both** only when the
> work is parallel or around the clock; one top-tier plan of either carried
> about two always-on workers in my fleet, and the second plan buys a second
> meter that does not fail at the same moment. Stay on **pay-per-token** if
> you use an agent under five hours a week and have neither plan already.
## Which one fits you?
If the quiz does not load, the questions it asks are these, and the sections
below answer each one:
1. How many hours a week will an agent be working for you?
2. What do you want to spend a month: $20, $100, $200, or $400?
3. Do you already pay for ChatGPT or Claude for chat?
4. Do you steer every step, hand off tasks and come back, run several at once, or need it unattended in scripts and CI?
5. When a limit hits, what matters more: a predictable reset, never being blocked mid-task, or the cheapest tokens per finished task?
6. Solo, a small team sharing conventions, or a platform team setting guardrails?
7. Do you need hooks that can block or rewrite a command before it runs?
## What was measured
Everything in this guide comes from one machine that has run both agents
against the same queue of work since the summer of 2026: about three thousand
terminal sessions where a person typed, seven hundred of them an hour or
longer, and a fleet of unattended workers that claimed small tasks from a
shared backlog, did them, and pushed. Both agents keep a complete record of
every session on disk, and both subscriptions were polled every five minutes
by a governor whose job was to keep the fleet under the usage caps. That left
four kinds of evidence:
- **Session logs.** Every Codex rollout since the day Codex was installed
here (about 40,000 files, 46 GB, August 3 to October 31) and every Claude
Code transcript from July 9 to October 31 (about 96,000 files, 76 GB), read
once end to end: turns, tool calls, tokens by kind, compactions, errors,
versions. Codex keeps every session on disk; Claude Code deletes a
transcript thirty days after its last write, so its earlier months were
read back from this machine's own off-site copy.
- **Usage meters.** 15,000 five-minute readings of each subscription's
windows: how full, when they reset, how long anything sat at the cap.
- **Delivered work.** Tasks closed, attempts verified, commits landed, by
which agent did them.
- **The vendors' own pricing pages**, captured the day this was written.
Two caveats before any number. First, most of the volume is automated:
unattended workers running one task at a time, not a developer typing, so
"what one subscription delivers" here is an upper bound on sustained use,
not a picture of an afternoon's pairing. Second, in every month measured the
fleet's Claude Code workers ran GLM models through a third-party coding plan
rather than Anthropic's models (90 of 82,000 unattended sessions used an
Anthropic model), so where the Claude column says "fleet" it is the harness
being measured, and where it says "interactive" it is Anthropic's models on
an Anthropic plan. That fleet also ran on three other machines, which the
study counts but the per-machine numbers here do not. The Codex workers ran
on this machine, all on OpenAI models through one ChatGPT Pro plan.
## How a turn runs in each
Read a Codex rollout and a Claude Code transcript side by side and the
skeleton is identical. An instructions file is loaded. The model reads,
runs shell commands, patches, runs the tests, and writes a summary. In both
corpora the shell is most of the work: 75% of Claude Code's tool calls are
Bash, and 89% of Codex's are shell commands. Both keep their standing
context in the prompt cache and read it on every call, which is why 93 to
98% of all input tokens in both logs are cache reads. The differences are
in what wraps that loop, and the first chart puts the structural ones side
by side.
| Share of | Claude Code | Codex |
|---|---|---|
| Tool calls that are shell commands | 75% | 89% |
| Input tokens served from the prompt cache | 96% | 97% |
| Output tokens that are reasoning or thinking | 7% | 52% |
| Tokens spent inside sub-agents | 8% (17% in interactive sessions) | 5% |
| Sessions that compacted their context | 0.9% (2.5% interactive) | 3.7% (7.2% agentic) |
**Instructions.** Claude Code attaches `CLAUDE.md` from the home directory
and the repository, plus `AGENTS.md` if present, to every request. Codex
injects `AGENTS.md` ahead of the first message; it was present in 99.9% of
its sessions here. If you keep one `AGENTS.md` and have `CLAUDE.md` point
at it, both harnesses read the same rules, which is how this machine runs.
**Tools.** Claude Code exposes named tools: Bash, Read, Edit, Write, a
subagent tool, web search, MCP. Codex exposes one `exec` tool that takes a
snippet of JavaScript calling `exec_command`, `write_stdin`, `apply_patch`
and friends. The practical consequence shows up on long-running commands.
Claude Code blocks on a command with a timeout or sends it to the
background. Codex yields after a few seconds and then polls the running
command with `write_stdin`, and every poll re-sends the whole context. In
one fleet session a twenty-poll wait on a test gate was 2.4 million of the
session's 6.8 million tokens.
**Permissions and hooks.** This is the largest real difference. Claude Code
has permission modes and a hook system where a PreToolUse hook can allow,
deny, ask, or rewrite the tool's input. On this machine two hooks bracket
every Bash and Edit call: a secret pre-write scan and an organisation rule
guard that blocks workflow files, Kubernetes Jobs, floating image tags and
mutating cluster commands. Codex has an approval policy and a sandbox mode,
and its hook schema accepts the same three decisions, but its runtime
honours **deny alone**: a hook can veto a Codex command and nothing else.
Every veto surfaces to the agent as a failed tool call it then routes
around. That is not a small gap in practice. In a four-day sample of 2,056
Codex sessions the guard rejected 456 commands; the agents rewrote their
cleanup in Python or found another path, which is fine for `rm -rf` and not
fine when you wanted the command *changed* rather than refused. The fleet
ran Codex with `approval_policy = never` and full filesystem access in all
but eleven sessions, and not one approval prompt ever fired; the hook was
the guardrail.
**Delegation.** Claude Code's subagent tool spawns a child with the full
standing context, and the child re-reads that context on every call. Over
four months of interactive sessions subagents consumed 17% of all tokens for
4% of the output, and in October alone, when Opus did most of the
delegating, 34% for 4%. They are excellent for research and expensive for
routine edits.
Codex has `spawn_agent` and `wait_agent`; 856 sub-agent threads here were
4.9% of its tokens, mostly short.
**Context.** Both compact automatically. Claude Code compacts an interactive
session at about 300,000 live tokens down to about 12,000 (fleet sessions
earlier, around 170,000), and will also compact while idle before the cache
expires; under 1% of sessions ever got there, 2.5% of the interactive ones.
Codex compacts at about 246,000 of a 258,000 window,
re-injects `AGENTS.md` and a summary, and does so in 7.2% of agentic
sessions. Neither corpus contains a context-length error.
**Shape.** A Codex interactive thread is a heavy object: a median of 8.5
million cumulative tokens and 19 active minutes. Claude Code's interactive
sessions had two shapes, and which one dominated depended on who was doing
the work. In July, before the fleet carried the backlog, the median terminal
session ran 6.9 hours with 84 tool calls; by October the median was under
two minutes with no tool calls, while the long sessions still ran for hours.
Some of the Codex weight is structural: 52% of its output tokens are
reasoning, and the poll-while-waiting pattern bills the context again on
every poll. A fleet task is similar on both: about 1.6 million cumulative
tokens and five minutes for Codex, four to twenty tool calls and three to
fifteen thousand output tokens for Claude Code depending on the model behind
it.
**Records.** If you need to audit what an agent did, or charge its work to a
project, the two wrappers default differently. Codex writes every session to
`~/.codex/sessions` with per-turn token counts and the usage-window reading
at the time, and leaves it there; nothing has gone missing in three months
here, and the oldest rollout is from the day it was installed. Claude Code's
transcript is richer, with its own running
dollar estimate since late August, but it is deleted thirty days after the
last write unless you raise `cleanupPeriodDays`. Codex gives you the record
by default; Claude Code gives you thirty days to copy it somewhere.
**Versions.** Both ship constantly. The transcripts record 86 Claude Code
releases in 115 days and 21 Codex CLI releases in 90. A long-lived
interactive session keeps the version it started on; the fleet picks up a
new release within a day. Anything in this guide about how a turn runs is
true of the versions in the "Tested with" line and may not be true next
month, which is why a weekly check flags this page for a refresh.
## The usage windows, as they behaved
The plan pages describe the windows. The meters describe how they behave
under load, and the two accounts behaved differently in ways the pages do
not tell you. Seven weeks of both meters, side by side:
Every Claude weekly window observed ran exactly seven days and reset on a
Wednesday at 01:00 UTC; the peaks were 80, 46, 30, 15, 71, 51 and 19% of the
allowance. The Codex weekly windows in the same stretch:
| Codex window began (UTC) | Ended | Peak | At the cap |
|---|---|---|---|
| Sep 12 10:54 | replaced Sep 14 | 100% | 0.5 h |
| Sep 14 21:45 | full week | 100% | 4 h, 826 turns refused |
| Sep 21 21:51 | replaced Sep 26 | 55% | |
| Sep 26 16:58 | replaced Oct 2 | 100% | 11 h, credits drawn |
| Oct 2 21:13 | replaced Oct 7 | 92% | |
| Oct 7 03:28 | replaced Oct 11 | 100% | 39 h, credits drawn |
| Oct 11 03:58 | replaced Oct 13 | 53% | |
| Oct 15 06:13 | replaced Oct 17 | 96% | |
| Oct 17 20:40 | replaced Oct 20 | 80% | |
| Oct 26 11:03 | replaced Oct 28 | 35% | |
| Oct 28 06:35 | still open | 43% | |
**Claude.** The account exposes a weekly window, a second weekly window
scoped to the newest model, and a five-hour window, which is the Max plan's
shape. The weekly window resets at a fixed hour every week (here, early
Wednesday UTC) and that never varied. Under the governor the weekly peaks
were 80, 46 and 30% in September and 71 and 51% in October, with one to two
workers alive; the five-hour window never passed 23% at that fleet size.
Every cap hit in four months of transcripts came from the terminal, not the
fleet. The weekly cap was reached in three stretches: four sessions in the
week of September 15, 120 sessions on October 12 to 16, when the terminal
returned "You've hit your weekly limit, resets [day] 9pm" as a synthetic
assistant message, with no retry, and the session ended there, and six more
in the last week of October. The five-hour window bit ten times, four of
them on one July day during the long steering sessions, which is the one
place a five-hour window showed up in practice. A busy Claude session with a
frontier model burned about 2.3% of the weekly allowance per hour, which is
roughly 44 busy hours a week before the cap.
**Codex.** The Pro account exposes a weekly window only; the five-hour field
in every one of a million readings is empty, which matches the pricing
page. Two things about that window are not on the page. First, a reading of
100% before any credits were on the account meant a hard refusal: 826 turns
in the week of September 14 failed with "You've hit your usage limit ... try
again at 5:45 PM", 817 of them on their first request, and the seven that
were mid-task ended with no retry, no summary, and half-finished work on
disk. After credits were bought the window sat at 100% twice more, for 11
and 39 hours, with zero refusals while the credit balance fell instead.
Second, the window re-bases. Of 32 weekly windows observed on one account
and one login, only three ran a full seven days; 28 were superseded by a
fresh window at 0% after a median of about 2.3 days, abandoning 70 to 120
hours of the old one. The telemetry cannot say why. The practical effect is
that the weekly allowance was rarely the binding constraint for long, and
that "when does it reset" has no stable answer. A busy Codex session with
extra-high reasoning burned about 3.5% of the allowance per hour, roughly
29 busy hours a week, about 1.5 times the drain of a busy Claude session.
**Both.** An always-on but mostly idle automated worker cost about 0.3% of
either allowance per hour, so one top-tier plan of either carried about two
such workers around the clock. Neither account's five-hour window mattered
at that fleet size; the weekly meters carried the load. Put your own week
into those rates:
| Your week | Share of one Claude allowance | Share of one Codex allowance |
|---|---|---|
| 10 busy hours | 23% | 35% |
| 20 busy hours | 46% | 70% |
| 30 busy hours | 69% | at the cap |
| 44 busy hours | at the cap | at the cap |
| One always-on worker, no busy hours | 54% | 50% |
| Two always-on workers | at the cap | at the cap |
A busy hour cost about 2.3% of the Claude allowance and 3.5% of the Codex
allowance; an always-on but mostly idle worker about 0.3% an hour on either.
## What one subscription of each delivered
The caveat first, again: these are unattended workers on a shared backlog,
and the two fleets ran different models on different repositories, so the
yield numbers compare a Codex fleet with a Claude Code fleet on GLM, not
Codex with Claude on Anthropic's models. Anthropic's models were used from
the terminal, which leaves no attempt record, only commits. Week by week,
this is who carried the queue:
| Week | Claude Code sessions (unattended / typed) | Codex sessions |
|---|---|---|
| W29 | 0 / 53 | |
| W30 | 1 / 77 | |
| W31 | 2,674 / 158 | |
| W32 | 8,976 / 232 | 988 |
| W33 | 7,969 / 180 | 1,283 |
| W34 | 4,789 / 100 | 3,210 |
| W35 | 13,289 / 115 | 1,923 |
| W36 | 7,123 / 63 | 60 |
| W37 | 12,812 / 887 | 152 |
| W38 | 7,413 / 124 | 1,768 |
| W39 | 6,874 / 165 | 4,474 (weekly cap: 826 refusals) |
| W40 | 4,932 / 163 | 5,339 |
| W41 | 1,807 / 87 | 8,497 |
| W42 | 5,613 / 607 (weekly cap: 118 sessions) | 6,955 |
| W43 | 1,551 / 29 | 5,188 |
| W44 | 1,963 / 23 | 504 |
**One ChatGPT Pro plan, Codex.** Between September 12 and October 31 the
Codex workers made 9,708 attempts at tasks and 4,843 passed verification, a
yield of 50% counting the attempts that split a task into smaller ones and
61% without them. The median attempt took six minutes. Over sixty days that
was 5,757 tasks closed and 3,741 code commits, about 0.65 commits per closed
task; 18% of those closures were later reopened, almost always because the
worker had closed before pushing. The plan hit its weekly cap in four
windows out of 32 and refused work in one of them, the week before credits
were added. Its characteristic failure was process, not capability: the
three biggest failure kinds were finishing without a shipped commit (32%),
failing the close verification (26%), and leaving uncommitted work in the
checkout (18%).
**One Claude Max plan, Claude Code.** The Anthropic plan carried the
interactive work: about 3,000 terminal sessions between July 9 and October
31, 700 of them an hour or longer. The long sessions ran 40 to 100 a week in
July and August and 7 to 30 a week by October, as the fleet took over the
backlog; about 1,400 of the short ones were one-turn sweeps scripted around
the terminal on two days. The CLI began writing its own cost estimate into
transcripts in late August; from the week of August 24 to October 31 that
estimate sums to $16,500 over ten weeks, $900 to $4,300 a week in working
weeks and $50 to $180 in the two lightest, with July and early August, the
two heaviest months by output, not counted. In bead terms that was 280
closures and 293 commits claimed from a terminal, plus about 2,465 further
commits in ninety days carrying a Claude model trailer with no bead
attached, which is what a person steering an agent looks like in a git log.
The weekly meter peaked at 71% in the busiest October week at one to two
governed workers, and every cap the account hit was hit from the terminal:
in mid-September, in the week of October 12, and in the last week of
October. Only 91 fleet attempts ran Anthropic's models, too few to score.
**The same harness on a GLM coding plan.** For scale, the Claude Code
harness with GLM models behind it made 8,302 fleet attempts in the same
window at a 40% yield (43% without splits), with a median attempt of 28
minutes against Codex's six, and 5,542 code commits over sixty days, about
one per closed task. Over the full four months and four machines it ran
about 116,000 fleet sessions and a billion output tokens, carrying the
backlog alone from late July to the end of September before the Codex fleet
ramped up. Its biggest failure kind was not the agent at all: 41% of
failures were the proxy closing the stream mid-response, and in September
the proxy's rate limiter returned 96,000 retries in a month. The plan's
five-hour window never passed 57% at ten to twenty workers. That is the
other answer to the budget question: the harness is free, and the cheapest
capable model behind it changes the economics more than the harness does.
Read the three together and the shape is this. Per closed task, Codex was
the fastest and the most likely to close without finishing the paperwork;
the Claude Code harness on GLM was slower and more often killed by its
provider; Anthropic's models were spent where a person was watching, and
that use would have cost many times the plan at API rates.
## Where Codex is the better fit
- **You hand off and come back.** Codex's whole surface is built for a
task to run without you: `codex exec` was 96% of its sessions here, cloud
tasks share the plan allowance, and a Pro plan has no five-hour window to
pause a long run in the middle. Interactive Claude Code sessions are
heavier on the person; headless Claude Code works, but it is the mode the
product treats as a special case.
- **Continuity beats a neat boundary.** The re-basing weekly window and the
option to add credits meant that, after one bad week, Codex never stopped
mid-task again. If being paused is the failure you least want, that is
the record.
- **You already pay for ChatGPT.** Codex is included. Trying it costs
nothing but an `AGENTS.md`.
- **Your guardrails are vetoes, not rewrites.** If a deny is all you need,
Codex's hook does it, and its approval and sandbox modes layer on top.
- **You want the plan to tell you what it costs.** The model you get, the
credit rate per million tokens, and what a typical task spends in credits
are stated on the pricing page in a way the Claude page does not match.
You would switch, or add Claude Code, when you need a hook to rewrite a
command rather than refuse it, or when the work is a long interactive
session where plan mode, named tools and context management matter more
than hand-off.
## Where Claude Code is the better fit
- **You steer from the terminal.** Named tools, a plan mode, permission
modes you can tighten, and a hook that can ask you before a dangerous
command make the interactive loop the richer one. When a person was
doing most of the work here, in July, the median terminal session was a
seven-hour working session; once the fleet carried the backlog, the
terminal became a lookup console, with the long sessions still running
for hours when something needed steering.
- **A team shares conventions, or a platform team sets rules.** Claude
Code's PreToolUse hook can allow, deny, ask, *or rewrite* a tool call,
and managed settings can pin that for everyone. On this machine that hook
is the reason no workflow file, no Kubernetes Job and no floating image
tag has been committed by an agent, across both harnesses, because the
rule guard runs under Codex too, as a veto.
- **A predictable reset.** The weekly window reset at the same hour every
week in every observation. If you plan a team's week around a quota, that
predictability is worth something.
- **Cheaper hours at the cap.** A busy Claude session drained its allowance
at about two thirds the rate a busy Codex session did, and the Max plan
includes monthly API credits for overflow.
- **You already pay for Claude.** Claude Code is included from the $20 Pro
tier up.
You would switch, or add Codex, when a task should run while you are away
and a pause mid-task costs more than a predictable reset, or when the
subagent bill for routine work stops being worth the delegation.
## When you want both, and when you want neither
**Both, each with a job.** Two top-tier plans make sense when the work is
parallel or around the clock. One allowance of either carried about two
always-on workers here; two allowances carry four, on two meters that do
not drain together, with two different models to cross-check each other.
The way to make $400 defensible is to make the split operational: give each
harness a named class of work, keep one `AGENTS.md` both can read, and run
one shared acceptance check, so that what you compare is finished, reviewed
work and not tokens or turns. Drop one when its meter sits under half used
for three weeks running.
**Neither, for now.** Under five hours a week, with no plan already in hand,
pay per token through either vendor's API. There are no windows at all, and
both agents run on a metered key, although Codex's cloud features do not.
The break-even arrives early: the lightest week of interactive Claude use
here, two dozen short sessions, priced at about $50 at list rates, and a
week with real multi-hour sessions priced in the hundreds, so a $100 plan
pays for itself well before a day a week of real work. Read the bill after a
month and move up when it crosses the plan price twice.
**The $20 tiers.** Both carry a five-hour window on top of the weekly cap,
and the five-hour window is the one a single busy afternoon hits. They are
the right way to find out which loop you prefer; they are not the plan to
run a long task on while you are away.
## Tested with
Claude Code 2.1.316 and Codex CLI 0.166.0 were the installed versions when
this was written, and the telemetry runs from July 9 (Claude Code) and
August 3 (Codex) through 2026-10-31. August 3 is the day Codex was installed
on this machine, so its record is complete; July 9 is the first day the
Claude Code archive holds, not the first day the tool was used. Both tools
ship often: the transcripts record 86 Claude Code releases in 115 days and
21 Codex CLI releases in 90. The plan names and prices are the vendors' pages
as they read on 2026-10-31; both pages change without a dated changelog. A
weekly check compares the installed versions and the age of the telemetry
against this page and flags it for a refresh when either tool moves by a
minor version or the data passes ninety days. When the numbers are re-run
the versions above change with them, and the "Tested with" line under the
title is the one to trust.
— Jed