Latest in AI
Vercel Sandbox Drives Get Faster Startup: What the 2.4x Claim Measures
The update reduces the wait to attach persistent agent workspaces, but it does not make every part of an agent run faster.
Vercel announced faster startup for Sandboxes using Drives on November 2. Its reported median creation time fell from 1.7 seconds to 0.7 seconds, with no SDK upgrade, configuration change or pricing change. The improvement affects a recurring delay in agents that resume work from persistent files.
What became faster
The release announcement measures creation of a sandbox with Drives from a Vercel image. Its median improves by about 2.4 times, while the 95th-percentile time falls from 2.2 seconds to 1.6 seconds.
| Startup measurement | Before | After |
|---|---|---|
| Median | 1.7 seconds | 0.7 seconds |
| 95th percentile | 2.2 seconds | 1.6 seconds |
These are Vercel's measurements, not an independent benchmark. The smaller improvement at the 95th percentile is worth noticing: the headline ratio describes the median, rather than every startup or the slowest requests.
The change applies automatically to sandboxes that use Drives. It does not establish a similar improvement in model inference, package installation or the time taken by the code running inside the sandbox.
Why Drives matter for agents
According to the Drives documentation, a drive is a persistent directory that can be mounted into a sandbox. Files remain after that sandbox stops, allowing a later run to reuse the workspace, dependencies or accumulated outputs.
A sandbox snapshot serves a different purpose: it captures an environment's filesystem. Drives can be used alongside snapshots, separating a reusable starting environment from files that continue changing between runs.
There are constraints. A drive allows one read-write mount at a time. Read-only snapshots support sharing with other sandboxes, and a sandbox can mount up to four drives. Faster startup does not remove the need to design how several agents read and update shared work.
Where one second makes a difference
Consider an assistant that wakes, opens a workspace, runs a short check and stops. For that kind of task, a second of setup can be a meaningful part of the visible wait. In a long-running build or a multi-minute model task, the same saving is much less important.
The useful evaluation is therefore the whole workflow, with startup measured separately. Teams should compare their typical short tasks and slower tail requests rather than multiply a complete agent runtime by the advertised speedup.
Persistent storage also changes what a resumed agent needs to reconstruct. Reusing files can avoid repeated preparation, but stale dependencies and concurrent writes still need handling. Lower startup latency makes these workflows more responsive; reliable state management makes them useful.
I’m Paras. I work at the intersection of AI, engineering and distribution.
I help technical teams explain AI infrastructure and developer releases through clear stories grounded in what actually changes.