Anteproof gives each repository two dated probabilities: will it keep up its recent commit pace, and will it publish a release. Each one is sealed with a public receipt before the outcome is known.
For engineering teams reviewing the dependencies they ship, and asking which ones may fall behind their recent commit pace or go without a release.
An npm, PyPI or crates.io name, or a GitHub owner/repo. No account needed.
Maintenance forecasts are new. Their past scores are withheld while the outcomes are re-measured against GitHub's own data. Coverage is a bounded set of repositories, so a package can come back without a forecast. A probability is not advice.
Or try the API yourself, no account needed.
A live forecast from the public log. The log's head hash is anchored daily to github.com/anteproof/log.
Counted on the GitHub REST API series. Repositories with GH Archive history only are not counted, because that capture is unreliable. The count dropped slightly when it moved to this series; that was a change of method, not a decline in the repositories' activity.
A dependency can fail you without a vulnerability ever being filed. A package quietly stops getting commits; the last release was fine, the scanner is green, and a year later a patch is needed and there is no one to ship it. By the time the repository is archived, the migration is an emergency.
Anteproof asks the question earlier. For the repositories it samples — not for everything it tracks — it asks: will the default branch receive at least K commits in the next 90 days, and will there be at least one release? K is that repository's own commit total over the trailing 90 days at question time, so the first question reads "at least as many commits as last quarter"; both resolve from the GitHub REST API, never from a judgement call. Each answer is a probability, tied to a resolution rule and a date, with the activity data it was read from. The coverage counts above say how many that is.
Failing the commit threshold is not the same as a project being abandoned. A mature library can have a quiet quarter and be perfectly well maintained, and a repository can clear the threshold and still be in trouble. The question is the question, and we do not publish a blended maintenance score behind it.
A dependency review with a dated probability on it, months before the migration would have become an emergency.
Load every dependency at once. Upload a CycloneDX or SPDX JSON document (Syft, Trivy, cdxgen, GitHub's dependency-graph export; up to 5 MB) on your account page. npm, PyPI, crates.io and GitHub components are matched to tracked entities and added to your watchlist; packages not tracked yet are queued so the archive picks them up. A dry run previews the match and changes nothing.
Import SBOM on /accountFollow the dependencies you actually ship. Anything you check, or that an SBOM import matched, can sit on a watchlist on your account page, so the next forecast on it is one page rather than one lookup at a time. Watchlist sizes are per plan and are listed on pricing.
Open your watchlistOne call, one answer, from the same archive this page reads. A call without a key works for trying it out, unmetered and without any service commitment; a free key on /account covers 1,000 calls a month.
curl "https://api.anteproof.com/v1/risk?q=express"
Also q=psf/requests, q=pypi:requests, q=crate:serde, or a GitHub URL. The developer docs have the full response shape.
claude mcp add --transport http anteproof https://api.anteproof.com/mcp \ --header "Authorization: Bearer ap_YOUR_KEY"
The dependency_risk tool returns the same answer as /v1/risk. Cursor, Claude.ai and the desktop app connect to the same URL; the developer docs have the setup for each.
The maintenance questions are scored on their own. The count above and this note are read from the record when the page loads: the commits_90d and release_90d families' own resolved rows, with the same numbers the calibration page shows. Until a family has resolved rows of its own, treat its probabilities as unscored.
The full forecast log — every forecast in the order it was issued, all families, with this week's scored outcomes and the launch-gate history — is on the track record page.
Every resolved forecast gets a Brier score (0.25 is always saying 50%; lower is better). Per family and per horizon, we publish n, Brier skill over that baseline, and the reliability diagram, on two tracks: live forecasts and point-in-time pastcasts. Fewer than 30 resolved rows and the number is shown but says little. See the calibration page.
We never describe a package as safe, and we do not claim to beat any market. We publish derived scores and forecasts only, no source data. Entities are added on request only where the maintaining organisation is in the United States, the European Union, the United Kingdom or an allied jurisdiction. Resolution rules, quotas and errors are in the developer docs.