What an OpenRouter Usage Chart Can and Cannot Show You

OpenRouter’s usage charts come with their own instruction manual, and almost nobody reads it. The rankings page states, in one sentence, what the chart counts: “Each model is ranked by the number of tokens it processed through the OpenRouter API, counting both prompt and completion tokens.” Every other property of the chart — what a row is, what gets excluded, what the number is explicitly not — is documented in prose on pages OpenRouter publishes.

That documentation is the entire subject of this reference. Every claim below about what these charts measure is pinned to a page OpenRouter published, fetched on August 26, 2026. Where OpenRouter does not document something, this page says so and names the pages checked — it never infers a methodology from the chart’s appearance, because an inferred methodology stated as fact is the exact failure this reference exists to correct.

The timing is not academic. Today’s identity reveal of the stealth listing Ox Alpha produced, in the wild, five mutually incompatible token totals for the same model — a live demonstration of what happens when a chart-derived number circulates without the methodology attached. Section 05 walks through it.

Start with the page itself. The openrouter.ai/rankings page documents its own mechanics in plain copy. Tokens are the unit, and both directions count: “Each model is ranked by the number of tokens it processed through the OpenRouter API, counting both prompt and completion tokens.” Rows are variants, not models: “Variants of the same model, such as a free variant, are ranked separately.” And the corpus is filtered before it is counted: “Requests that a user or app keeps private are excluded before aggregation.”

The page also states its own scope and its own limits. The rankings reflect “traffic routed through OpenRouter, not the whole market and not usage on a model provider’s own API.” They “measure adoption, not quality” and “do not rank models by accuracy, reasoning ability, or benchmark performance.” Token volume, the page says, is not equivalent to request count, user count, or spending, and models differ in verbosity and tokenization. Aggregation happens in daily buckets in UTC.

The chart offers exactly three fixed windows plus a derivative view, and the window you pick changes the population of traffic you are looking at:

The Trending floor deserves a second look, because it is OpenRouter’s own product design conceding a statistical point: percentage change on a small denominator misleads, so the platform refuses to compute it. That is the same logic this reference applies to every number below — the denominator is part of the figure.

The chart’s machinery is also available as data. The public Datasets API confirms the computation in API terms — token totals are computed as prompt_tokens + completion_tokens, directly matching the public rankings page — and documents a structural limit of the published data: the daily dataset carries the top 50 public models per day, plus a single aggregated other row that sums every model outside that top 50.

A reference like this is only citable if a stranger can redo the work and land on the same statements. The block below names what was read, when, what vocabulary the statuses use, and what this page deliberately did not do.

This table is the asset. Each row is a single limit of the token chart, its mechanical cause, and — the column that matters — the documentation status: whether OpenRouter itself states the limit, or whether it is an absence on the pages checked. Six of the seven limits are documented by OpenRouter in its own copy. Data as of August 26, 2026.

Row 4 is the one readers most consistently miss, and it runs deeper than this chart: the token is a vendor-defined unit everywhere, which is why identical dollar-per-million prices can produce different real costs. Our tokenizer variance reference measures that effect on the pricing side; here it means the leaderboard’s y-axis is not one unit but many.

OpenRouter’s own terminology page draws the distinctions casual chart-reading collapses. A model is a base offering with a canonical slug. A variant is a suffix-modified version of that same slug — :free, :batch — sharing the base identifier but differing in price, availability, or operational mode. A listing is the row that actually appears in the catalog and the ranking systems. The charts rank listings. “One model” in casual usage can be several distinct listings, each accumulating its own token total.

The freshest example is today’s headline model. GLM-5.3-Flash — revealed this morning as the model behind the stealth listing Ox Alpha — reaches the charts through more than one surface, at more than one price. Prices below are surface- and date-specific, which is exactly the point. Data as of August 26, 2026.

Three consequences follow. First, no single row is “GLM-5.3-Flash usage” — each is one surface’s traffic. Second, no roll-up across variants is documented on the pages we checked: summing variants is work the reader must do, from the Datasets API, if the rows are even inside the top 50. Third, because each surface prices differently on a given date, each row’s tokens sit at a different price per token — which is row 5 of the inventory operating in the wild. During its stealth window the same weights traded as their own listing, stealth/ox-alpha, accumulating tokens under that slug; whether a renamed listing carries that history forward is not documented on the pages we checked. Which brings us to the worked example.

This morning, Z.ai revealed that the anonymous OpenRouter listing stealth/ox-alpha was GLM-5.3-Flash — our reveal-day coverage has the full story, and our stealth-listing census tracks the pattern across every such listing. Z.ai’s own reveal post says the model “quickly became the most popular model of the week” — a vendor claim.

Then came the number. Within the day, coverage and social posts circulated cumulative token totals for the stealth period — and they do not agree. We logged five mutually incompatible figures in circulation: 11.6 trillion, 23.2 trillion, 26 trillion, 42 trillion, and 62 trillion tokens. The largest is more than five times the smallest. None of the five traces to Z.ai’s own announcement, which states a pretraining corpus size but no usage figure at all. And none could be re-derived from the source: OpenRouter’s charts render client-side, so there is no archived figure to read back and check a claim against.

We endorse none of those totals — we name them only to show the spread — and neither should you. That is not a failure of this article — it is its finding: a chart-derived number, detached from its methodology, fragmented into five incompatible published figures within hours, and no available method could arbitrate between them. Part of the spread likely has a mundane origin worth naming: Z.ai separately publishes a 30-trillion-token pretraining corpus figure — a training-data quantity with no relationship to inference traffic — and totals in that neighborhood suggest the two are being conflated.

Now the contrast. One usage figure from the whole episode has clean provenance: OpenRouter’s own post on X, dated August 24, 2026 — “Ox Alpha is on track to hit nearly 6 trillion tokens today.” Dated, first-party, attributable. And read it precisely: it is a single-day run rate, published by the party that operates the counter, claiming nothing about any period total. The gap between that one careful sentence and five incompatible cumulative totals is the entire lesson of this reference, compressed into one news day.

The natural follow-up: is OpenRouter’s disclosure normal? We searched for comparable usage- or ranking-methodology documentation across five other platforms on August 26, 2026. The vocabulary from the methodology block applies strictly here — in particular, “page not located in this search” is a statement about our search, not a finding that no page exists. Rows below the fold are honest negative results, kept in.

Read the census the right way around. The finding is not that OpenRouter’s chart is unreliable — the finding is that OpenRouter is the outlier in a good way: the only platform in this set whose ranking mechanics we could read off its own pages in prose a reader can check. That is exactly why its chart is worth taking seriously as a source, and exactly why the limits it documents matter. A platform that tells you what it is not measuring is more trustworthy than one that does not say — but “more trustworthy than undocumented” is not the same as “a complete usage signal.”

OpenRouter’s most detailed methodology disclosure is not on the rankings page at all. The State of AI report — published December 2025 by OpenRouter Inc. and Andreessen Horowitz researchers — is built on anonymized request-level metadata for billions of prompt–completion pairs spanning roughly two years, with its primary focus on November 2024 to November 2025. The researchers state plainly that they “did not have access to the underlying text of prompts or completions” — metadata only.

The report’s most instructive habit is naming its denominators. The task-category breakdowns quoted around the industry rest on Google Cloud Natural Language’s classifier applied to a random sample of approximately 0.25% of all prompts — a quarter of one percent, not the full corpus. Category-level analysis is further restricted to mid-2025 onward, because the classification fields were only added then — a second, narrower denominator layered on the first. The authors call their results observational, exclude enterprise usage, locally hosted deployments, and closed internal systems from scope, and note that geography is inferred from billing location — with some users on third-party billing or shared organizational accounts — an admitted proxy, not ground truth.

That is the standard worth importing: even the platform’s flagship research, with full access to its own data, hedges its geography, names its sampling rate, and dates its category fields. If the party running the counter qualifies its numbers this carefully, a reader quoting a screenshot of the public chart has no business being more confident than the source.

Two boundary lines keep this reference honest about what it owns. First: usage is not benchmark. A token chart measures adoption through one gateway; a benchmark leaderboard measures scored performance on a fixed task set. They answer different questions with different failure modes, and OpenRouter’s own disclaimer draws the line. For leaderboard methodology — contamination, evaluation drift, score reading — see our benchmark methodology guide; this page owns the usage side only.

Second: volume is not price. Our catalog-literacy reference covers what a catalog row hides about price — surface-specific pricing, promo windows, launch-date ambiguity. This page covers what a usage chart hides about volume — token counting, variant fragmentation, window sensitivity, gateway scope. The two failure modes compound, as the GLM-5.3-Flash table in Section 04 shows, but they are distinct, and each reference owns one of them.

A disclosure about our own archive belongs here too. We have quoted these charts as adoption data ourselves — our April rankings analysis and our June OpenRouter roundup cite ranking positions and token volumes. Both restate one of the limits collected here — that these rankings measure adoption rather than benchmark quality — but neither carries the full set. Those posts are not wrong to use the data — it is the best-documented gateway data available — but they should be read with this reference open beside them. That correction applies to us before it applies to anyone else.

To redo or extend this work: the openrouter.ai/data overview describes the data products, the Datasets API serves the daily top-50 series from January 1, 2025 (also reachable via the TypeScript SDK), licensed CC BY 4.0 with attribution required, at 30 requests per minute per key and 500 per day per account. When we build model-routing and adoption analyses for client stacks in our AI transformation engagements, gateway charts enter as one scoped input among several — never as a market-share number.