# 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](/docs/agents/overview) service, on remote VMs, while you watch the
results stream into your terminal.
Cloud features need the managed-agents host set in your config:
```bash
cluster config set managed_agents_url https://agents.clusterbase.dev
```
All three are available in interactive sessions only.
## /megaplan [#megaplan]
```text
/megaplan [--repo name=spec]
```
`/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](#sharing-local-source)
below for how that's captured and approved.
## /megareview [#megareview]
```text
/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](#sharing-local-source)) so the review agents
see your actual changes, even uncommitted ones.
You can also trigger a review from GitHub by mentioning `@cluster-build review`
(or `@cluster-build megareview`) on a pull request — see
[Triggers](/docs/agents/triggers).
## cloud\_task [#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 [#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:
```text
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 [#how-it-runs]
All three run server-side, on the same infrastructure described in the
[Managed Agents](/docs/agents/overview) docs:
* **[On-demand runs](/docs/agents/runs)** — how a one-off cloud run is kicked off,
with your repos cloned in.
* **[Environments](/docs/agents/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 [#next-steps]
* **[Config basics](/docs/build/config/basic)** — where `managed_agents_url`
lives.
* **[Managed Agents](/docs/agents/overview)** — define, schedule, and trigger your
own cloud agents beyond these built-ins.