A side-by-side observation, not a winner
Claude Code has more observed tokens than Codex CLI in this snapshot. Claude Code accounts for 63% and Codex CLI accounts for 29%of eligible tokens in the 30-day cohort. This difference describes usage intensity among opt-in participants—not product quality, preference, or industry-wide market share.
Same window, same definitions
Claude Code and Codex usage scorecard
Each card uses the same trailing 30-day snapshot. Reach counts distinct listed developers with an eligible row; token metrics sum the usage those rows expose.
Claude observed tokens
580.03B
Aggregate tokens attributed to Claude Code in the window
Codex observed tokens
267.62B
Aggregate tokens attributed to Codex CLI in the window
Claude token share
63%
Share of all eligible cohort tokens
Codex token share
29%
Share of all eligible cohort tokens
Claude participants
135
What this comparison can answer
- Observed usage intensity
- Which tool accumulated more tokens in the same 30-day opt-in cohort, and what share of all eligible cohort tokens each tool represents.
- Observed participant reach
- How many listed developers had at least one eligible Claude Code or Codex CLI usage row during the window, both as a count and as a share of the cohort.
- Usage concentration per participant
- The average observed tokens per participating developer for each agent. This describes the row aggregate; it does not reveal the distribution between light and heavy users.
- Observed model and recorded cost mix
- The leading model by attributed tokens and the recorded API-equivalent cost divided by all observed tokens, normalized to one million. The rate is a lower bound whenever pricing coverage is incomplete.
What the data cannot answer
These aggregates do not support claims about product quality, developer productivity, model efficiency, satisfaction, preference, revenue, installations, or industry-wide market share. Higher token usage is not evidence that a tool is better, worse, faster, more capable, or more economical. The data also cannot show whether a participant used a tool by choice, because of an employer policy, or for a specific kind of task.
Participant reach and token share answer different questions
Breadth
Participant reach
Reach divides an agent's distinct participating developers by every listed developer with eligible usage in the window. One developer can appear in both agent rows, so the percentages overlap and are not market shares.
Intensity
Token share
Token share divides one agent's observed tokens by all eligible tokens in the cohort. A smaller group of intensive users can create more token volume than a larger group of occasional users, without establishing preference or quality.
Why API-equivalent cost is not a subscription invoice
The recorded API-equivalent cost per 1M observed tokens takes the positive cost estimate attached to a tool row, divides it by all of that row's observed tokens, and multiplies by one million. Because unmatched or unpriced model usage can remain in the token denominator without adding to recorded cost, the result is a lower bound when pricing coverage is incomplete—not a complete blended price. A non-positive recorded cost is shown as Not available, never as free usage. The metric also does not reconstruct what a participant paid for Claude Code, a ChatGPT plan, credits, enterprise seats, taxes, negotiated rates, promotions, or bundled allowances. Provider billing records remain the source of truth for actual spend.
A short worked method
01 · select
Match the agent rows
Request 30d insights and select exact tool IDs claude and codex.
02 · normalize
Keep denominators explicit
Tokens per participant = tokens ÷ agent developers. Recorded API-equivalent cost per million = costUSD ÷ observed tokens × 1,000,000, only when both values are positive. The cost result is a lower bound if pricing coverage is incomplete.
03 · interpret
Report an observation
Name the window and cohort, compare the returned values, and stop before drawing conclusions about quality, preference, productivity, or the wider market.
Methodology and limitations
Window and record selection. The page asks the public insights API for its trailing 30-day aggregate and matches the exact tool IDsclaude andcodex. It shows a data-unavailable state unless both rows are present; missing data is not converted to zero and earlier snapshots are not carried forward.
Token and reach measures. Observed tokens, token share, developer count, and leading model come directly from each returned tool row. Cohort reach divides tool developers by the response's cohort developer count. Tokens per participant divides tool tokens by tool developers. Participants can use both agents, so reach percentages overlap.
Cost normalization. Recorded API-equivalent cost per million observed tokens equals row costUSD ÷ row totalTokens × 1,000,000 when both values are positive. A non-positive cost or token denominator returns Not available. Because model price matching can be incomplete while all observed tokens remain in the denominator, the displayed rate is a lower bound rather than a complete blended price. Subscriptions and provider invoices use different commercial rules.
Limitations. Participation is opt-in, public, and not weighted to represent all developers. Local integrations differ in log coverage, model identifiers can be incomplete, and large users can dominate token totals. Aggregates contain no task outcome, latency, code-quality, satisfaction, or causal evidence. The result is a cohort usage comparison—not a benchmark, product review, preference survey, revenue estimate, installation count, or market-share report.
Sources
- whoburnedmore public insights API
Aggregated model, agent, trend, skill, and tool-call totals from participating developers.
- LiteLLM model pricing dataset
Public model pricing reference used for API-equivalent estimates; provider billing remains authoritative.
- Data collection and privacy methodology
Explains what the CLI aggregates, what it does not collect, and the limits of the public cohort.