Methodology
What we measure, how the Pulse Score is put together, and what the numbers can and cannot tell you.
What gets tracked
AgentGid follows software that uses a language model to carry out multi-step work with tools, and the libraries used to build such software. A product is listed when it is a significant option in its category and leaves at least one public trace we can measure: a package on npm or PyPI, an editor extension, a public repository, a Homebrew formula, its own website, or a status page.
Every number on the site comes from a public source. Nothing is estimated, modelled or supplied by vendors. When a signal does not exist for a product, the cell shows a dash.
The signals
| Signal | What it measures | Where it comes from |
|---|---|---|
| Downloads | Daily package downloads, npm and PyPI combined | npm downloads API; PyPI download logs via ClickPy |
| VS Code installs | Unique installs of the product's extension | Visual Studio Marketplace |
| Marketplace rating | Average user rating and number of ratings | Visual Studio Marketplace, Open VSX, WordPress.org, App Store |
| GitHub stars, forks, open issues | Community size and backlog | GitHub |
| Releases | Version, date and notes of each stable release | GitHub releases |
| Homebrew installs | Installs over 30, 90 and 365 days | Homebrew analytics |
| Docker pulls | Cumulative image pulls | Docker Hub |
| Hacker News mentions | Posts and comments that name the product | Hacker News public dataset |
| Wikipedia views | Daily views of the product's English article | Wikimedia Pageviews API |
| Site rank | Position of the product's own domain in a research ranking of popular sites | Tranco list |
| Pull requests | Public pull requests opened by a coding agent, and how many were merged | GitHub search |
| Incidents | Incidents the vendor reported on its status page | Vendor status pages |
The data sources page describes each one in detail.
Growth figures
For daily flows such as downloads, the 7-day change compares the last seven complete days with the seven before them; the 30-day change does the same with 30-day windows. A change is shown only when both windows are fully covered by data, so a product that launched three weeks ago has a 7-day change and no 30-day change.
For counters such as stars and installs, we store one reading a day and report the difference between readings. These series start on the day a product was added, so their history is shorter than the download history, which the registries provide going back up to 18 months.
The newest one or two days of download data are often incomplete at the registries, so windows end on the last complete day, which is shown on each agent's page.
Step changes
Sometimes a package's daily downloads move to a different level overnight and stay there: ten times higher, or a tenth of what they were. Real adoption does not behave like that. Such a step comes from automated traffic switching on or off (a CI fleet, a mirror, a new dependent package) or from the registry changing what it counts; in late August 2026, for example, several unrelated PyPI packages we track lost most of their counted downloads within the same few days.
We detect a step when the typical daily level of one week differs from the week before by a factor of 3.5 or more and the new level holds. When a step falls inside the two windows a growth figure compares, that figure is withheld and the agent's page says so. The totals are still shown, since they are what the registry reports.
The Pulse Score
The Pulse Score is a number from 0 to 100 that gives the tables a default order. It combines four components:
| Component | Weight | Built from |
|---|---|---|
| Adoption | 45% | The strongest of the usage signals a product has: downloads, VS Code installs, Open VSX downloads, JetBrains downloads, Homebrew installs, Docker pulls, WordPress installs, App Store ratings, site rank |
| Community | 20% | GitHub stars |
| Attention | 20% | Average of Hacker News mentions and Wikipedia views over 30 days |
| Momentum | 15% | 30-day growth of downloads, or of stars or Wikipedia views when there are no downloads |
Each signal is converted to a 0 to 100 value on a logarithmic scale between two fixed reference points:
| Signal | Scores 0 at | Scores 100 at |
|---|---|---|
| Downloads, 7 days | 1,000 | 30,000,000 |
| VS Code installs | 10,000 | 100,000,000 |
| Open VSX downloads | 50,000 | 200,000,000 |
| JetBrains downloads | 10,000 | 100,000,000 |
| Homebrew installs, 30 days | 100 | 100,000 |
| Docker pulls | 100,000 | 500,000,000 |
| WordPress active installs | 1,000 | 1,000,000 |
| App Store ratings | 1,000 | 5,000,000 |
| Site rank (lower is better) | 1,000,000 | 1,000 |
| GitHub stars | 1,000 | 250,000 |
| Wikipedia views, 30 days | 500 | 100,000 |
| Hacker News mentions, 30 days | 5 | 3,000 |
Momentum maps 30-day growth onto the same range: a fall of 50% or more scores 0, no change scores 50, and growth of 100% or more scores 100.
Three design choices are worth knowing:
- Fixed scales. A product's score depends only on its own numbers, so adding or removing other products never moves it.
- Adoption takes the best channel. Products are distributed in different ways. A VS Code extension has no npm downloads and a command-line tool has no extension installs, so adoption uses whichever usage signal is strongest instead of averaging in the missing ones.
- Missing components are left out, and thin evidence counts for less. If there is no data for a component, the score is the weighted average of the components that exist, multiplied by a coverage factor: 1.0 when all four are present, falling in a straight line to 0.55 as the weight of the missing components grows. A product known only by its GitHub stars keeps 64% of that component's score. Without this, one strong signal would outrank a product with broad evidence. Each agent's page shows which components exist.
The score is a convenience for sorting. It is our own construction, and it is not a measure of how good an agent's output is.
What the numbers do not tell you
- Downloads are not users. Registries count every download, including CI runs, mirrors, containers and automatic updates. A tool that releases daily is downloaded more often per user than one that releases monthly. Downloads are best read as activity and as a trend.
- Distribution changes move the line. When a vendor shifts users from an npm package to a native installer, downloads fall without usage falling. Where we know about such a change it is noted on the agent's page.
- Stars are cheap. They show interest at some point in time and can be inflated. We use them for community size, with a modest weight.
- Mentions depend on the name. Counting Hacker News mentions works for distinctive names and is unreliable for names that are ordinary words, so those products have no mention count.
- Site rank covers a whole domain. It is only shown for products that have a domain of their own.
- Incidents are self-reported. Vendors differ in how readily they post incidents, so a clean status page is weak evidence of better uptime.
- Merge rate depends on usage. An agent that opens pull requests only on request will see more of them merged than one that opens them unprompted.
Product facts and pricing
Descriptions, licences, supported platforms and prices are checked by hand against the vendor's own pages. Each pricing block shows the page it came from and the date it was last checked. Prices in this market change often, so confirm on the vendor's site before buying.
Corrections
If a number or a fact looks wrong, let us know with a link to the source and we will fix it.