cargo-hauler weekly downloads statistics

cargo-hauler

One Cargo, many agents. cargo-hauler is a broker for cargo on a machine where several AI coding sessions (Claude Code, Codex, Cursor), scripts, and terminals build the same Rust workspaces at once. It keeps them from blocking each other on the build directory, runs the shared work once, and hands every requester its own result.

The GitHub Action applies warm workers to a repository's PR queue. It manages isolated snapshots, per-PR checks, and compiler reuse from one trusted CI recipe. Routing delegates a trusted PR at once, before its lane checks exist, so consumers relying on that optimistic delegation should also run the Action with mode: enqueue on a schedule to recover heads whose enqueue run was missed. A lane can run several numbered workers through a worker: [1, 2] matrix with one hauler-ci-- concurrency group each. Workers agree on one holder for each head.

The problem

Agents run cargo check, cargo test, and cargo build often and independently. On a shared machine, the same crates compile five times over, and everyone blocks on Blocking waiting for file lock on build directory. The CPU saturates, and shell tools kill a build at their ten-minute timeout with no result. Nobody can see what is running, what is queued, or why their command is slow.

What it does

• Intercepts every Cargo invocation. Hooks rewrite cargo … in agent shells, an optional PATH shim covers scripts and terminals, and MCP tools let agents submit work directly. • Coalesces compatible requests. A byte-identical command attaches to the run already in flight, a narrower check attaches to a broader build, and queued tests with the same selection fold into one --no-fail-fast run. Riders receive the leader's streamed output and exit code as if they had run it themselves. • Schedules and admits work per workspace lane. A machine-wide permit cap and load, memory-pressure, and heavy-profile gates control admission. Cost estimates come from run history and kache priors, and --after cc-N dependencies order a test after the build it needs. • Keeps a ticket (cc-N) for every request. The ticket records status, exit code, live output tail, the whole output log on disk, timings, and the session that asked. Long builds become background tickets that agents await, and a stop hook holds an agent's turn until its build finishes. • Protects the machine. cargo-hauler refuses cargo clean while builds are in flight and flags stalled processes (and kills them when their owner is gone). hauler kill frees a stuck lane through the broker instead of by PID. • Shows everything in a live dashboard. The dashboard shows contention, in-flight and queued work, lanes, per-command timings, compute avoided, and kache data.

Quick start

Install from npm. The package carries a ready-made plugin for each host and its own installer, so you need nothing else:

Restart the host (or reload the window) so new sessions load the hooks. The daemon starts on demand with the first brokered request. hauler status and the hauler_status tool show what is running as text, and the hauler_dashboard tool opens the dashboard in hosts that render MCP Apps. To use the hosts' own plugin commands or build from a checkout, see Install.

The CLI is hauler on PATH from npm i -g cargo-hauler. Never run scripts/hauler.mjs or any path under .claude/plugins/cache, .codex/plugins/cache, .cursor/plugins, or artifact/ directly.

Commands and tools

hauler is the command line. Agents reach the same operations as MCP tools (hauler_status, hauler_await, …), and hooks rewrite plain cargo … into hauler exec automatically. Every command except exec, daemon, and install-shim also accepts --json for the machine-readable value.

| Command | Behavior |…

Description from the npm listing.