The Bottleneck
Open a terminal. SSH to a machine. Start a coding agent. Now run four more agents on four different tasks.
You can't, really. Each agent owns a working directory. Two agents in the same checkout will trample each other's files, branches, and staging area. So you serialize — one task at a time — or you hand-roll a tmux farm with four clones of the repo, four sets of credentials, four gh pr create calls.
The bottleneck isn't your CPU. It's that one machine can normally run one coding agent at a time without conflict.
The Fix: Worktrees
Git has a feature called worktrees — multiple working directories backed by the same repository, each on its own branch, all sharing one .git. Worktrees let many agents edit the same repo at the same time without stepping on each other.
Rush Cloud builds on this. When you dispatch a task, the runtime creates a new worktree, hands it to the agent, and steps out of the way. The agent has a clean checkout, a fresh branch, and zero awareness of the other agents running on the same machine.
Worktree creation takes about four seconds on a 6,500-file repository. Cheap parallelism, not 4x storage.
Any Machine, Connected
Register a machine once, and it becomes part of your dispatch pool. Anything that can run an agent counts.
Your laptop
The machine you're already on. Free compute, no setup.
A Mac mini at home
Always on, sips power. Dispatch from your laptop, results come back.
A workstation or home server
More cores, more parallel agents. Same dispatch command.
Managed compute
When you don't have spare hardware on hand, we'll run the work. Same CLI.
The dispatch command is identical regardless of where the work runs:
rush cloud run claude my-org/my-repo --prompt "Fix the auth bug"
rush cloud run claude my-org/my-repo --prompt "Add tests" --computer mac-mini
rush cloud run codex my-org/other-repo --prompt "Bump logger" --computer workstation
Each of those is a separate, independent agent. They can all run at the same time, on the same machine or across your whole pool.
What You Can Actually Do With It
- Work on five tickets at once - Dispatch one agent per ticket. They run on whichever machines you've connected. You review the PRs as they come in.
- Run the same task across many repos - Repeat the
--repoflag to dispatch one prompt across every repo it should touch. "Bump every service's logger." One command, N PRs. - Close your laptop and walk away - The agent lives on the remote machine, not in your terminal. Output streams over SSE; reconnect with
rush cloud logs <id>whenever you want to check in. - Steer an agent that's still running -
rush cloud message <id> "also add tests for the edge cases"injects new direction mid-task. No restart. - Send the right work to the right machine - macOS-only tasks (codesigning, notarization, Keychain, your local browser profiles) go to your Mac mini. Heavy Linux builds go to your workstation. The dispatch command picks the destination.
What You're Not Doing
You're not writing the orchestrator. You're not managing tmux windows. You're not provisioning SSH keys to every laptop you might dispatch from. You're not duplicating the repo four times to give four agents space. You're not losing the job when your laptop sleeps.
The dispatch surface absorbs all of that. You write a prompt; you get a PR. Run it once or run a fleet of them in parallel — the command is the same.