Most projects show you raw download counts and hope you don't ask questions. We ask them for you: downloads are bot-filtered, savings come from an opt-in census that starts at zero and can't be inflated, and every number below is computed by public code from a public git branch.
connecting to the metrics branch…
Community tokens saved · exact
0
—
Summed from — that opted in and have actually reported
savings, calibration-corrected, never estimated. It's an
exact cumulative (exact meaning never projected forward — the
underlying token counts are calibrated against each install's billed usage
and carry that calibration's error bar), summed fresh on every read — the digits move only when a real
heartbeat or census (content-free, every ~5 min) reports genuinely more saved, and
sit static while everyone idles. No per-day projection, no invented growth. Worth
— at metered API rates.
—
Decision-equivalence
Decision-equivalence from paired shadow replays on live traffic:
each sampled request is run three times — twice on the original context, once
compressed — so both arms are the same request. The number is how often compression
changed the agent's next action, relative to how often the model changes it by
itself. Across — shadowed requests.
—
active installs · 30d
—
agent runs
—
avg saved / run
–
Active installs · 30d
– reporting savings · opt-in census · one per machine
–
Real $ saved · metered
plus – notional API-rate value from flat-rate subscriptions
–
PyPI installs / month
bot-filtered download events (incl. CI & upgrades) — not unique users; the census tile is the provable-users number. Filtering is a heuristic (no OS reported = bot), so this is a lower bound on real clients
–
API shapes seen
distinct SDK wire formats across the fleet — Anthropic / OpenAI / Gemini
Downloads · honestly
The number everyone shows vs. the one that's true
A public PyPI package receives constant traffic from supply-chain scanners (Snyk/Socket-class), package-intel crawlers (deps.dev, libraries.io), and malware sandboxes — every new release triggers fleet-wide sweeps. They report no operating system; pip on a real machine does. Even the filtered number counts events (CI reinstalls, upgrades), not people — provable people are the census tile. So we split:
real clients (OS reported) · –/mobots & scanners (no OS) · –/mo
By operating system · real clients, 30d
By Python version · real clients, 30d
Usage · from the opt-in census
Who actually runs it — and what it saves them
Machines that consented (distil census on). Anonymous install ids, schema frozen by test, fully disclosed — preview your own payload anytime with distil census show.
Versions in the wild · active 30d
Tokens saved by model
Integration surface · requests
API shape · SDK wire formats
Session mode · how it's driven
Billing mix · wrapped agents · channels
How it's measured
Two paths, three validation layers, one public datastore
Passive registry stats involve zero code on anyone's machine. The census is validated at the worker, re-validated in CI, and capped again at rollup — then stored in a git branch anyone can read.
Freshness · census re-rolls within ~1 min of any ping · registry stats nightly (PyPI publishes daily) · badges re-poll every 5 min · this page fetches on load
Why these numbers survive scrutiny. They started at zero (no estimates, no seeding). They can't be inflated: schema allowlists and hard numeric ceilings are enforced at the worker, again in CI, and again at rollup; one census per machine, latest wins. Subscription users' dollar savings are shown as notional, never mixed into real $. And if you don't like any of it: DO_NOT_TRACK=1 wins over everything — see TELEMETRY.md.
Distil