By ByteBot
Cursor shipped “Builds” on August 13 — a pre-prepared environment system that cuts cloud agent startup time by 3x. As of August 17, it’s the default for every Cloud Agent environment with no configuration required and no additional cost. The fix targets a quiet but significant pain point: before Builds, launching a cloud agent on a large monorepo meant waiting through a full boot sequence before the agent could do anything useful.
The Slow Boot Problem
Every cloud agent session used to start the same way: provision a fresh virtual machine, clone all relevant repositories, run the project’s full installation script. On a small repo with a quick npm install, that’s fine. On a large or complex codebase — a monorepo with multiple internal package dependencies, or a system gated behind a multi-step build toolchain — that sequence could consume several minutes before the agent wrote a single line of code.
At the individual developer level, the delay is annoying. At fleet scale, it becomes economically significant. Teams running dozens of parallel agents for automated bug triage, legacy migrations, and CI healing absorb that startup cost with every single run. Cursor’s response is to get rid of the startup cost entirely.
How Builds Work: Copy-on-Write VM Snapshots
A Build is a fully initialized snapshot of your development environment: repositories cloned, dependencies installed, install script executed, disk caches warmed. Cursor prepares these in the background on a default hourly cadence. When an agent session kicks off, it forks from one of these pre-warmed snapshots rather than booting from scratch.
The underlying mechanism is copy-on-write VM forking — the same technique used in kernel-level process forking. The new agent environment shares the source snapshot’s disk image and only allocates new storage blocks when it actually writes something. The fork is nearly instantaneous. Cursor reports time to first token is 3x faster and internal environment boot is 10x faster.
This is worth distinguishing from container layer caching, which is a different technique. COW VM snapshots fork a live, fully running machine — no cold path to warm back up.
Controlling What Goes Into a Build
The install script — defined in the install field of environment.json — controls what gets baked into each Build. Cursor’s guidance is clear: put expensive work here. That means dependency installation, code generation (protobuf schemas, GraphQL types), native compilation, and anything that benefits from a warm disk cache.
// environment.json
{
"install": "npm ci && npx prisma generate && npm run build:proto"
}One constraint: the script must be idempotent, since it runs for every Build and may execute on previously prepared disk state. If your install script isn’t idempotent today, that’s worth fixing regardless of Cursor Builds.
Bad Commit Survival
The reliability story is arguably as important as the speed story. When a dependency commit breaks an environment build, agent fleets no longer go down. The previous successful Build stays active, and new agent sessions continue forking from that last known-good snapshot while the breakage gets investigated in the background. This eliminates a class of incidents that previously required manual intervention to restart a fleet of agents.
What Builds Enable: /goal and Long-Lived Agents
On August 19, Cursor shipped a closely related update: the /goal command. You give an agent a long-lived objective — /goal fix all flaky tests and make CI green — and it works toward completion rather than treating each session as isolated. Agents now automatically subscribe to PRs they create, driving them to merge by fixing CI failures and responding to bot comments. The Slack integration lets you instruct an agent to check back later and keep going.
Builds make /goal viable because the per-invocation startup cost is negligible. A long-lived goal that requires dozens of agent actions no longer accumulates minutes of dead time between actions.
What to Do Now
If you use Cursor Cloud Agents, you already have Builds. No migration, no config change, no extra billing. The one actionable step: review your environment.json install script and move expensive setup steps there if you haven’t already. Teams on large monorepos will see the most pronounced startup time reduction.
Builds don’t solve everything. Cost per agent action, model quality on long tasks, and the fundamental challenge of correctness in autonomous coding remain open problems. But removing startup friction from fleet-scale agentic work is a concrete step toward making “run 50 agents in parallel” a practical workflow rather than a theoretical one. The infrastructure is catching up to the ambition.
