How we rank AI npm 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 npm: SDKs for model providers, agent frameworks, MCP servers and clients, and tooling built around them. We search the npm registry by AI keywords (ai, llm, agent, mcp, openai, anthropic, langchain, gemini, rag, embeddings and similar), keep packages whose name or description is about AI, and take the 186 with the most monthly 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

npm downloads API (api.npmjs.org): daily downloads for the last 365 days and more.
npm registry: first publish date, latest release date, repository link.
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 3-month level is the median day in the 28 days that ended 90 days ago, and the 6-month level the 28 days that ended 182 days ago.

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: npm 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

Missing days. On 13 dates (Jul 12, 2026, Aug 14, 2026, Sep 3, 2026, Sep 7, 2026, Sep 8, 2026, Sep 15, 2026, Oct 6, 2026, Oct 13, 2026, Oct 14, 2026, Oct 15, 2026, Oct 19, 2026, Oct 20, 2026, Oct 21, 2026) the npm downloads API returned 0 for at least half of all tracked packages at once, between normal days on either side. Those are reporting gaps, not real zero days, so we treat them as missing: they are left blank in the daily chart and tooltip and skipped by every median, the churn chart and the problem rate. 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.