Methodology

Metric definitions

All token counts come from the instance’s own usage accounting (per-session, per-model counters), summed over a trailing window of 7 or 30 days, UTC.

metric	definition
`gross_tokens`	`input + output + cache_read + cache_write`
`fresh_tokens`	`input + output`
`cache_tokens`	`cache_read + cache_write`
`cache_efficiency_pct`	`cache_tokens / gross_tokens × 100`
`gross_per_day`	`gross_tokens / window_days` (actual period days)
`fresh_per_day`	`fresh_tokens / window_days`
`reasoning_tokens`	reported separately when the provider exposes it; never added into gross or fresh a second time
`api_calls`	count of model API requests in the window
`sessions`, `messages`, `tool_calls`	simple counts in the window

Two standing honesty rules:

Cache tokens are not billable-equivalent tokens. Cache reads are re-served context and are priced and computed differently from fresh tokens. That is why fresh volume is always displayed next to gross, and why “biggest gross number” is explicitly a throughput brag, not a spend brag. This site publishes no cost estimates at all — subscription plans and provider accounting are not comparable across instances.
No percentiles. Nobody has a defensible census of Hermes instances. Without a denominator, “top X%” is fiction. The site publishes ratios against cited public numbers instead.

Verification tiers

tier	meaning	ranked?
first-party attested	produced by the strict exporter in this repo, on a host controlled by this project; validated against the public allowlist	yes
community self-report	a number a person posted publicly; quoted, linked, normalized to 30d, flagged if extrapolated	never
ecosystem aggregate	app-wide total across all instances (e.g. OpenRouter’s Hermes Agent page)	never

“Attested” is deliberately modest: the exporter proves the pipeline is strict, not that the host owner is honest. A malicious owner could inflate their own counters. The anti-gaming posture for v1 is transparency — submissions arrive by merge request, the exporter is public, the validator is public, daily series make fabricated curves easier to spot, and absurd magnitudes are rejected outright by schema bounds.

Badges

Badges are deterministic threshold checks computed at build time by scripts/build_leaderboard.py — there is no editorial discretion.

badge	threshold
TOKEN FURNACE	`gross_per_day` of at least 500,000,000
CACHE ALCHEMIST	`cache_efficiency_pct` of at least 90 and `gross_tokens` of at least 1,000,000,000
CONTEXT WELDER	`gross_tokens` of at least 10,000,000,000 in one window
WIRE RUNNER	at least 2,000 `api_calls` per window day on average

Windowing and attribution

Known limitations, stated so nobody has to discover them:

Day attribution. The usage store keeps one accounting row per (session, model) pair with a last_seen timestamp. The daily series attributes a row’s whole volume to the UTC day the row was last updated, so a long-running session’s tokens lump onto its final day. Window totals are unaffected; the daily chart is a good shape, not a perfect ledger.
Window edges. The window is [now − N×86400s, now) at export time, so the first and last calendar days shown are usually partial.
Trailing snapshot, not live. The site is static; numbers update when a new exporter run is committed. The freshness chip shows the window-end date of the data actually displayed.
Model/provider mix is private. The allowlist deliberately excludes the model roster, so throughput cannot be normalized per model. Gross tokens are gross tokens, whatever produced them.

Reproduce it

Every artifact is rebuildable from the repository:

python3 -m unittest discover -s tests        # hermetic pipeline tests
python3 scripts/validate_snapshots.py data/submissions/*.json
python3 scripts/build_leaderboard.py         # deterministic, byte-stable
hugo --minify                                # static site

The machine-readable board is public at /data/leaderboard.json.