Cloud features

Most of Cluster Build runs locally on your machine. /megaplan, /megareview, and the cloud_task tool reach into the cloud for work that's bigger than a single session — they run on Cluster's Managed Agents service, on remote VMs, while you watch the results stream into your terminal.

cluster config set managed_agents_url https://agents.clusterbase.dev

/megaplan

/megaplan [--repo name=spec] <request>

/megaplan offloads read-only planning to a cloud VM. Cluster provisions an ephemeral environment with your repositories cloned, a planning agent explores the code there, and the resulting plan streams back to your terminal — ready for you to review and implement locally. Nothing is changed on the remote VM; the output is a plan, not a commit.

Use it when planning a change needs more context than your local session can hold, or spans repositories you don't have checked out.

/megaplan is model-managed: the assistant starts the run, tells you it's continuing in the background, and delivers the finished plan back into the conversation on its own — you don't poll for it. Use /megaplan --status to check on an in-flight run, or /megaplan --stop to cancel it.

A --repo name=spec can point at a local path (., ./path, /abs, ~/path) that has no GitHub remote at all — see Sharing local source below for how that's captured and approved.

/megareview

/megareview

/megareview launches a cloud multi-agent code review. The assistant infers what to review — a diff against a base branch, your uncommitted changes, a specific commit, or custom instructions — from the conversation and your repo state, asking only if the scope is genuinely ambiguous. A fleet of specialist review agents (correctness, security, performance, and more) then runs in parallel on a remote VM, and their findings are cross-validated into a single consolidated review. When the reviewed changes match an open pull request, the review is also posted there as a comment.

Like /megaplan, /megareview is model-managed: it runs in the background and its findings are delivered back automatically. Use /megareview --status to check progress, or /megareview --stop to cancel it.

/megareview always shares a snapshot of your current repository's working tree (see Sharing local source) so the review agents see your actual changes, even uncommitted ones.

cloud_task

cloud_task is a native tool the assistant can call on its own — there's no slash command — to delegate a bounded coding task to a cloud sandbox instead of making the change locally. Give it a task description and the same kind of repos (local paths or GitHub repositories) that /megaplan accepts, and it starts a run the same way /megaplan does: start, status, and stop actions, with status/stop taking no further input.

The sandbox's resulting patch and base-tree metadata are saved to your local session — cloud_task never applies a patch automatically. Review it like any other proposed change before deciding whether to apply it. Stopping a run early still recovers whatever partial patch is available before the sandbox is torn down.

Sharing local source

/megaplan, /megareview, and cloud_task can all work against a local repository that has no GitHub remote at all. Instead of cloning from origin, Cluster Build builds a bounded, history-free Git bundle from your working tree — your tracked files plus any untracked files you explicitly select — and asks you to approve it before anything leaves your machine:

Temporary source upload; expires within one hour.
Original Git history, hooks and configuration are excluded.

The prompt lists each repository's name, path, size, and SHA-256, plus any untracked files included. Declining cancels the run. Approved snapshots are uploaded as a temporary run input capped at 16 MiB per repository (64 MiB total) and expire automatically within an hour; the remote sandbox never receives your Git history, hooks, or local configuration, and results never modify your local checkout.

Every local --repo name=spec is snapshotted this way, whether or not it has a GitHub origin remote — only a spec given as a GitHub repository is resolved to a clone URL and cloned on the remote VM instead. At most ten repositories can be attached to one run.

How it runs

All three run server-side, on the same infrastructure described in the Managed Agents docs:

• On-demand runs — how a one-off cloud run is kicked off, with your repos cloned in.
• Environments — the Firecracker VMs the agents execute inside, provisioned on your behalf and torn down automatically.

The VM is provisioned under your own identity using the credentials from cluster login, so it sees only what you can access.

Next steps

• Config basics — where managed_agents_url lives.
• Managed Agents — define, schedule, and trigger your own cloud agents beyond these built-ins.