How we count downloads

• PyPI — the official download logs published by the Python Software Foundation as bigquery-public-data.pypi.file_downloads. This is the same source behind PyPI’s own statistics.
• npm — the npm registry download API, reconciled against the registry’s own per-package counts.

We aggregate to daily, weekly, and monthly grains. A month is only final once it is complete, so the current month is always shown as partial and is never used for month-over-month comparisons.

We count requests for real distribution artifacts: .whl, .tar.gz, and .zip. We do not count:

• Metadata sidecars — .metadata files that installers fetch under PEP 658 to resolve dependencies without downloading the package itself. A sidecar fetch is a resolver step, not a download.
• Signatures and legacy formats — .asc, .egg, and installer formats such as .exe, .msi, and .rpm.

We do not strip mirror or CI traffic. It is real installation demand, and removing it would make our numbers incomparable with every other public source. We expose it instead: the installer, CI, operating system, architecture, and country breakdowns show how much of a package’s volume is automation, and where it comes from.

The architecture split counts the CPU name the client reports. x86_64 is x86_64 as Linux and macOS report it; ARM is arm64 and aarch64. Windows clients report AMD64 and ARM64 and are counted in neither, so about 5% of PyPI downloads fall outside both columns: Windows (about 2.6%), clients that report no CPU, and rarer chips such as ppc64le and riscv64 (measured over one day, September 2026). Read the split as Linux and macOS hardware. The API returns the rest as other_arch_downloads, so x86_64, ARM and other add up to the total (6.2% of PyPI downloads were other in August 2026).

On August 24, 2026, PyPI stopped logging any request that isn’t a real distribution file. That changed what PyPI records, not what anyone actually does — but because metadata sidecars had grown to roughly 40% of all logged rows, it makes every PyPI package look like it lost about a third of its downloads overnight. PyPI’s announcement has the details.

PyPI did not rewrite its historical logs, so this would otherwise have left a permanent artificial cliff in the middle of every chart. Rather than annotate around it, we recounted: every month from July 2023 — when sidecars first appear in meaningful volume — through the present has been rebuilt counting distribution files only.

The result is one continuous series. Three things are worth knowing:

• Absolute PyPI counts before September 2026 are lower than they used to be — by about 3% in mid-2023, rising to roughly 35–40% by 2026, tracking sidecar adoption. Nothing was lost; those rows were never installations.
• Rankings, shares, and trends barely move — sidecar traffic scaled with package popularity, so removing it shifts almost every package by a similar proportion.
• Data before July 2023 is untouched — sidecars were under 0.03% of rows then, so it was already on the new basis.

If you compare our PyPI figures against a source that has not recounted, expect it to match us before July 2023 and to read higher from then through August 2026, by a margin that tracks sidecar adoption. That gap is its overcount, not our undercount: those rows were metadata fetches, not installations. From September 2026 the two agree again, because PyPI itself stopped logging sidecars — which is also why an un-recounted series shows a ~35% drop at that date that never happened in reality. npm is unaffected by any of this.

• Downloads are requests, not installs. A cached install produces no download; a failing one may produce several.
• Country is derived from the request’s network location, so VPNs, cloud regions, and mirrors distort it. A package used mostly in one country can surface as traffic from wherever its CI runs.
• Installer and CI attribution depends on self-reported client metadata. Coverage is good from 2024 onward and sparse before it, so CI share in particular should not be trended across that boundary.
• npm history is reconciled against the registry API, which caps very old per-day queries. Where the registry cannot serve a day, we carry the mirrored value.

If a number looks wrong, tell us — corrections are reviewed by hand. Reach us at support@ensemblai.com.