Every coding agent eventually needs a place to run the code it just wrote — untrusted, possibly hostile, definitely not something you execute in your own process. The market answered with a wave of "agent sandbox" providers, and this month Vercel's entry, Vercel Sandbox, went generally available. It's worth a look, especially if your app already lives on Vercel.
What it is#
Vercel Sandbox is an ephemeral compute primitive: an API that spins up an isolated Firecracker microVM, runs code in it, and tears it down. It runs on the same infrastructure that powers Vercel's build system, and it's purpose-built to execute untrusted or AI-generated code in short-lived, fully isolated environments. Vercel's own framing — from CEO Guillermo Rauch — is the "EC2 of AI": an API to instantly run AI-generated code, one sandbox per job.
The isolation primitive matters. Firecracker is the microVM technology AWS built for Lambda; a compromised process inside the sandbox is contained by a virtualization boundary, not just a container namespace. For "run whatever the model emitted," that's the boundary you want. (If you're weighing isolation models generally, we went deep on Firecracker vs gVisor vs Kata.)
Who it's for#
The clearest fit is a team already deploying on Vercel that wants agent-generated code to run next to the app without standing up separate sandbox infrastructure — no second vendor, no separate billing relationship, one platform. It's built for AI agents, code-generation products, and developer experimentation where each execution is bursty and short-lived.
The interesting bet isn't the microVM — everyone has one. It's billing by active CPU, which fits how agents actually spend time: mostly idle, occasionally busy.
The pricing is the story#
Most sandbox providers bill per vCPU-hour of wall-clock — you pay while the machine exists, even if the agent is sitting on the result thinking about its next move. Vercel Sandbox uses the Fluid compute model and charges by Active CPU time: you pay $0.128 per active CPU-hour, plus $0.0106 per GB-hr of provisioned memory, $0.15 per GB of network, and $0.60 per million sandbox creations. Idle time between tool calls is cheap.
For agent workloads — which are overwhelmingly idle punctuated by short bursts of execution — that model can undercut per-wall-clock-hour pricing even though the headline CPU rate ($0.128/CPU-hr) is higher than E2B's or Daytona's ~$0.05/vCPU-hr. Run the math on your duty cycle before assuming a provider is cheaper; the rate card and the bill are different documents.
The Hobby tier is genuinely usable for prototyping: 5 CPU-hours, 420 GB-hr of provisioned memory, 20 GB of network bandwidth, and 5,000 sandbox creations per month, free. Resource ceilings scale by plan: up to 4 vCPUs on Hobby, 8 on Pro, 32 on Enterprise, with 2 GB of memory per vCPU throughout.
How to start#
The recommended path is the Sandbox SDK. Link a project, install the package, and create a sandbox from a git repo or from files:
mkdir my-sandbox-app && cd my-sandbox-app
npm init -y
npm i @vercel/sandbox
vercel linkimport { Sandbox } from "@vercel/sandbox";
const sb = await Sandbox.create({
source: { url: "<git url>", type: "git" },
resources: { vcpus: 4 },
});
const res = await sb.runCommand("npm", ["test"]);
console.log(await res.stdout());
await sb.stop(); // ephemeral: don't leave it runningThat's the whole loop — create from a source, run commands, read output, stop. Node.js 22+ on the calling side.
Where it sits#
Vercel Sandbox isn't trying to be the only sandbox you'll ever consider — it's a strong default for one specific reader: the Vercel-native team that wants isolation, active-CPU billing, and no new infra. If cold start is your bottleneck, Daytona still leads (~90ms). If your sandbox needs a GPU — inference or fine-tuning on the sandbox side of the wire — that remains Modal's lane, because it's the only one of the four that attaches a GPU at all. For the full four-way decision, see E2B vs Modal vs Daytona; Vercel Sandbox now slots in as the platform-integrated fourth option.
Pick the sandbox for your duty cycle and your isolation needs, not the feature grid. For a lot of teams shipping AI features on Vercel, the right answer just got one API call closer.
