Vercel fixes elastic build machines downgrading after warm Turborepo cache hits

What happened

Vercel has updated its elastic build machines to take Turborepo cache hits into account when deciding whether a build can move to a smaller machine, according to a changelog entry on the Vercel blog. The fix addresses a failure mode where a warm-cache build — one that reused most of its cached task outputs — appeared to need very little CPU and memory, and the sizing logic responded by downgrading the machine assigned to that build pipeline. A later build running against a cold cache would then have to execute every task from scratch on hardware without the resources to finish the job.

With the change, a run that benefits from cache hits no longer counts as evidence that a smaller machine is enough. Vercel says the adjustment applies automatically to every build using elastic build machines, with no configuration changes or opt-ins required, and points readers to its build documentation for further detail.

How the sizing loop went wrong

Turborepo, Vercel's build system for JavaScript and TypeScript monorepos, caches the outputs of tasks such as builds, tests and linting, keyed on the inputs that produced them. When nothing relevant has changed since the previous run, tasks are restored from the cache almost instantly and consume very little compute. When an input does change — a source edit, a dependency bump, an environment variable — the cache entry is invalidated and the task has to execute for real.

Elastic build machines are meant to right-size compute based on what builds actually use. That works well when usage reflects the true cost of the work, but a warm cache temporarily suppresses that cost. The sizing logic was effectively optimising against a best-case measurement rather than a representative one, and then locking in a downgrade that only became visible the next time the cache was cold.

What users need to do

Nothing. According to Vercel, the corrected behaviour shipped automatically for all builds on elastic build machines, so teams already using elastic sizing get it without migrating settings or touching their Turborepo configuration. Teams that had noticed builds struggling after a stretch of fast, cache-heavy runs — particularly around dependency updates or other broad input changes that flush the cache — should no longer see machines shrink in those circumstances.

Why it matters

Caches are supposed to make CI faster and cheaper, not less reliable. This bug was an interaction between two optimisation layers that each behaved as designed: Turborepo reduced measured resource usage, and elastic sizing responded to the reduction. Together they turned a best-case run into a resource shortfall that surfaced later, far from the change that triggered it.

It is also a good illustration of a general pitfall for usage-driven autoscaling. Telemetry that is lowered by caching does not describe the real cost of the underlying work, and capacity decisions based on it will eventually undershoot. For monorepo teams running CI on Vercel, the fix removes a class of confusing, delayed build failures while keeping the cost savings that elastic sizing is meant to deliver.