compression with a quality contract
Live telemetry · auditable end-to-end

Adoption & Community Savings

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
 
The community total from opted-in ledgers, calibration-corrected, never estimated. It's an exact cumulative, 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
Compression provably didn't change the agent's next action, across shadowed requests. This is the distil guarantee — as a community number, noise-adjusted.
active installs · 30d
agent runs
avg saved / run
Active installs · 30d
opt-in census · one per machine · bot-proof by construction
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
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) · /mo bots & 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.

Distil versions in the wild
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.

OPT-IN CENSUS · RE-ROLLS WITHIN ~1 MIN OF A PING Your machine census on · ≤1 JSON/day Ingest worker validate · 2 KB cap · no IPs CI re-validation defense in depth · allowlists metrics branch public git = the database PASSIVE · ZERO CLIENT CODE · NIGHTLY Registries PyPI · GitHub · Docker Nightly snapshot bot split · OS · Python Rollup dedupe · skew caps · Σ README badges this page

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.