Vercel Vercel Sandbox persistence reaches GA, two months after beta
Sandbox persistence shipped to general availability on May 26, with filesystem state surviving across stops and restarts by default. The release closes a gap that pushed agent and voice workloads toward custom infrastructure.
Vercel marked Sandbox persistence as generally available on May 26, two months after the beta release in late March. Persistence is on by default, filesystem state is automatically snapshotted when a sandbox stops, and a fresh session can resume from the prior snapshot via the same named handle. The shipping detail that matters: developers stop managing snapshot lifecycle by hand.
What changed
The API surface that ships with GA is short and worth knowing. A
Sandbox.create() call now opts a sandbox into persistence by
default. A Sandbox.get() call retrieves a stopped sandbox by its
name and resumes it automatically. Sandbox.update() toggles
persistence on or off after creation, and fork(), getOrCreate(),
delete() round out the lifecycle methods. Two new hooks,
onCreate and onResume, give the application a place to run
startup or rehydration logic without wrapping everything in custom
state management.
Snapshot storage is billed separately from compute. Developers running
ephemeral workloads can pass persistent: false at creation time to
skip the snapshot cost. The post stops short of publishing per-GB
storage rates.
For working developers, the practical change is that a long-running agent or voice assistant no longer needs an external database or volume to keep its working directory alive across interruptions. The sandbox itself is the durable surface, and the application code stays short.
Why the timing matters
Vercel has been building toward this point in stages through 2026. Open Agents shipped in April with a programming model for background AI coding workflows that explicitly assumed durable execution. The durable-execution blog post earlier this year framed the architectural argument: every interaction triggers a workflow that can span multiple steps and persist over time, and resumable sessions are a primitive, not an add-on. Sandbox persistence reaching GA closes the gap between that programming model and the runtime that hosts it.
The competitive context is sharper than it looks. Cloudflare shipped Claude Managed Agents on May 19 paired with Durable Objects and the edge data layer, putting Anthropic’s agent runtime on a platform with its own persistence primitives. Vercel’s answer is to keep the primitives inside the sandbox itself, so an agent that runs on Vercel does not need to learn a separate durable-state system to survive a restart.
The bet appears to be that the simplest path to a working long-lived agent should be a single primitive that already feels like the filesystem the developer was using anyway. If that bet lands, the friction of standing up an agent on Vercel drops below the friction of standing one up on a generic VM.
What’s worth watching
The next 90 days will surface whether persistence behaves like a production primitive or like a beta feature with a GA label. Three signals:
- Cold-start time on resume. The post does not commit to a SLA, and agent workloads are sensitive to the difference between a sub-second wake and a multi-second cold start
- Cost. Snapshot storage billed separately from compute means long-lived sandboxes will accrue a steady bill even when idle. Field reports on monthly cost for non-trivial agent fleets will define whether persistence is a default or an opt-in for cost-sensitive teams
- Failure modes. Forking, deleting, and the interaction between
fork()andonResumeare easy to get wrong in production. The first detailed post-mortem from a team running agents at scale will read better than any marketing post
The strategic frame: Vercel is competing for the agent runtime layer on the same week Cloudflare and Google are. The fight is no longer about who has the best frontend hosting, it is about who owns the durable surface an agent runs on.