# vlt benchmarks > Install and run performance for JavaScript package managers, registries and task runners, measured nightly on identical GitHub-hosted runners and published in full. Every page is available as Markdown: append `.md` to its URL, or request the page with an `Accept: text/markdown` header. The links below point at the Markdown versions. Query parameters apply to the Markdown as they do to the page: https://benchmarks.vlt.io/package-managers/clean.md?fixture=babylon is that scenario on one fixture. [llms-full.txt](https://benchmarks.vlt.io/llms-full.txt) holds every scenario of the latest run, at the default view, in one file. [Methodology](https://benchmarks.vlt.io/methodology.md) holds the method, the runner environment and what each scenario measures. [About](https://benchmarks.vlt.io/about.md) is this index as a page; `/` itself opens on the registries average, and each benchmark's own URL on its average: the derived mean of its scenarios. ## Reading the results - Total time is the measurement and the ranking: the mean wall-clock install (or, for task runners, execution) time, over the fixtures a tool completed. Lower is faster. - DNF: the run exited non-zero. It is excluded from every mean, chart and ranking, never counted as a time, and reported as DNF. - Partial: a tool that did not complete every fixture. Its mean covers fewer fixtures (shown as n/N), so it is not ranked against tools that did, and it gets no bar. - ±RSD: the pooled relative standard deviation across a tool's repeated runs. - Derived metrics are computed from total time and labelled "derived": time per installed package, change since the start of the window, and time relative to the baseline. - The baseline is npm: the npm client for package managers, registry.npmjs.org for registries, `npm run` for task runners. It is a reference point, not the tool to beat. - Results regenerate nightly. A run is named and cited by its date; `?date=YYYY-MM-DD` pins one. - Page parameters: `date`, `fixture`, `range` (30, 60, 90 or 120 days of trend), `from` and `to` (an exact trend window), `hide` (comma-separated tools), `metric` (total, change, baseline or per-package), `exclude` (`YYYY-MM-DD` or `tool@YYYY-MM-DD`, comma-separated). ## API and MCP - JSON API, described at [openapi.json](https://benchmarks.vlt.io/openapi.json): `/api/v1/runs`, `/api/v1/catalog`, `/api/v1/{section}/{scenario}` (the full report, same parameters as the page) and `/api/v1/{section}/{scenario}/history` (the trend, failures and coverage). - MCP server (streamable HTTP, read-only, no auth): https://benchmarks.vlt.io/mcp. Tools: `list_benchmarks`, `get_results`, `get_history`, `compare_scenarios`. Add it to Claude Code with `claude mcp add --transport http vlt-benchmarks https://benchmarks.vlt.io/mcp`. ## Benchmarks ### Registries The same projects installed with the same npm client from each registry, so the registry is the only thing that changes. - [average](https://benchmarks.vlt.io/registries/average.md): Every tool across all of this benchmark's scenarios at once. - [registry-clean](https://benchmarks.vlt.io/registries/registry-clean.md): A cold install, holding the package manager constant and varying the registry. - [registry-lockfile](https://benchmarks.vlt.io/registries/registry-lockfile.md): A lockfile install, holding the package manager constant and varying the registry. ### Package managers The same projects installed by each package manager, from every combination of warm and cold cache, lockfile and node_modules. - [average](https://benchmarks.vlt.io/package-managers/average.md): Every tool across all of this benchmark's scenarios at once. - [clean](https://benchmarks.vlt.io/package-managers/clean.md): A first install on a fresh machine. Every package is resolved, downloaded and linked from scratch. - [cache](https://benchmarks.vlt.io/package-managers/cache.md): The package cache is warm. Nothing else is: no lockfile, no node_modules. - [lockfile](https://benchmarks.vlt.io/package-managers/lockfile.md): A lockfile pins the graph, but nothing is cached and nothing is installed. Resolution is skipped; download is not. - [node_modules](https://benchmarks.vlt.io/package-managers/node_modules.md): node_modules is already populated. The question is how quickly a tool can decide there is little to do. - [cache+lockfile](https://benchmarks.vlt.io/package-managers/cache%2Blockfile.md): Cache and lockfile both warm. No node_modules to reuse. - [cache+node_modules](https://benchmarks.vlt.io/package-managers/cache%2Bnode_modules.md): Cache and node_modules present, with no lockfile to pin the graph. - [lockfile+node_modules](https://benchmarks.vlt.io/package-managers/lockfile%2Bnode_modules.md): Lockfile and node_modules present, with a cold cache. - [cache+lockfile+node_modules](https://benchmarks.vlt.io/package-managers/cache%2Blockfile%2Bnode_modules.md): Everything warm. The best case, and usually dominated by how fast a tool can decide it has nothing to do. - [ci](https://benchmarks.vlt.io/package-managers/ci.md): The tool's CI-oriented install — npm ci and its equivalents. Requires a lockfile and installs strictly from it. - [ci+setup](https://benchmarks.vlt.io/package-managers/ci%2Bsetup.md): Published, with no description yet. ### Task runners The same build and the same script started by each runner, measuring what the runner adds. - [average](https://benchmarks.vlt.io/task-runners/average.md): Every tool across all of this benchmark's scenarios at once. - [build](https://benchmarks.vlt.io/task-runners/build.md): A project build after install. Measures the build, not the install. - [build-cache](https://benchmarks.vlt.io/task-runners/build-cache.md): The same build with a warm build cache. - [run](https://benchmarks.vlt.io/task-runners/run.md): Script execution only: process startup, reading package.json, and spawning the command.