Vercel Sandbox Persistence Goes GA: What It Means for AI-First Workflows

Vercel Sandbox persistence reached general availability on May 26, 2026. The change: Sandboxes now automatically save and restore filesystem state between sessions, and persistence is on by default. The result: an isolated-execution primitive that was designed for safely running untrusted code (think AI-generated code from v0, Claude Code, or other coding-agent workflows) becomes a durable runtime that AI agents and long-running workflows can rely on across sessions without managing snapshots manually. Vercel also shipped a meaningfully expanded API surface alongside the GA, including Sandbox.getOrCreate, Sandbox.fork, Sandbox.delete, lifecycle hooks (onCreate and onResume), and Tags for multi-tenant tracking.

This post covers what changed, what the new API surface enables, what the storage and pricing model looks like, why this matters specifically for AI-first developer workflows, and where Vercel Sandbox fits relative to the other isolated-execution platforms (Cloudflare Sandboxes, the various Firecracker-based options). For context on Vercel’s broader platform, see our introduction to Vercel.

Where persistence fits in the Sandbox story

Vercel Sandboxes themselves went GA on January 30, 2026 as an ephemeral compute primitive: spin up an isolated execution environment, run code in it, tear it down. The isolation is real (Sandboxes run on Firecracker microVMs, the same KVM-backed isolation primitive AWS Lambda uses) which makes Sandboxes safe to use for untrusted code execution. The original GA scoped the primitive at "run this code in a clean room and throw the clean room away when you’re done."

For AI-first workflows specifically, the ephemeral model has been most of what’s needed. v0 generates a project, runs it inside a Sandbox to verify it builds and behaves, then either deploys the output or returns the result to the developer. Each verification is a fresh execution; the Sandbox can be discarded between runs. That pattern fits the "AI agent generates code, sandbox executes code safely" loop cleanly.

The shape that ephemeral Sandboxes don’t fit is the loop where the agent needs to keep working against persistent state. Running npm install and then losing the entire node_modules directory between sessions is wasteful at best; rebuilding the environment from scratch on every session adds latency to every agent loop iteration and consumes both developer patience and the compute budget. Persistence is the answer to that gap.

The persistence feature itself went into beta earlier in 2026 (after the broader Sandbox GA in January) and reached general availability on May 26, 2026 with persistence flipped to on-by-default. That default matters: developers no longer have to opt into persistence explicitly. Any new Sandbox created without specifying otherwise gets persistent filesystem state.

What persistence actually does

The runtime mechanics are clean. When you create a Sandbox, Vercel automatically captures snapshots of its filesystem state. When the Sandbox’s session ends (whether you explicitly call sandbox.stop() or the session ends through inactivity), the snapshot is durable. When you next interact with the Sandbox (call runCommand(), writeFiles(), or any other operation), Vercel spins a new session up from the most recent snapshot. The filesystem from the previous session reappears intact.

In code, the simplest persistent-Sandbox example from Vercel’s own changelog:

import { Sandbox } from "@vercel/sandbox";

// Filesystem is snapshotted automatically
const sandbox = await Sandbox.create({ name: "my-sandbox" });

await sandbox.runCommand("npm", ["install"]);

await sandbox.stop();

The name parameter gives the Sandbox a durable, customizable identifier you can reference later. Resuming is implicit:

import { Sandbox } from "@vercel/sandbox";

const resumedSandbox = await Sandbox.get({ name: "my-sandbox" });

// Automatically resumes the sandbox from the latest snapshot
await resumedSandbox.runCommand("npm", ["test"]);

The first runCommand call on the resumed Sandbox triggers session-startup, which begins from the most recent snapshot. The developer doesn’t manage the snapshot, doesn’t track which version they’re resuming, doesn’t manually call any "resume" API. It’s invisible plumbing.

For ephemeral workloads, the opt-out path is explicit:

const sandbox = await Sandbox.create({ persistent: false });

// Or update an existing sandbox
await sandbox.update({ persistent: false });

On the CLI, the equivalent is sandbox create --non-persistent. Non-persistent Sandboxes discard their filesystem at session end and don’t accumulate snapshot storage charges.

The expanded API surface

The persistence GA shipped alongside a meaningful expansion of the Sandbox SDK. The pieces worth knowing about:

Sandbox.fork() creates a new Sandbox from the current state of an existing one. The forked Sandbox starts from the parent’s most recent snapshot and evolves independently from there. The use cases are obvious for any workflow that needs branched execution: an agent tries two approaches to the same problem; a test harness needs to verify a change against multiple variants of the project state; a multi-tenant platform spins up per-customer sandboxes from a common base image.

Sandbox.getOrCreate() is the idempotent retrieve-or-create primitive. If a Sandbox with the given name exists, return it. If not, create it. The pattern matters for long-lived agentic workloads where the harness doesn’t necessarily know whether the Sandbox was previously initialized, and where re-initializing redundantly would be wasteful.

Sandbox.delete() is the explicit teardown. Persistence is opt-out, and deleted sandboxes clear their snapshot storage. The combination of automatic persistence and explicit deletion gives developers the right defaults for the common cases (state survives by default, explicit cleanup when you actually want the state gone).

Lifecycle hooks: onCreate and onResume run on first creation and on subsequent resumes respectively, available across create, get, and getOrCreate. They’re the right primitive for environment initialization that needs to happen exactly once (the create hook) or every time the Sandbox wakes up (the resume hook). Setting up environment variables, registering with an external service, refreshing credentials that may have expired during the sleep: these all fit cleanly into the hooks rather than being smeared across the harness code.

Tags are a multi-tenant tracking primitive. You assign custom properties to a Sandbox (user_id, customer_id, agent_session, whatever your platform needs to track) and Vercel surfaces them in the dashboard and APIs. For SaaS platforms running per-customer Sandboxes, this turns the inventory from a flat list into a queryable, attributable resource pool.

Richer sandbox.stop() now returns snapshot metadata alongside active-CPU and network-transfer totals from the session. The metrics are usable for both billing transparency (you can see exactly what your session cost) and for performance debugging (long active-CPU times suggest the workload could be tightened up).

The storage and pricing model

Persistence isn’t free, and it isn’t bundled into compute pricing. Each automatic snapshot consumes snapshot storage, which is billed separately. The storage charge is for the persistent filesystem state itself: anything you wrote into the Sandbox between sessions sits in Vercel’s storage layer until the next session resumes it or until you explicitly delete it.

The pricing line worth holding in your head: you pay for compute when the Sandbox is running, and you pay for storage continuously for any persistent Sandbox that has accumulated snapshot data. The compute charges are familiar serverless economics. The storage charges are the new dimension.

For workloads where the persistent state matters (the agent is working against a real project, the developer wants to resume where they left off), the storage cost is worth it. For workloads where the state doesn’t matter between sessions (one-shot code verification, throwaway prototyping, AI-generated code that runs once and is then deployed elsewhere), opting out via persistent: false is the right move. The non-persistent path matches the pre-GA behavior cost profile.

Vercel’s pricing page documents the snapshot-storage rates specifically; the rate is per gigabyte-month, with the storage measured against actual snapshot data rather than allocated filesystem size. The economics align with the standard cloud-storage pattern: cheap per unit, meaningful in aggregate at scale, manageable through explicit opt-out for workloads that don’t need the durability.

Why this matters for AI-first workflows

The reason persistence is a meaningful upgrade specifically for AI workflows is that agentic loops are state-heavy in ways that ephemeral execution can’t serve well.

An agent that’s working on a refactor task needs to know what files it has already modified, what tests have already passed, what dependencies have already been installed. An agent that’s running a multi-step build needs the intermediate artifacts from earlier steps available to later steps. An agent that’s iterating on a UI needs the dev server, the database, and the test fixtures all in a known state on every iteration.

Pre-persistence, the workaround was to keep the Sandbox session alive across the entire workload (which is expensive and brittle if anything interrupts the session) or to externalize the state to managed storage and re-mount it on each session (which adds complexity and latency to every iteration). Post-persistence, the agent can simply call Sandbox.get({ name }) whenever it needs to resume, and the previous session’s filesystem appears.

The pattern this unlocks most cleanly is the long-running agent that you check in on periodically. A developer hands an agent a large refactor; the agent works for hours across many resumed sessions; each session picks up where the last one left off; the developer reviews progress against the Sandbox’s current state. None of this needed to be impossible before persistence, but doing it cleanly required scaffolding that persistence now removes.

This is also the right primitive for the consumer-facing agent products that pair naturally with Vercel’s AI cloud positioning. v0 is the most visible example: a v0 session that involves multiple iterations on the same generated project now has a natural home for the intermediate state. Vercel’s broader Agent product, which builds on the same primitives, gets the same benefit. For background on the agent-first workflows this primitive serves, our coverage of Google Antigravity covers the equivalent agent-execution story from Google’s side, and our AI agents pillar covers the broader category.

Where Sandbox fits competitively

The isolated-execution-for-AI-agents category has consolidated quickly. The major comparables as of mid-2026:

Cloudflare Sandboxes reached general availability in April 2026 with a similar positioning: isolated execution environments for AI-generated code, oriented toward agents. Cloudflare’s strength is the edge-network footprint and the unmetered-bandwidth pricing model. Vercel’s strength is the developer-experience polish and the deeper integration with the AI cloud product surface (v0, Vercel Agent, AI SDK). For teams already on Cloudflare for hosting, Cloudflare Sandboxes are the natural choice; for teams already on Vercel, Vercel Sandboxes are the natural choice. Cross-platform adoption tends to follow which AI-tooling ecosystem the team is most invested in.

Firecracker-based self-hosted solutions (E2B, Daytona, and the various Kubernetes-on-Firecracker patterns) are the build-it-yourself path. They give maximum control over the execution environment, isolation policy, and cost profile, at the trade-off of operating the infrastructure yourself. For teams with strong platform engineering and specific compliance or cost requirements, self-hosting is viable. For most teams shipping AI-first product features, the managed-Sandbox path is the realistic choice.

Code Interpreter / Advanced Data Analysis surfaces in OpenAI, Anthropic, and Google’s consumer-facing AI products are technically isolated-execution environments too, but they’re designed for the AI-product use case rather than developer-tooling use case. They aren’t a substitute for Sandbox in workflows where the developer’s own code (not just the AI’s outputs) needs to execute against the sandboxed runtime.

The honest framing: Vercel Sandbox with persistence is a strong choice for any team building developer-facing or AI-tooling products on the Vercel stack, and is competitive with Cloudflare Sandboxes on features as of mid-2026. The deciding factor between Vercel and Cloudflare is usually which broader hosting ecosystem the team is already in.

What this means for developers building on Vercel

A few practical takeaways:

• If you’re already using Vercel Sandbox in ephemeral mode and the workloads would benefit from durable state, the migration is essentially free: upgrade the SDK, drop the explicit teardown calls, and let persistence handle the state. The default behavior matches what most agent harnesses actually want.
• If you’re using Sandbox for high-volume ephemeral workloads (one-shot code verification, throwaway prototyping), pass persistent: false on creation. Persistence-by-default would otherwise accumulate snapshot storage charges you don’t want.
• The new Sandbox.fork() primitive is worth designing around. If you’ve been building multi-variant execution patterns by managing separate Sandbox instances, the fork pattern is cleaner: start from a common base, fork into variants for each branch you want to explore.
• The onCreate and onResume lifecycle hooks are the right home for environment initialization. If you’ve been smearing initialization across your harness code, refactoring into hooks makes the create-vs-resume distinction explicit and removes a class of bugs where initialization runs at the wrong time.
• Tags are valuable specifically for multi-tenant platforms. If you’re running per-customer Sandboxes, tag them with the customer identifier on creation; the dashboard and APIs become substantially more useful for both monitoring and billing attribution.
• Watch the snapshot storage line on your invoices for the first few weeks after switching to persistence-by-default. The storage costs build up subtly; explicit Sandbox.delete() calls or automated cleanup of inactive sandboxes prevent surprises.

The deeper takeaway is that Vercel’s positioning of Sandbox as a primitive for AI-first workflows now has the durability story to match. Pre-persistence, recommending Sandbox for serious agent workloads required asterisks (the state story was awkward; the long-running pattern needed external scaffolding). Post-persistence, the recommendation is unqualified for the workload shape Vercel is targeting. That’s a meaningful product upgrade and a real differentiator against the build-it-yourself isolated-execution alternatives.

Frequently Asked Questions