Cursor Cloud Agents Start Up to 3x Faster With Builds

Cursor has changed the startup path for Cloud Agents, and since August 17, 2026 every environment uses it by default with nothing to enable. Its Builds feature prepares ready-to-use copies of a development environment in the background, and Cursor says agents can start up to 3x faster as a result. Builds are available at no additional cost. (Cursor Builds; Cloud Agent Builds documentation)

Instead of booting a machine, cloning a repository, installing dependencies, and running the install script after every request, an agent can fork a warm environment that has already completed those steps. That makes the update relevant to long-running tasks where setup time otherwise becomes part of the interaction. (Cursor Builds)

Key Takeaways

• Builds prepare development environments continuously in the background.
• Cursor says Cloud Agents start up to 3x faster with the feature.
• There is no additional cost for Builds.
• Failed Builds do not replace the last successful environment.
• The Cloud Agents dashboard shows logs, versions, commit SHAs, and the Build used by each run.
• Builds are now the default for every environment. Cursor scheduled the switch for August 17, 2026; its documentation, checked August 23, 2026, no longer describes an opt-in.

What a Build prepares

A Build is a copy of the environment that Cursor prepares before the next agent session needs it. The process can boot a machine, clone repositories, install dependencies, and fully execute the install script. When that work succeeds, the result becomes the environment that future agents start from. (Cursor Builds)

Cursor says it keeps warm copies ready, so a new agent can fork a live machine instead of restoring an environment from disk. The start command still runs when an agent is prompted for the first time; it remains the right place for services that need to be fresh at session start, such as Docker containers or other long-running processes. (Cursor Builds)

The August 13 announcement says "by default, Cursor runs a new build every hour." Read that as the check interval, not the rebuild interval. Cursor's documentation, checked August 23, 2026, lists four reasons a Build starts and gives recurring checks a Skipped outcome: a recurring check skips the Build when nothing has changed since the last completed one, meaning no new commits on any repository's default branch and no configuration or secret change. Skipped checks "complete in seconds, run no install commands, and leave the active Build in place," so a quiet repository produces mostly Skipped entries and few actual Builds. Only recurring Builds can be skipped; manual, agent-requested, and configuration-change Builds always run. (Cloud Agent Builds documentation)

Treat a Build as a prepared starting point, not a frozen replacement for the repository's current state. The dashboard records the exact commit SHA each Build captured for each repository, and the drift control the announcement described only as "a configurable threshold" is documented concretely: an Update stale builds toggle with a Staleness threshold that defaults to 24 hours. With it on, an agent starting from a Build older than the threshold pulls the latest default-branch code at start; set the threshold to 0 to always pull; with it off, the agent uses the Build's recorded commit as-is. (Cloud Agent Builds documentation)

Speed and cost

Cursor's announcement says Cloud Agents start up to 3x faster with Builds. The accompanying explanation says Cursor's internal environments now boot 10x faster and reach the first token 3x faster. Cursor presents these as product performance results rather than an independent benchmark, so the actual improvement will depend on repository size, dependencies, install scripts, and task shape. (Cursor Builds)

Builds are included at no additional cost. That matters for teams that want to reduce setup latency without trading a faster path for a separate execution fee. Cursor's documentation states it plainly: "Do Builds cost extra? No. Builds are included with Cloud Agents." (Cursor Builds; Cloud Agent Builds documentation)

The safety behavior when preparation fails

A failed dependency update, install script, or Docker build does not become the active environment. Cursor says it notifies the user, leaves new and existing sessions on the last successful Build, and keeps the failed preparation available for debugging in the background, manually or with an agent. (Cursor Builds)

That rollback behavior is important for autonomous work. A broken environment can slow down a run, but it should not silently become the base for every new session. The Builds dashboard records Build status, start time, versioning, logs, and the association between an agent run and the exact Build it used. (Cursor Builds)

How to manage Builds now that they are the default

What this section used to say, and why it changed. Until this update it carried the August 13 announcement's migration path: open the environment in the Cloud Agents dashboard, go to the Builds tab, click Enable Builds, and optionally run a setup agent first to review proposed configuration changes. That path was for the window before August 17, 2026, and it is gone from Cursor's documentation. There is nothing left to enable.

What the Builds tab does today, per Cursor's documentation checked August 23, 2026:

• See every Build's type, status, and start time.
• Open a Build to inspect its details and logs.
• Select Trigger build to run a Build on demand.
• Activate a draft Build or deactivate a Build.
• Cancel an in-progress Build.
• Start an agent from a specific Build.
• Configure Update stale builds and the Staleness threshold.

Three environment commands now split the work, and putting something in the wrong one is the most common way to lose the speedup. install runs during each Build and is where dependencies, code generation, compiled artifacts, and disk-cache warming belong; it must be idempotent, because it can run repeatedly on top of previously prepared disk state. start runs at the beginning of each agent run and is where Docker, databases, and tunnels belong. terminals also runs at agent start, for app processes in shared tmux terminals. Builds preserve disk state only: running processes, shell exports, and in-memory caches stop when Cursor snapshots the machine. (Cloud Agent Builds documentation)

If your install process needs credentials for a private registry, use team or environment secrets. User secrets are added only when an agent starts; they are not available during Builds and do not become part of a shared snapshot. (Cloud Agent Builds documentation)

Agents can also inspect and manage Builds through the built-in Cursor Cloud MCP, which is the documented way to have an agent open a failed Build, fix the environment configuration, run a test Build, and verify the result before proposing final install and start commands. (Cloud Agent Builds documentation)

What to check before relying on the default

Builds work best when the install command covers everything that can be prepared ahead of time, especially dependencies. Keep the start command for services that must be recreated or refreshed at the beginning of a session. Check that:

• The Build captures the repository state you expect.
• Private-registry access uses team or environment secrets rather than user secrets.
• Docker and long-running services start in the start command when they need fresh processes.
• The last successful Build is healthy before launching an unattended task.
• The dashboard's logs and commit SHA make the agent's starting point easy to audit.
• A feature-branch run starts from the active Build's prepared disk and then checks out your branch, so a branch that changes dependencies needs the install command rerun before you trust a test result.

These checks do not undermine the speedup; they make the prepared environment predictable enough for longer-running work.

Bottom line

Cursor Builds move Cloud Agents from prepare first, act later toward a warm-start workflow. Cursor says the feature makes agents start up to 3x faster at no additional cost, while failed preparations remain isolated and the last successful environment stays in service. There is no longer anything to switch on: Builds are the default path for every environment, so the work is making the install command complete and idempotent, keeping services in start, and setting the staleness threshold your branch cadence needs. (Cursor Builds; Cloud Agent Builds documentation)

Corrections and Updates

August 23, 2026: the default has landed, and there is no longer an opt-in to perform.

Sources

• Cursor, "Cloud agents start 3x faster with builds", August 13, 2026: https://cursor.com/blog/builds (the announcement; source for the up-to-3x figure, the 10x internal boot and 3x time-to-first-token figures, the no-additional-cost statement, the hourly default, and the August 17, 2026 default date, re-read August 23, 2026)
• Cursor, "Cloud Agent Builds" documentation: https://cursor.com/docs/cloud-agent/builds.md (checked August 23, 2026; source for the four Build triggers and the Skipped status, the install/start/terminals split, the Update stale builds toggle and 24-hour default staleness threshold, secret handling, feature-branch behavior, the Builds tab controls, the Cursor Cloud MCP, and the absence of any enable step)
• Cursor, "Cloud Environment Setup" documentation: https://cursor.com/docs/cloud-agent/setup.md (checked August 23, 2026; environment creation ends in a first Build, with no migration step)