Every monorepo tool folds the lockfile into every key, so pnpm update invalidates the world. @vzn/vx-lockfile parses the lockfile and keys each task on its own project's dependency closure. In vx's own repo that turned 59 re-keyed tasks into 2.
vx is built like Vite: a core pipeline with a named hook at every stage, and plugins that fill exactly the stage they need. A remote cache is one hook. A lockfile parser is one hook. Zero-migration Turbo support is one hook.
Every executor list ends with this machine. Every cache chain ends with .vx/cache. That is the one thing core does without being told, and it is what lets a plugin decline a task and hand it back instead of failing the run.
A telemetry sink in vx receives immutable records and a read-only context. There is no API path from a sink back into scheduling, caching or execution, a sink that throws is disabled for the run, and a sink that hangs is cut off after three seconds. The guarantee is structural.
@vzn/vx-reapi runs tasks on any Bazel Remote Execution API worker pool. The graph, the placement decision, retries, timeouts and the cache all stay on your machine; what moves is one self-contained action per task.
An AI agent working in a monorepo asks the same questions you do: what can I run here, why did that re-run, which tasks flake. @vzn/vx-mcp answers them over the Model Context Protocol, read-only, from the cache database vx already keeps.
