Cursor Builds: your agent's cold start is a cost line

Nobody budgets for the ninety seconds an agent spends running npm install. Cursor just made that number visible by removing it. On August 13 the company shipped Builds for Cloud Agents — pre-baked snapshots of your dev environment that agents boot into directly, so the clone-and-install work happens before the run starts rather than inside it. The feature is worth reading less as a Cursor announcement and more as a statement about where agent cost actually accumulates.

What actually happened

Per Cursor's changelog, a Build is a bootable snapshot created from your base image with repositories already cloned at their default branch and install commands already executed. Agents start from that snapshot instead of a cold container. Cursor reports internal environments booting 10x faster with 3x faster time to first token, and says Builds are included with Cloud Agents at no additional cost.

The mechanics matter more than the multiplier. Per Cursor's docs, Builds preserve disk state — installed dependencies and generated artifacts — but not running processes or in-memory caches. They regenerate on a schedule, when environment config or secrets change, on manual request, or when a setup agent asks for one. Feature branches check out after the Build boots, reusing the prepared dependency tree rather than reinstalling it. A staleness threshold, 24 hours by default, controls when an agent pulls fresher code; set it to zero and you always get HEAD at the price of a slower start.

One documented requirement is the real constraint: install commands must be complete and idempotent, because they run repeatedly across rebuilds. An install step that quietly depends on a leftover file or a one-time manual action will produce a snapshot that works once and rots.

Why the cold start is a cost line for your business

Agent economics get discussed in tokens, which hides half the bill. A cloud agent waiting on a dependency install is consuming a billed compute minute, holding a slot in whatever concurrency cap you're paying for, and — if your loop polls or retries around a slow environment — burning tokens on nothing. Multiply by every run in a day and setup becomes a standing line item that never shows up in a per-task token report.

The generalizable move has nothing to do with Cursor: stop rebuilding state your agent didn't change. Snapshot the environment, not the task. That's a boring container practice — prebuilt images, warm pools, layer caching — that agent runners largely skipped because early agent work was interactive and rare. It isn't rare anymore.

Two things to check on your own setup this week. First, measure it: log time-to-first-useful-action separately from total run time. If setup is a third of your wall clock, you have a caching problem, not a model problem. Second, audit idempotency. Any setup script that can only run on a clean box is a snapshot you can't safely reuse, and that's the actual blocker for most teams — not the tooling.

The vendor-agnostic version of this is the version worth building. Warm environments, deterministic setup, and a runner you can point at any model keep the savings when you swap the model underneath.

Sources: Cursor changelog, Cursor Cloud Agent Builds docs.