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.
The hard part of 'start the tests once the server is up' is knowing when it is up. vx watches a persistent task's output for a pattern, holds its dependents until the line appears, and tears the server down when the run ends.
A task runner spawns processes, and the one thing every process spawner owes you is that they die when it does. Here is the teardown vx runs on a signal, an abort, a timeout or a crashed sibling, and the tests that pin it.
vx watch does not filter filesystem events against your input globs. It re-runs the graph and lets the cache key decide, which is tens of milliseconds for an irrelevant edit and exactly right for a relevant one.
vx names a task flaky only when its exact cache key has both passed and failed on record, or it needed a retry this run. A failure on inputs that never passed is a break, not a flake. No service, no upload: the local run history is enough.
A Turborepo workspace runs under vx with a two-line workspace file and no config rewritten. When you want the TypeScript configs, one command writes them, and a package that has one keeps it while the rest stay on turbo.json.
Run an Nx repo under vx unchanged with nx(), executors included, then trade executors for shell commands at your pace. bunx @vzn/vx-migrate reads the resolved project graph Nx itself uses, so plugin-inferred targets come along, and an executor target migrates as the nx-exec line that runs it.
Two benchmarks: a synthetic 1,090-package workspace where all three runners see the same graph, and solidjs/solid, a real Turbo repository with vx on top of its own turbo.json. Every number is a command away, and the cold rows are read honestly.
