Vigía

Returns the current state of one package: latest stable version and its publish date, status (active / deprecated / yanked / not_found_in_registry), the deprecation message if any, runtime requirements (npm engines and peerDependencies, PyPI Requires-Python, Rust rust-version, PHP require.php), license, known security advisories on the latest version, a release-activity summary (active / slowing / dormant) and the sources with their last verification time. Read-only and requires no authentication. A package Vigia does not track yet is fetched live from its registry on the first call (a few seconds); if the name does not exist the result has status not_found_in_registry plus similar-name suggestions. Use it to decide whether to add or recommend a package, or to learn its newest version. For a specific version you already have use version_status; for what breaks when moving between two versions use upgrade_impact; to find a release that fits an older runtime use find_compatible_version; to find a package whose exact name you do not know use find_package.

Lists the published versions of one package, newest first, each with its publish date, a prerelease flag and whether it is withdrawn (npm: deprecated; PyPI and crates.io: yanked; Packagist: abandoned), plus a maintenance summary: last release date, releases in the last 12 months and an activity label (active / slowing / dormant). Read-only and requires no authentication. A package Vigia does not track yet is fetched live on the first call. Use it to judge release cadence, to see which version was current at a given date, or to check whether a version was ever withdrawn. For only the latest version use package_status; for the vulnerabilities of one version use version_status.

Reports what changes between two versions of an npm package by diffing the public TypeScript API of both releases (only the type declarations are analyzed; package code is never executed): removed exports and import paths, changed function signatures and class or interface members, newly deprecated APIs, changed engines and peerDependencies, and the changelog sections published in between. Returns a summary with counts and a likely_breaking flag, followed by the before/after detail of each change. Read-only and requires no authentication. The first request for a version pair can take up to about 25 seconds while the analysis runs; if it is still running the result has status "pending" and retry_after_s, and you should call again after that delay. Limits: only npm packages that ship TypeScript types (or have @types) can be analyzed, and behavior changes that do not alter types (for example new caching defaults) are invisible, so also read the returned changelog. Use it BEFORE upgrading a dependency across a major version, or when code written for an old version fails on a new one. For one API in one version use symbol_status; for vulnerabilities use version_status; to choose a version that fits an older runtime use find_compatible_version.

Checks whether an exported function, class, type or constant (or a Class.member) exists in a specific version of an npm package, using the package's TypeScript declarations. Returns whether it was found, its kind, its exact signature, the module path to import it from, whether it is deprecated (with the deprecation message) and, when it is not found, close-name suggestions. Read-only and requires no authentication. The first lookup for a package version can take up to about 25 seconds while its types are analyzed; a result with status "pending" and retry_after_s means call again after that delay. Limits: npm packages with TypeScript types only; exports that exist at runtime but have no type declaration are not visible. Use it before writing code that calls a library API you are not sure exists, or has the same signature, in the installed version, especially after a major upgrade. For a complete list of what changed between two versions use upgrade_impact.

Finds the newest stable, non-withdrawn version of a package whose own declared requirements admit the runtimes you give it: npm engines and peerDependencies, PyPI Requires-Python, Rust rust-version (minimum Rust), PHP require.php and required packages. Returns the best version with the per-constraint checks, the newest release that is incompatible together with the reason it fails, and a list of unverified constraints (a version that declares nothing for a constraint is not counted against it but is flagged). Read-only and requires no authentication. If per-version requirement data for a package is still being loaded, the result has status "requirements_not_synced_yet" and retry_after_s. Use it when a project is pinned to an older Node, React, Python, Rust or PHP and the latest release may not support it. For the plain latest version use package_status; to check whether the runtime itself is still supported use eol_status.

Reports on one exact version of an npm, PyPI, crates.io or Packagist package: whether that version exists, when it was published, whether it is withdrawn (npm deprecated, PyPI and crates.io yanked, Packagist abandoned), how many stable releases and major versions it is behind the latest, and its known vulnerabilities from OSV with severity, summary, the version that fixes each one, and the single nearest version that fixes all of them (null if any has no fix). Read-only and requires no authentication. Vulnerability data is cached for up to 6 hours, and the response states when OSV could not be reached. Use it before keeping, pinning or recommending a specific version, or when auditing one lockfile entry. For the latest version and general package health use package_status; to audit a whole manifest at once use check_dependencies.

Audits a whole manifest in one call. For every dependency in a package.json (dependencies and devDependencies) or a requirements.txt it returns the latest version, whether the declared range includes it (up_to_date / outdated / outdated_major / unpinned / unsupported_spec), how many major versions behind it is, whether the package is deprecated, and the OSV vulnerability IDs of the lowest version the range allows; a summary with counts comes first. Read-only and requires no authentication. Nothing is stored. Up to 300 dependencies are handled per call; packages Vigia does not track yet are resolved live (up to 40 per call), and the rest come back as not_resolved_yet with retry_after_s. Only npm and PyPI manifests are supported. Use it when opening a project or before upgrading its dependencies. For a single package use package_status; for one exact version use version_status.

Lists the changes Vigia detected recently, newest first: new package releases (with old and new version), deprecations, yanks and removals, runtime-requirement changes, AI model price changes and model retirement announcements. Each item has the entity, the kind of change, the old and new values and the detection time. Without a name it returns the global feed; with ecosystem and name it returns the change history of that one package or model. Read-only and requires no authentication. History only goes back to when Vigia started tracking the entity, so it is not a package's full release history (use list_versions for that). Use it to find out what happened after your training data ends, or whether a dependency or model has just changed.

Looks up AI models in the OpenRouter catalog: price per million input and output tokens in USD, context window, maximum output tokens, knowledge cutoff, supported modalities and announced retirement date, with a status of available / retiring / removed_from_catalog. With model_id it returns that one model (if the id is unknown, a list of similar ids); with provider and/or query it returns up to 40 matching models. Read-only and requires no authentication. Prices are OpenRouter reference prices and may differ from a provider's direct pricing; the catalog is refreshed every 15 minutes. Use it before writing a model ID in code, choosing between models, estimating costs, or checking whether a model is being retired. It does not call, run or benchmark models.

Tells whether a language, runtime, framework, database or operating-system version is still supported and when it reaches end of life. Covers about 480 products (Python, Node.js, PHP, Java, Ruby, Go, Rust, Django, Laravel, Rails, React, Angular, PostgreSQL, MySQL, Ubuntu, Debian, Kubernetes and more). With product and version it returns that version's status (supported / security_only / end_of_life / upcoming), its release, active-support and end-of-life dates, days remaining or elapsed, and the cycles that are still supported; with only product it returns every release cycle; with neither it lists the product identifiers. Read-only and requires no authentication. Status is computed on every call from today's date; the dates come from endoflife.date and are refreshed every 12 hours. Use it before choosing a runtime or base image, when writing a Dockerfile or CI matrix, or when auditing an old version. It concerns the language, runtime or platform itself; for a library's own versions use package_status.

Returns what happened in software after a given date, so an agent can patch the gap between its training data and today: packages among the most popular on npm, PyPI, crates.io and Packagist that shipped a NEW MAJOR VERSION after the date (with the version that existed at that date, the new majors and their first release dates, the latest version, and an upgrade-guide link when one exists), runtimes, frameworks and platforms released or ended since (Python, Node.js, PHP, Java, Django, Laravel, Ubuntu, PostgreSQL and about 35 more), runtimes ending within 180 days, and AI models released since by the main providers with their prices. Read-only and requires no authentication. Results are computed from registry publication dates and cached for an hour. Coverage is the most popular packages (not every package), 0.x-to-0.y changes and calendar-versioned packages are not reported as major versions, and deprecations that happened before Vigia started tracking are not listed. Use it once at the start of a coding session, passing the month your training data ends, or when you suspect a library you know has changed a lot. To dig into one package use upgrade_impact (npm) or package_status; for one runtime use eol_status.

Searches the catalog of tracked packages and AI models by case-insensitive name prefix and returns up to 15 matches ordered by popularity, each with its ecosystem, name and popularity rank. Read-only and requires no authentication. It matches only the beginning of the name (not descriptions or keywords) and covers tracked packages only, about 34,000 across npm, PyPI, crates.io and Packagist. Use it when you do not know the exact package or model name before calling package_status, list_versions or model_status; it is not a way to discover packages by what they do.