Configure one Cloud Agent, point it at a repo, paste your .env, and save. Once it shows "Active", teammates with delivery permission can ship a Brief or Task from the cloud, in parallel, without anyone's laptop in the loop.
A Cloud Agent is a configured cloud sandbox plus the AI agent that runs inside it. The sandbox knows your repo URL, your env vars, and your build and test commands. The AI agent knows the Brief, the relevant Blueprints, and the Methods. When a teammate clicks Deliver on a Brief, launches from a Task, or triggers a Routine, the Cloud Agent boots, the AI executes the work, and a pull request lands in your repository.
Cloud Agents complement the IDE flow rather than replacing it. Most engineers ship from their IDE using the Hamster plugin — they want control. Cloud Agents are the path for deliveries that don't need an engineer at the keyboard: a PM clicking Deliver on a Brief, Routines running scheduled work, or parallel deliveries across the Team.
Setting up a Cloud Agent uses a guided flow:
Repository detection — Connect your GitHub repository and Hamster analyzes its languages, frameworks, build system, and package manager.
Setup plan — Hamster proposes Install, Build, Test, and Run commands plus relevant environment configuration. Review and refine the plan before saving.
Install validation — Hamster prepares the sandbox and automatically executes the Install phase. An install failure surfaces as an actionable setup error. Build, Test, and Run remain available to the coding agent during delivery rather than running as setup gates.
Snapshot creation — After installation succeeds, Hamster creates a reusable snapshot. Deliveries boot from that prepared environment instead of repeating the initial setup.
After setup completes, the Cloud Agent shows Active and is ready to deliver. You can configure multiple repositories and multiple Cloud Agents for different parts of your codebase.
Open an active Agent at any time to review its environment variables and saved Install, Build, Test, and Run commands in one place.
Each Cloud Agent shows a status pill that mirrors the sandbox lifecycle:
The list updates live, so you can save a config and watch the pill change without refreshing.
Env vars are encrypted at rest and never exposed in the UI after they're saved. You can paste:
.env blob — comments, blank lines, and export prefixes are tolerated..env overrides the prior value cleanly.Vars are scoped to the Cloud Agent and made available to the sandbox at Delivery time.
You can run as many Cloud Agents as your team needs. Common patterns:
Two Briefs targeting different Agents deliver in parallel without contention. Two Briefs targeting the same Agent each get their own sandbox, also in parallel, booted from the shared snapshot.
When a Delivery launches, the AI agent inside the Cloud Agent receives:
The agent uses all of this to understand not just what to build, but why and how — which leads to more contextually appropriate implementation than a generic AI coding tool would produce in isolation.
Hamster Cloud can run deliveries with Cursor CLI using Grok 4.6 High Fast.
This is separate from Deliver with Cursor Cloud: Cursor Cloud Agents run in Cursor's hosted environment, while Cursor CLI runs inside the Hamster Cloud sandbox.
Each Delivery moves through a set of states Hamster tracks and displays:
Only one Delivery can be active for a given Brief at a time. If you try to launch a second run while one is in progress, you'll wait for it to finish or cancel it first.
If a Cloud Agent stops booting cleanly — bad commit, broken dependency, stale snapshot — open the Agent's overflow menu and click Reset. Hamster clears the live sandbox handles, flips the Agent back to Pending, and re-runs the build. When it lands on Active again, it has a fresh snapshot.
Reset is the right move when:
When a Cloud Agent opens a pull request, it creates commits with the following properties:
hamster[bot], a GitHub bot account that represents the Cloud Agent's work.Commit verification status is environment-dependent and best-effort. By default, commits are unsigned. When signature verification is available, Hamster will attempt to sign commits; if that fails, commits fall back to unsigned. Commit signature verification is not configurable per workspace.
Configuring Cloud Agents requires the environments.manage permission, while delivering a Brief requires documents.manage. The seeded Owner, Admin, and Creator roles can deliver; Reviewers cannot. For sensitive environments, grant these permissions only to the roles that should configure or launch work.
Cloud Agents are available on Team and Enterprise plans. If your workspace is on the free plan, clicking Deliver on a Brief or opening the Cloud Agents settings will show an option to upgrade.
The Team plan now starts at a single seat — there's no creator minimum. See the pricing page for current rates.
Cloud Agents and the IDE flow (the Hamster plugin) are two paths to the same destination — a PR in your repo from a Brief. Use whichever fits the situation:
Most teams use both. The Hamster plugin for individual engineers; Cloud Agents for everything else.
.env source of truth somewhere stable (1Password, a secrets manager). Re-paste into the Cloud Agent any time the source changes; the parser handles re-paste cleanly.