remote_compilation_helper
Intercepts cargo/gcc builds from AI coding agents via hooks and transparently routes them to remote worker machines, returning artifacts as if compiled locally
rch, a remote compilation helper for AI coding agents
rch intercepts build and test commands from AI coding agents and routes them to remote worker machines, returning artifacts as if they ran locally.
What rch intercepts and what it leaves local
rch, short for Remote Compilation Helper, runs as a Claude Code PreToolUse hook and classifies build like commands in milliseconds, then executes the ones it recognizes on remote workers. The README lists the ecosystems it understands. For Rust it handles cargo build, cargo check, cargo clippy, cargo doc, cargo test, cargo nextest run, cargo bench, and rustc. For Bun and TypeScript it handles bun test and bun typecheck. For C and C++ it handles gcc, g++, clang, and clang++. For build systems it handles make, cmake build, ninja, and meson compile. For Nix it handles nix build, nix-build, nix flake check, nix develop with a command, and nix shell with a command, but only on workers that advertise a nix capability. Just as important is what rch deliberately does not intercept. It skips package management commands such as cargo install, cargo clean, bun install, and bun add. It skips Bun runners and dev commands such as bun run, bun build, bun dev, and bun x. It skips interactive or mutating Nix commands such as bare nix develop, nix shell, nix run, nix repl, nix profile, nix flake update, nix store gc, and nix-env. It also skips watch, background, piped, or redirected commands where deterministic offload would be unsafe. This boundary keeps rch focused on pure compilation and test workloads and avoids touching commands that change local state or need a live terminal.
Installing, configuring, and the fail open design
The README offers a quick install with a curl piped installer that sets up rch and rchd, bootstraps configuration, and can start the background daemon. A from source build clones the repository, runs cargo build release, and copies the rch and rchd binaries into ~/.local/bin. The authors note that all dependencies resolve from crates.io, so a clean clone and build works on any machine. First time setup is driven by rch init, which can discover workers from your SSH config, probe and select them, deploy the rch-wkr agent, synchronize toolchains, start the daemon, install the hook, and run a validation build. You can also configure manually through files: a user config at ~/.config/rch/config.toml, a worker list at ~/.config/rch/workers.toml, and an optional project override at .rch/config.toml with a .rchignore for exclusions. A central design rule is that rch fails open. If remote execution cannot proceed safely, the command runs locally instead of blocking your work. That posture is carried into the security model too: the hook path stays fail open to avoid deadlocks, transport uses SSH, worker commands are constrained to classified execution paths, and sensitive fields are masked. The README recommends using workers you control, dedicated SSH keys, patched and isolated workers, and telemetry for production like use.
Worker selection, placement controls, and observability
rch is built from several crates. The rch crate is the hook and primary command line interface. The rchd crate is the local daemon that owns worker state and slot accounting. The rch-wkr crate is the worker agent that runs builds and manages its cache. The rch-common crate holds shared protocol and types, and rch-telemetry handles telemetry collection. The architecture flows from the agent shell through the PreToolUse hook into rchd, which selects a worker, queues the job, and tracks health, then the chosen rch-wkr executes the command. Built in placement controls let you steer this. You can request a specific worker with RCH_WORKER, force offload attempts with RCH_FORCE_REMOTE, or demand strict remote only with RCH_REQUIRE_REMOTE, which refuses local fallback for proof style runs. RCH_QUEUE_WHEN_BUSY makes a busy worker wait instead of falling back, and a wait timeout bounds that wait. The resolved plan for any command is visible through rch diagnose with the JSON flag, which reports the requested and effective worker, the strict remote policy, the queue policy, and any diagnostics. For observability, rch exposes daemon health endpoints, Prometheus metrics, OpenTelemetry tracing, worker SpeedScore history, and status APIs that show queue and build history plus active alerts. Quick checks include rch status with the workers and jobs flags, rch speedscore for all workers, and rch doctor with the JSON flag.
Editorial conclusion
rch is a Rust tool under an MIT license with an OpenAI and Anthropic rider that you install with the curl piped installer or by running cargo build release, and it fails open to local execution when remote work is not possible.
Community notes