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.
A side-by-side observation, not a winner
Codex CLI has more observed tokens than Claude Code in this snapshot. Claude Code accounts for 39% and Codex CLI accounts for 53%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
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
282.74B
Aggregate tokens attributed to Claude Code in the window
Codex observed tokens
384.51B
Aggregate tokens attributed to Codex CLI in the window
Claude token share
39%
Share of all eligible cohort tokens
Codex token share
53%
Share of all eligible cohort tokens
Claude participants
105
66% cohort reach
Codex participants
106
66% cohort reach
Claude tokens / participant
2.69B
Observed tokens divided by Claude participants
Codex tokens / participant
3.63B
Observed tokens divided by Codex participants
Claude recorded cost / 1M
$0.78
Lower bound when pricing coverage is incomplete
Codex recorded cost / 1M
$0.67
Lower bound when pricing coverage is incomplete
Claude leading model
claude-opus-5
Model with the most Claude-attributed tokens
Codex leading model
gpt-5.6-sol
Model with the most Codex-attributed tokens
The bars share a 0–100% scale. They show each tool's portion of the complete eligible cohort, so the two bars do not need to add to 100%: other coding agents account for the remainder.
Claude Code
282.74B observed tokens
Codex CLI
384.51B observed tokens
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.
Breadth
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 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.
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.
01 · select
Request 30d insights and select exact tool IDs claude and codex.
02 · normalize
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
Name the window and cohort, compare the returned values, and stop before drawing conclusions about quality, preference, productivity, or the wider market.
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.
Aggregated model, agent, trend, skill, and tool-call totals from participating developers.
Public model pricing reference used for API-equivalent estimates; provider billing remains authoritative.
Explains what the CLI aggregates, what it does not collect, and the limits of the public cohort.