# Cloud agents start 3x faster with builds

Source: [Cursor](https://cursor.com/blog/builds)  
Feed7 permalink: https://feed7.dev/p/builds-1x27f44  
Published: 2026-08-13T12:00:00.000Z  
Trust: Official Source (official_source)

## Why Included

Cursor Cloud Agents can start from continuously prepared environment snapshots instead of reinstalling each session. Internal time to first token improved 3x, with failed builds falling back to the last good state.

## Source Summary

Cursor’s new **builds** continuously prepare cloud-agent environments with repositories, dependencies, and install scripts already completed. Internally, environments booted **10x faster** and time to first token improved **3x**.

## Practical Implication

Builders should move deterministic setup into the install command, keep session-fresh services in the start command, and use team or environment secrets for private registries. Agent runs can be traced to exact builds and commit SHAs.

## Agent-Ready Context

Cursor’s new **builds** continuously prepare cloud-agent environments with repositories, dependencies, and install scripts already completed. Internally, environments booted **10x faster** and time to first token improved **3x**.

Builders should move deterministic setup into the install command, keep session-fresh services in the start command, and use team or environment secrets for private registries. Agent runs can be traced to exact builds and commit SHAs.

The gains are Cursor’s internal measurements, and user results will depend on repository setup. Builds run hourly by default; failed builds are rejected, leaving agents on the last working snapshot, which may be older than the default branch.

## Connected Context

Feed7 judgment across 461 accumulated Signals:

This makes environment preparation a first-class latency and reproducibility mechanism for cloud agents: deterministic setup moves into continuously refreshed snapshots, while runtime-only services remain session-fresh. It reinforces snapshot-based infrastructure patterns and adds commit-level build traceability, but introduces explicit staleness risk when refreshes fail and agents remain on the last valid image.

- [Scaling Managed Agents: Decoupling the brain from the hands](https://feed7.dev/p/managed-agents-00zpz67) — Both reduce startup latency by separating agent reasoning from replaceable prepared environments; Cursor adds continuous repository-specific builds and commit attribution to that architecture.
- [From fork() to Fleet: Designing an Agent Sandbox Cloud — Abhishek Bhardwaj, OpenAI](https://feed7.dev/p/from-fork-to-fleet-designing-an-agent-sandbox-cloud-abhishek-bhardwaj-op-0np9ki3) — Cursor’s prepared builds implement the candidate’s snapshot principle for faster placement and recovery, while exposing failed-refresh staleness as an operational consequence.
- [Agent Runs now available in the Vercel MCP and CLI](https://feed7.dev/p/agent-runs-vercel-mcp-cli-06cfo04) — Exact build and commit identifiers complement run-level reasoning and tool traces, making failures attributable to both agent behavior and the environment it executed in.
- [Give every agent in Herdr its own Vercel Sandbox](https://feed7.dev/p/give-every-agent-in-herdr-its-own-vercel-sandbox-1p4i553) — Prepared environments improve startup inside the per-agent sandbox model, but do not replace its isolation and reviewable-output trust boundary.

## Context Map

- Layer: infra
- Domains: coding
- Topics: cloud-agents, sandboxing, observability

## Uncertainty

- The gains are Cursor’s internal measurements, and user results will depend on repository setup. Builds run hourly by default; failed builds are rejected, leaving agents on the last working snapshot, which may be older than the default branch.

## Agent Instruction

Use this item as source-backed context. Do not invent claims beyond the linked source. If this item conflicts with another source, call out the conflict.