rch (Remote Compilation Helper): routing AI agent builds to remote workers

The CPU contention problem rch was built for

Running one AI coding agent is tolerable. Running several at once is not, because each one periodically fires off `cargo build` or `cargo test`, and those processes compete for the same cores. The workstation stops responding to its owner while the agents wait on each other. The README states the problem in exactly those terms: many concurrent agents can saturate local CPU and make the workstation unusable.

rch, short for Remote Compilation Helper, targets that specific situation. It runs as a Claude Code PreToolUse hook, classifies build-like commands in milliseconds, executes them on remote workers, and returns artifacts and output as if they ran locally. The audience is narrow and identifiable: developers who drive multiple agents from one machine and who have other machines available to absorb the compile load. If you run a single agent sequentially, the contention rch removes mostly does not exist for you, and the operational surface it adds (a daemon, worker agents, SSH configuration, toolchain sync) is cost without benefit.

How classification, the daemon and workers fit together

The data flow has four stages. An agent shell issues a command. The PreToolUse hook hands it to `rch`, which runs a five-tier classification pipeline. The README describes that pipeline as optimized for very fast non-compilation rejection, which matters because most commands an agent emits are not builds and should not pay a network round trip. If the command classifies as build-like, it goes to `rchd`, the local daemon.

The daemon owns worker state and slot accounting, does cache-aware worker selection with project affinity, and holds queueing and cancellation metadata. Below it sit remote workers running `rch-wkr`, which execute the build or test command, manage a worker-side cache, and report capabilities, health and telemetry back up. The workspace splits along the same lines: `rch` for the hook and CLI, `rchd` for scheduling and reliability APIs, `rch-wkr` for execution and caching, `rch-common` for shared protocol and types, `rch-telemetry` for collection and storage.

Capability matching is the part worth understanding before you deploy. Nix builds only route to workers that advertise a `nix` capability, meaning a usable `nix` binary plus a populated `/nix/store`. On a fleet with no such worker, Nix commands fall back to local execution, or are refused outright when `RCH_REQUIRE_REMOTE=1` is set. Nix outputs also stay on the worker behind a `result` symlink, so those runs are streaming, exit-status-only commands: the flake source is synced out, the build runs, and no artifacts come back.

Installing rch and running a first remote build

The README's recommended path is the installer, which installs `rch` and `rchd`, bootstraps configuration, and can install and start the background daemon:

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/remote_compilation_helper/main/install.sh?$(date +%s)" | bash -s -- --easy-mode

After that, `rch init` is the guided path. According to the README it can walk through worker discovery from SSH config and aliases, worker probing and selection, `rch-wkr` deployment, toolchain synchronization, daemon startup, hook installation, and a validation build.

rch init

If you prefer to configure workers by hand, the README gives this `workers.toml` example under `~/.config/rch/`, with an id, host, user, identity file, slot count and priority:

[[workers]]
id = "css"
host = "203.0.113.20"
user = "ubuntu"
identity_file = "~/.ssh/id_rsa"
total_slots = 32
priority = 100

The manual sequence that follows is to start the daemon, probe workers, install the hook, and inspect posture:

rch daemon start
rch workers probe --all
rch hook install
rch check
rch status --workers --jobs

A reader running this should expect `rch workers probe --all` to report each configured worker and its capabilities, and `rch check` to print posture plus remediation hints. If probing returns nothing, the daemon has no worker to schedule onto and builds will stay local. Building from source is also documented: clone the repository, run `cargo build --release`, and copy `target/release/rch` and `target/release/rchd` into `~/.local/bin/`. The README notes that all dependencies, including the FrankenTUI, `rich_rust` and TOON crates, resolve from crates.io, so a clean clone builds without a pre-cloned dependency tree.

What rch deliberately refuses to intercept

The interception table is broad within its categories: `cargo build`, `check`, `clippy`, `doc`, `test`, `nextest run`, `bench` and `rustc`; `bun test` and `bun typecheck`; `gcc`, `g++`, `clang`, `clang++`; `make`, `cmake --build`, `ninja`, `meson compile`; and the Nix family including `nix build`, `nix-build`, `nix flake check`, `nix develop -c <cmd>` and `nix shell -c <cmd>`.

The exclusion list is equally explicit, and it is the practical boundary of the tool. Package management is out: `cargo install`, `cargo clean`, `bun install`, `bun add`, `bun remove`. Bun runners and dev servers are out: `bun run`, `bun build`, `bun dev`, `bun x` and `bunx`. Interactive and mutating Nix commands are out: bare `nix develop` and `nix shell`, `nix run`, `nix repl`, `nix profile`, `nix flake update`, `nix store gc`, `nix-env`, `nix-shell`. Watch, background, piped and redirected commands are also excluded, on the grounds that deterministic offload is unsafe there.

That exclusion set tells you where rch is the wrong tool. A frontend project whose build step is `bun run build` gets no offload at all, and neither does a workflow built around watch mode or a piped command. The README's own framing is that if remote execution cannot proceed safely, RCH fails open to local execution. Fail-open is the right default for an agent hook, since a hook that blocks a build is worse than a slow one, but it also means a misconfigured worker fleet degrades silently into the local behavior you were trying to escape. The posture output from `rch check` and `rch status --workers --jobs` is how you notice that, and it is worth checking rather than assuming.

Reliability subsystems and the operational cost they imply

Beyond routing, the repository carries a set of reliability features aimed at multi-repo, multi-worker fleets: path-dependency closure planning so a build can pull in required repository closure rather than a single root; canonical topology enforcement normalizing worker and project roots around `/data/projects` and `/dp`; a repo convergence service that tracks worker drift against required repos and can repair it; disk pressure scoring with admission control and safe reclaim that protects active builds; bounded TERM/KILL process triage with an audit trail; cancellation orchestration; and a unified posture report.

These are not incidental. They exist because a fleet of workers running agent-driven builds drifts: repositories fall out of sync, disks fill, orphaned processes accumulate. The command surface reflects the same reality, with `rch gc` to reap stale remote target directories, `rch cache warm|clean|status` for remote source and target caches, and a separate `rabs` family (`rabs gc plan|run|history`, `rabs worker|doctor|inventory|reconcile`) that the workspace manifest describes as an Asupersync-native accelerated build sidecar. The Cargo workspace lists eleven `rabs-*` crates alongside the five `rch-*` ones.

The honest reading is that rch is not a small script you drop in and forget. A single-worker setup is manageable. A fleet with convergence repair, disk pressure handling and process triage is infrastructure, and it needs an owner who understands what `rch gc` and the `rabs` reconciliation commands do before running them against production workers.

Alternatives and where the approaches differ

The obvious alternative is distributed build tooling in the compiler ecosystem itself, such as sccache or a remote-cache arrangement. The difference is where the decision is made. A compiler wrapper decides at compile time, after the build system has already started, and it optimizes for cache hits on object files. rch decides before the command runs, at the agent hook layer, and optimizes for getting the whole command off the local machine. That means rch can move a `cargo test` or a `make` invocation wholesale, which a compiler wrapper cannot, but it also means rch depends on command classification being correct. A command it does not recognize runs locally, full stop.

A second alternative is simply running the agents on the build machine, over SSH or in a container, so there is no local/remote split to manage. That removes the daemon, the worker agent and the fail-open ambiguity entirely. It costs you the local editing experience, and it does not help if you want the agent working in a local checkout. rch's design assumes you want the checkout local and only the compilation remote; if that assumption does not hold for you, the simpler arrangement wins.

Maintenance, licensing and what to check before committing

The repository is not archived, and the last push was on 2026-08-29, with v1.0.61 released the same day and two releases in the preceding two days. That is a fast release cadence, and it cuts both ways: fixes arrive quickly, and so does churn. The workspace version is declared as 2.0.0 in `Cargo.toml` while the releases are tagged v1.0.x, which is the kind of inconsistency worth confirming against the changelog before you pin a version in a deployment script.

Licensing needs attention rather than assumption. The repository's license field reports NOASSERTION, and the workspace manifest declares `license = "LicenseRef-MIT-OpenAI-Anthropic-Rider"`, a custom identifier that is not a standard SPDX license. The README's badge links to a LICENSE file, but the terms are not summarized in the README. If you are adopting this inside a company, read that file and route it through whoever handles licence review; a non-standard identifier with named third parties in it is not something to wave through on the strength of the word MIT appearing in it.

Upgrade cost is tied to the daemon and worker agents rather than the CLI. `rch daemon reload` exists, and the repository ships an `UPGRADE_LOG.md`, so upgrades are a tracked concern. The practical check before adopting is to run the validation build that `rch init` offers and confirm that artifacts land in your local target directory, then run `rch gc --dry-run` to see what stale remote directories already exist on your workers.

Editorial conclusion

Adopt rch if you run several AI coding agents in parallel on one workstation and already have SSH-reachable build machines with matching toolchains; the installer path plus `rch init` is the shortest route to a working setup. Do not adopt it if your builds are mostly `bun run`, `cargo install`, watch-mode or interactive commands, since the README states those are not intercepted, or if you cannot give workers a populated `/nix/store` when you need Nix builds offloaded. Verify first that `rch workers probe --all` reports the capabilities you actually need, and that a validation build returns artifacts to the local target directory rather than only to the worker.

Frequently asked questions

Official sources

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