How we rank AI Python packages

The ranking measures usage and staying power from public data. It doesn't measure quality, and nobody pays to be in it or to move up. It uses the same score as our n8n community node ranking.

What it ranks

AI packages on PyPI. We start from the public list of the 15,000 most-downloaded PyPI projects (hugovk/top-pypi-packages), keep projects whose name is about AI (openai, anthropic, llm, agent, mcp, langchain, vector databases and similar), drop per-library tracing shims and false matches, and take the 150 with the most downloads.

We then keep packages with at least 10,000 typical downloads per 28 days, drop names with test, trial, demo or example and archived repos, and score the ones at least 6 months old. Younger packages go in the "new and rising" list without a score.

One row per project

Many projects publish several packages from one GitHub repo (for example a core package plus one per provider). These are folded into one row, shown under the repo's most-downloaded package, and the others are listed in the row's detail. Without this, a few big projects would fill most of the top 20.

Packages left out by hand

Some packages are mostly installed because another package depends on them: detection helpers bundled in CLIs, core packages under a framework, internal interfaces. Their downloads say little about direct use, so we keep a short hand-checked list of them and leave them out. The list and the reason for each is at the bottom of the ranking. Their GitHub issues still count when we split a repo's issues across its packages.

Sources

pypistats.org: daily downloads without mirrors. It keeps about 180 days, so our series is shorter than for npm.
PyPI JSON API: first upload date, latest release date, project links.
GitHub API: stars, last code push, archived status, and issues opened in the last 12 months (pull requests excluded).

How the score is built

Usage (40 points). Typical downloads per 28 days = median daily downloads × 28. Scored on a log scale from 10,000 up to the top package, so 10× more downloads adds a fixed step instead of crushing everyone else.
Staying power (30 points). The current level as a share of the level 3 months ago and 6 months ago, each capped at 100%, averaged. A package that held gets full points; one that dropped by half gets half. Growth earns nothing extra, so a sudden surge can't buy a top spot.
Problems (15 points). GitHub issues opened in the last 12 months per 100,000 downloads over the year (with spikes capped). When several packages share a repo, its issues are split by their share of the downloads. Fewer issues per download scores higher. Low, Medium and High are thirds of the list. Packages with no GitHub repo found get a neutral middle score and the label "No repo found". Issues are a rough signal: busy projects get more feature requests, not just bugs.
Upkeep (15 points). Days since the newer of the latest release and the latest GitHub code push: up to 90 days full points, up to 180 = 70%, up to a year = 40%, older = 10%.

Score = the weighted sum, out of 100. Ties go to the package with more downloads.

Retention and churn columns

The 6-month window is partial. pypistats.org only serves about 180 days, so there is no full 28-day block from 6 months ago. We use the oldest days that exist instead: 23 to 23 days, ending 182 days before the data end date, and take the median day × 28 as before. A median over fewer days moves more with one odd week, so treat the 6-month retention and churn numbers for Python as rougher than the 3-month ones. The daily chart shows the 205 days we have. We now store a copy every week, so this window fills up over the next months.

Kept after 3 / 6 months is retention: the current download level (median day in the last 28 days) as a share of the level 3 and 6 months ago, capped at 100%. Lost after 3 / 6 months is churn: 100% minus retention. A package with 70% kept after 6 months shows 30% lost.

This is download churn, a drop in the download level. It isn't user churn: PyPI doesn't say who downloads a package, and one install can count many times.
Because retention is capped at 100%, a package that grew shows 0% lost, however much it grew. The change vs 6 months ago is in each row's detail.
The Sticky, Holding and Fading label uses the lower of the two kept numbers: Sticky at 90% or more, Holding at 60 to 90%, Fading under 60%.

Month-over-month churn chart

Each expanded row has a second chart under the daily downloads. We cut the series into back-to-back 28-day blocks ending on the data end date and take the median daily downloads in each block as its level. Churn for a block is 1 − level ÷ previous level, shown as 0% when the level grew. Blocks before the package was first published, or where the previous level was under 3 downloads a day, are grey "not enough data" gaps. It's computed in your browser from the same daily series as the first chart.

Cleaning

Median days instead of totals, so one-day bursts from CI servers or mirrors don't move the ranking. For the yearly problem rate, any day above 3× its trailing 28-day median is capped. Packages whose downloads rose over 6× in 6 months while having under 50 GitHub stars and no vendor backing get a "Sudden jump" badge and lose a quarter of their score.

Limits

Downloads aren't users. Automated installs, CI runs, Docker rebuilds and packages installed as dependencies all count, and the hand-kept list only removes the clearest cases.
Keyword search misses AI packages that don't describe themselves with AI words.
Popular doesn't mean best for you, or safe to run.

Refresh

Monthly, at the start of the month. Raw numbers are in data.json.

Spotted an error? Write to mission@usestarbase.com.