Show HN: VX – Vite-like task runner. Fastest, safest, open, yours. VX, a new open-source task runner from the vznjs project, launched with a benchmark claiming it adds less overhead than Turborepo 2.11.7 and Nx 23.3.0 on a synthetic monorepo of 1,601 projects and 9,603 tasks across 30 dependency levels, tested on 2026-10-12 on linux x64 with 4 cores. VX ships an agent-oriented skill installable via `npx skills add vznjs/vx` that teaches coding agents commands including `vx run`, `vx last --failed`, `vx why` and `vx docs`, and it reports JSON with a published schema. The tool is MIT-licensed with no paywall, cloud or account, and offers per-task file sandboxing plus remote execution over Bazel's open REAPI protocol. npx skills add vznjs/vx One skill teaches any coding agent the CLI: run tasks, read failures and history, ask why. - vx run - vx last --failed - vx last --stats - vx why - vx docs Built for agents → https://vznjs.github.io/vx/concepts/ai-first/ vx runs and caches your task graph correctly, and every stage after that is a seam you can fill. // ai first npx skills add vznjs/vx vx run vx last --failed vx last --stats vx why vx docs A re-run names its cause, down to the file that changed. bash $ vx why @demo/web build verdict cache key changed: upstream @demo/ui build root cause: @demo/web build ← @demo/ui build ← file packages/ui/src/index.ts --format json Every report verb prints JSON with a published schema, and failures keep their full log. vx show vx info vx last --dry=json // extensibility is king Every plugin below is a separate package on core’s public seams, and yours can be too. // 9,603 tasks · 1,601 projects · 30 levels · identical commands, identical concurrency Time each tool adds over the ideal run; lower is better. Benchmark workload: a synthetic monorepo of 1,601 projects and 9,603 tasks in 30 dependency levels, five core libraries a quarter of the projects use; build 300 ms, test and typecheck 150 ms, lint 75 ms, publish 30 ms; real repos with uneven task times will differ. Run 2026-10-12 on linux x64, 4 cores: vx at commit 126d60a93, Turborepo 2.11.7, Nx 23.3.0, Vite Task vite-plus 1.1.0. // vx vs Turborepo vs Nx | | vx | Turborepo | Nx | |---|---|---|---| | A file sandbox for every task | Local and free, Linux and macOS | None | Nx Cloud add-on | | Remote execution you host | Bazel’s open REAPI protocol | None | Nx Agents on Nx Cloud | | A remote cache on any backend | REAPI, Turborepo’s or Nx’s wire, by plugin | Its own HTTP API | Nx Cloud or its own API | | Config is code | TypeScript, evaluated and hashed | JSON | JSON, merged with inferred tasks | | No background daemon | None | None for turbo run | On by default | // four commands npm install -D @vzn/vx npx @vzn/vx init a vx.config.ts per package; add the cache block each TODO shows npx @vzn/vx run build --all builds in dependency order; stores what is cached npx @vzn/vx run build --all again: the cached tasks are up-to-date Coming from Turbo or Nx: the same vx init writes the native vx config from it. // one run, after you edit app app builds after what it uses. ui and api build at once. // what you can count on A task’s cache key covers every file, setting and env var it declares. Caching in depth → A sandboxed task cannot read a workspace file it did not declare. Sandboxing → Plugins decide where tasks run, where the cache lives and who watches. Writing a plugin → MIT, no paywall, no cloud, no account. Migrate →