Codex vs Claude Code: What Each Is Good At, and When You Would Pick the Other

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?#

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.

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:

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:

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:

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