What a Build Actually Costs: Reading the Gap Between 23% and Four Times

One controlled test says 23%. A build-along video says four times. Both are defensible, and neither is a forecast for your repository.

Every published figure disagrees, and that is the finding

Ask what a real project costs on each of the two coding agents and you get numbers that do not merely differ, they differ by an order of magnitude in the ratio. A controlled comparison run by Composio put Claude Code at roughly 192,000 tokens and about $2.50 against Codex at roughly 136,000 tokens and about $2.04 on identical tasks — a 1.4× token gap and about 23% more money. Benchmark figures published in August 2026 for DeepSWE resolution put a Claude task at $11.84 against $8.39, which is nearer 41%. Informal hands-on comparisons, of the kind that circulate as build-along videos, have reported Claude Code builds costing three to four times as much.

The instinct is to work out which of those is right. The argument here is that they are all defensible measurements of different things, that the spread between them is more informative than any single figure in it, and that anyone quoting one number without saying what was measured is telling you almost nothing about what your project will cost.

That matters practically, because the decision people make on the back of these numbers — switch tools, change tiers, restrict who can use what — is expensive to reverse and is usually made on the largest ratio somebody saw.

The four things people mean by cost

Before comparing figures, separate the quantities, because published comparisons rarely say which one they are reporting.

Tokens consumed is the raw count the harness burned: prompt, output, reasoning, and everything the agent read along the way. It is the only quantity that is purely a property of the tool's behaviour.

API cost is that count priced at per-token rates. It moves with the model chosen as much as with the tool, which is why a comparison that does not name the models on both sides is not a comparison of tools.

Subscription cost is what most people actually pay, and it is flat. On a $20 or $100 seat, a task that burns twice the tokens does not cost twice the money. It costs the same money and brings the ceiling closer.

Cost to completion is what the work cost including the attempts that failed. A cheaper run that produced something you had to redo was not cheaper.

The 23% figure and the 3× figure are not in conflict once you notice that one is a controlled per-task API measurement and the other is a whole build including retries, sub-agent fan-out and whatever the operator did when it went wrong.

Why the architectural difference produces a token difference

The token gap is real and it has a structural explanation that does not require anyone to be inefficient.

Claude Code's harness leans on fan-out. Subagents explore parts of a codebase in parallel; each one carries its own context and returns its own summary. Skills, hooks and plugins inject material into the session. That design buys coverage on problems where the answer is spread across files nobody thought to open, and it is why the tool is strong on large multi-file work. It also means the token count for a hard task is not one conversation, it is several, plus the cost of reconciling them.

Codex's harness has historically optimised the other way: keep one capable agent, keep state light, return a diff. Fewer parallel contexts is fewer tokens for the same nominal task, and on work where the relevant material is already obvious, the fan-out was buying nothing.

Read that as a design trade rather than as one tool being wasteful. The question a cost figure cannot answer on its own is whether the extra tokens bought anything on the task you actually ran.

Where the largest ratios come from

The three-and-four-times figures generally come from long, ambitious, single-session builds — the kind where somebody asks for a whole application and lets it run. Several things compound in exactly that setting, and none of them compound in a controlled per-task benchmark.

Sub-agent fan-out multiplies with task ambiguity: a vague brief produces more exploration, and exploration is where the parallel contexts open. Long sessions accumulate context that is re-read on every turn until compaction runs. Retries in an interactive session are often invisible in the accounting, because the operator steered rather than restarting, and the steering is billed. And reasoning depth, if it is left at a high setting for a whole session, is charged as output tokens on the mechanical middle of the work as well as on the hard parts.

A controlled benchmark suppresses every one of those. It uses a specified task, a bounded context and a single attempt. That is why it reports 23% and the build-along reports 300%: they are measuring a well-posed task and a badly posed one respectively, and the badly posed one is more like your Tuesday.

~23%   Composio, controlled task, API pricing, one attempt
       192k vs 136k tokens; $2.50 vs $2.04

~41%   DeepSWE resolution, Aug 2026 benchmark figures
       $11.84 vs $8.39 per task; 74% vs 73% resolved

3-4x   Hands-on build comparisons, whole project, interactive
       session, retries and steering included, models often
       not matched across the two runs

0%     Anyone on a flat subscription who did not hit the cap

The subscription line is the one most people are actually on

All of the above is API accounting, and most working developers are not paying per token. They are on a seat, and for them the question is not what a build cost but how many builds fit before the window closes.

That reframes the comparison entirely. Token efficiency stops being money and becomes headroom: the efficient tool lets you do more work between resets. It also introduces a factor no per-token figure captures, which is that Claude Code's allowance is shared with the same account's chat usage, so an afternoon of unrelated conversation eats into the coding budget. A per-task cost comparison cannot see that at all, and for a lot of people it is the dominant effect.

Which of the two ceilings is more generous is genuinely contested and moves with every pricing change, so I am not going to assert a winner. What is stable is the shape: if you are on a seat, measure how often you hit the ceiling doing your actual work for a fortnight. That number is yours, it is cheap to collect, and it beats every published ratio.

Measuring it on your own work, which takes an afternoon

The measurement that matters is the one on your codebase, and it does not need a rig. Pick five tasks that are representative and specified well enough that a competent stranger could do them. Run each on both tools, from the same starting commit, with the models you would actually use. Record four things per run.

tokens_in / tokens_out    from the tool's own usage report
wall_clock                start to reviewable result
attempts                  restarts and mid-run corrections
outcome                   accepted / accepted with edits / redone

Then price it two ways: at API rates, and as a fraction of your seat's window. The two answers will disagree, and the disagreement tells you which constraint you are actually under. Report the median and the worst run, not the mean — the mean of five runs where one went badly is a number that describes no run you had.

Five tasks is enough to see a 3× effect if it is there. It is not enough to resolve a 23% one, and you should not pretend otherwise; if the gap on your work is that size, it is smaller than the variance between your own briefs and you should choose on something else.

The variables that dominate the tool choice

Every published comparison holds these constant and your team does not, which is why your ratio will not match anybody's.

Brief quality is the largest. A task specified to the point where the agent does not have to guess costs a fraction of the same task described loosely, on either tool, and the gap between a good and a bad brief is routinely larger than the gap between the two products.

Model selection is next. A comparison that ran a flagship model against a mid-tier one measured the price list, not the harness. Note that the tiers do not line up: at the $20 mark the two vendors have historically included different classes of model, so the naive same-price comparison is not a same-capability comparison in either direction.

Then reasoning depth, which is billed as output and is frequently left at one setting for a whole session. Then session length, because context that is never compacted is re-read. Then how many people on the team let an agent run unattended on an ambiguous brief, which is the single most expensive habit either tool supports.

What I would actually conclude

On the evidence available, Codex is the more token-efficient harness on comparable tasks, and the direction of that finding is consistent across every source I can check. The magnitude is not: defensible published figures run from about 23% to about 41% on controlled tasks, and informal whole-project comparisons run far higher for reasons that are mostly about session shape rather than about the tools.

If you are paying per token on well-specified tasks, that difference is real money and worth acting on. If you are on a subscription, it is headroom rather than money, and the sharing of the allowance with chat usage may matter more to you than the per-task gap. And if your briefs are vague, you have a much larger and much cheaper saving available than switching tools.