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
Claude Code has more observed tokens than Codex CLI in this snapshot. Claude Code accounts for 45% and Codex CLI accounts for 43%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
315.64B
Aggregate tokens attributed to Claude Code in the window
Codex observed tokens
304.74B
Aggregate tokens attributed to Codex CLI in the window
Claude token share
45%
Share of all eligible cohort tokens
Codex token share
43%
Share of all eligible cohort tokens
Claude participants
105
64% cohort reach
Codex participants
111
68% cohort reach
Claude tokens / participant
3.01B
Observed tokens divided by Claude participants
Codex tokens / participant
2.75B
Observed tokens divided by Codex participants
Claude recorded cost / 1M
$0.75
Lower bound when pricing coverage is incomplete
Codex recorded cost / 1M
$0.76
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
315.64B observed tokens
Codex CLI
304.74B 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.