rch: Offloading AI Agent Builds to Remote Workers Without Breaking the Loop

The Problem: AI Agents Turn Your Laptop Into a Build Server

When a team runs multiple AI coding agents, each agent can trigger a `cargo build` or `gcc` invocation. The combined load saturates local CPU, making the workstation unusable for interactive work. rch addresses this by intercepting build-like commands at the shell hook level and executing them on remote workers. The target user is a developer or small team that relies on Claude Code or similar agents and has access to a cluster of machines, perhaps cloud instances or idle desktops. The project is not aimed at solo developers who run one build at a time. It is for the scenario where the local machine becomes a bottleneck, not because the code is large, but because many agents are compiling concurrently.

How rch Routes a Build: Hook to Daemon to Worker

rch runs as a Claude Code PreToolUse hook. When an agent is about to run a command, the hook invokes `rch`, which classifies the command in milliseconds. If the command matches an interceptable pattern like `cargo build` or `gcc`, rch forwards it to a local daemon, `rchd`. The daemon performs worker selection, queueing, and cancellation metadata. It then dispatches the command to a remote worker process, `rch-wkr`, which executes the build and returns the artifacts and output. The agent sees the same command semantics as a local run. The classification pipeline is a 5-tier system optimized for fast rejection of non-compilation commands. The daemon owns worker state and slot accounting, and it tracks project affinity to keep related builds on the same worker to reuse caches. For Nix builds, the result stays in the worker's `/nix/store` behind a `result` symlink, and only exit status is streamed back. This is a deliberate trade-off: no artifact copying for Nix, which keeps the protocol simple but means the local agent cannot inspect the built output directly.

Fail-Open Design: The Safety Valve

The most important design constraint is that rch is fail-open. If remote execution is not safe or possible, the command runs locally. This is not a fallback that happens only on errors; it is a core principle. The README states that if remote execution cannot proceed, RCH fails open to local execution. This means a misconfigured worker, a network outage, or an unrecognized command will not block the agent. It also means rch explicitly excludes local-mutating or interactive patterns. `cargo install`, `bun add`, `nix develop` without a command, and any watch/background/piped/redirected commands are not intercepted. This is a sensible boundary. The failure mode to watch is that a command you expected to be offloaded silently runs locally, defeating the purpose. The `RCH_REQUIRE_REMOTE=1` environment variable can force remote execution for supported commands, but then a worker failure will cause the command to fail rather than fall back. That is a sharp edge: you trade safety for determinism.

Getting Started: Install, Init, and Configure Workers

The quickest installation is a one-liner: `curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/remote_compilation_helper/main/install.sh?$(date +%s)" | bash -s -- --easy-mode`. This installs both `rch` and `rchd`, bootstraps config, and can start the daemon. For a manual setup, you clone the repo, run `cargo build --release`, and copy `rch` and `rchd` to `~/.local/bin`. Then run `rch init` to guide you through worker discovery, probing, deployment, toolchain sync, daemon startup, hook installation, and a validation build. If you prefer to write config by hand, create `~/.config/rch/workers.toml` with entries like `[[workers]] id = "css" host = "203.0.113.20" user = "ubuntu" identity_file = "~/.ssh/id_rsa" total_slots = 32 priority = 100`. After that, start the daemon with `rch daemon start`, probe workers with `rch workers probe --all`, install the hook with `rch hook install`, and verify with `rch check` and `rch status --workers --jobs`. The source build note says all dependencies resolve from crates.io, so a clean clone builds without special directory layout.

What rch Intercepts and What It Deliberately Ignores

The intercept list is broad: Rust commands (`cargo build`, `check`, `clippy`, `doc`, `test`, `nextest run`, `bench`, `rustc`), Bun/TypeScript (`bun test`, `bun typecheck`), C/C++ compilers (`gcc`, `g++`, `clang`, `clang++`), build systems (`make`, `cmake --build`, `ninja`, `meson compile`), and Nix (`nix build`, `nix-build`, `nix flake check`, `nix develop -c <cmd>`, `nix shell -c <cmd>`). The exclusion list is equally specific: package managers (`cargo install`, `bun install`), interactive runners (`bun run`, `bun dev`, `bunx`), and mutating Nix commands (`nix profile`, `nix flake update`, `nix store gc`). This is a clear line: anything that modifies local state or expects interactive input stays local. The trade-off is that some commands you might want to offload, like `cargo clean` or `bun build`, are not supported. If your workflow relies on those, you will see no speedup. The classification is fast, but it is not exhaustive, and the README does not claim it will catch every possible build invocation.

The Reliability Stack: More Than a Simple Proxy

Beyond basic routing, rch includes a set of reliability subsystems that are unusual for a tool like this. There is path-dependency closure planning, so a build can include the required repository closure rather than just a single root. Canonical topology enforcement normalizes worker and project roots around `/data/projects` and `/dp` conventions. A repo convergence service tracks worker drift versus required repos and can repair drift. Disk pressure resilience uses pressure scoring and admission control, with safe reclaim that protects active builds. Process triage and remediation use a bounded TERM/KILL escalation with an audit trail. Cancellation orchestration provides deterministic cancellation metadata. All of this surfaces in a unified status output with posture and remediation hints. This complexity is a double-edged sword. It means rch is not a trivial script; it is a system that can handle multi-repo, multi-worker fleets. But it also means there is a significant operational surface: you need to understand convergence, pressure, and triage states to debug issues. The README mentions a `rch rabs` subcommand for CAS (content-addressed storage) garbage collection, which suggests the project is evolving toward a more sophisticated artifact management model.

Limitations and Wrong-Tool Cases

The most obvious limitation is that rch only works as a Claude Code PreToolUse hook. If you use a different agent, like a plain shell script or another AI coding tool, you cannot use rch's hook mechanism. You could manually invoke `rch` as a wrapper, but the README does not document that. Second, the fail-open design means you cannot guarantee that a build will run remotely unless you set `RCH_REQUIRE_REMOTE=1`, and then you risk hard failures. Third, Nix builds are exit-status-only: no artifacts are copied back, so if you need the built binary locally, this is the wrong tool for Nix. Fourth, the worker selection depends on capability advertisement. A Nix build only routes to workers that advertise a `nix` capability, meaning a usable `nix` binary and a populated `/nix/store`. If no such worker exists, the build falls back to local execution or is refused under `RCH_REQUIRE_REMOTE=1`. This is a real constraint for mixed fleets. Finally, the project has no declared license (NOASSERTION), which is a legal red flag for adoption in a corporate environment. You cannot assume you have the right to use or modify the code without clarification from the author.

Alternatives and How They Differ

The closest alternative is to use a distributed build tool like `distcc` for C/C++ or `sccache` for Rust and C++. `distcc` intercepts compiler invocations and distributes preprocessing and compilation across a pool of machines. `sccache` caches compilation results and can use a remote cache like S3 or Memcached. The key difference is that rch operates at the command level, not the compiler level. It intercepts the entire `cargo build` command and sends it as a unit to a remote worker, which then runs its own local build. This means rch can offload not just compilation but also linking, test execution, and even `cargo doc`. `distcc` and `sccache` are more granular: they cache individual compilation units, which can be more efficient for incremental builds. However, they do not handle test commands or build system invocations like `make` or `ninja`. rch also has the hook integration with Claude Code, which neither `distcc` nor `sccache` provides. If you need to offload a full build pipeline including tests, rch is a better fit. If you only need to speed up C/C++ compilation and already have a cache, `sccache` might be simpler and more battle-tested.

Maintenance, Upgrade, and License Considerations

The project is actively maintained, with releases v1.0.59, v1.0.60, and v1.0.61 pushed on consecutive days in August 2026. That suggests a rapid iteration pace. The README does not mention a migration path or upgrade notes, but given the release cadence, you should expect frequent changes. The daemon and worker components are separate binaries, so upgrades likely involve replacing both. The `rch daemon reload` command suggests you can reload configuration without a full restart. The license is listed as NOASSERTION, which means the repository does not declare a standard open-source license. This is a significant concern for adoption. Without a clear license, you cannot legally redistribute or modify the code in most jurisdictions. You should contact the author or check the repository for a LICENSE file before using it in a commercial setting. The README shows a LICENSE badge. This is a blocker for many organizations.

Editorial conclusion

Adopt rch if you run many concurrent AI agents that saturate your workstation and you have SSH-accessible machines with spare CPU. Skip it if you work alone with light builds or need deterministic local-only execution. Before rolling out, verify that your build commands are not on the exclusion list, confirm that remote workers advertise the required capabilities (especially nix), and test the hook in a dry-run or validation build via `rch check` after `rch hook install`.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes