On June 30, 2026, the public vercel/sandbox repository showed sandbox@3.3.1 as its latest release. A few days earlier, Vercel's Sandbox docs had been refreshed with the current runtime, pricing, snapshot, and isolation details.
That timing matters. Agent products keep drifting from "suggest code" toward "run the code, inspect the output, and keep going." The uncomfortable part is not the model call. It is the execution surface.
I read Vercel Sandbox as a very direct answer to that problem: give the agent a Linux machine, but make it disposable, scoped, metered, and observable enough that a product team can reason about it.
The useful mental model is not "serverless function." It is "temporary dev machine with a blast radius."
1. The boundary: a Firecracker microVM
The core piece is isolation. Vercel describes Sandbox as a way to run untrusted or user-generated code, and the docs say each sandbox runs in a Firecracker microVM with its own filesystem and network boundary.
That is the right abstraction for AI code execution. A function is too cramped for many agent tasks. A full shared VM is too dangerous. A microVM gives you a place to run package installs, shell commands, dev servers, build tools, and test suites while keeping the production app out of reach.
It also changes what I would allow an agent to do. I would still restrict credentials hard, but I would be much more comfortable letting a sandbox install dependencies, compile a branch, or start a preview server than letting that happen on the same host that runs the app.
2. The runtime: boring Linux, current Node
The runtime stack is intentionally ordinary. The current docs list node26, node24, node22, and python3.13, with node24 as the default when no runtime is specified. The base system is Amazon Linux 2023, and user code runs as vercel-sandbox in /vercel/sandbox.
That sounds mundane, but mundane is the feature. Agent workflows fail in weird ways when the environment is novel. A current Node runtime, npm, pnpm, git, tar, unzip, openssl, and the usual system tools are exactly what most web projects need before the interesting work starts.
The docs also note sudo access. That is powerful and risky, but it is useful for real workloads. Some tasks need a system package, a container runtime, a VPN client, or a FUSE filesystem. I would not expose that by default to every user prompt, but I do want the platform primitive to support it.
3. The API shape: create, run, read, stop
The happy path is small enough to understand. Link a Vercel project, pull environment variables, install @vercel/sandbox, create a sandbox, run a command, and read stdout.
import { config } from 'dotenv';
import { Sandbox } from '@vercel/sandbox';
config({ path: '.env.local' });
const sandbox = await Sandbox.create({
runtime: 'node24',
timeout: 5 * 60 * 1000,
});
const result = await sandbox.runCommand('node', ['--version']);
console.log(await result.stdout());
await sandbox.stop();
That is the whole product hook. The agent can propose a command, the application can decide whether to allow it, and the sandbox becomes the execution target.
I would still put a policy layer in front of this. For example, allow pnpm test or npm run build, require review for network scanners, and deny commands that try to print environment variables. The primitive gives you a place to run code. It does not replace judgment.
4. The lifecycle: persistence by default, snapshots when needed
One detail I like is that persistence is not bolted on as an afterthought. The quickstart says sandboxes stop after five minutes by default and are persistent by default. The snapshot docs explain the flow: when a persistent session stops, Vercel captures filesystem state so the next session can resume from that point.
That solves a real agent UX problem. Nobody wants every loop to reinstall the same dependencies. For code review agents, playgrounds, or user-generated app builders, a snapshot after setup can turn a slow repeated task into a faster loop.
There is a tradeoff. Persistent state can hide drift. If the sandbox gets into a bad state, the next run inherits the bad state. My preference would be named environments for long-lived work, plus non-persistent sandboxes for one-off checks where clean-room behavior matters.
5. The cost model: cheap tests can still become expensive
The pricing page is more interesting than it looks. Hobby includes 5 active CPU hours per month, 420 GB-hours of provisioned memory, 5,000 creations, 20 GB data transfer, and 15 GB lifetime storage. Pro pricing lists active CPU at $0.128 per hour, provisioned memory at $0.0212 per GB-hour, creations at $0.60 per million, data transfer at $0.15 per GB, and storage at $0.08 per GB-month.
Vercel also publishes example costs: an AI code validation run of 5 minutes on 2 vCPUs and 4 GB memory is estimated around $0.03, while a 30 minute build and test run on 4 vCPUs and 8 GB memory is around $0.34. Those are not scary numbers individually.
They become scary when an agent retries blindly. The most important product control is not the price per sandbox. It is the retry budget, timeout, and concurrency limit. A bad loop that spawns 100 builds is still a bad loop.
6. The product fit: not every agent needs this
I would reach for Sandbox when the product needs execution, not just generation.
Good fits:
- AI coding tools that run tests before suggesting a patch.
- Browser-based playgrounds for generated apps.
- Internal tools that validate user-submitted scripts.
- Education products that run code in isolated lessons.
- CI-like preview checks where startup speed matters more than a full build farm.
Bad fits:
- Pure chat assistants that never execute code.
- Deterministic background jobs that already run safely in normal functions.
- Long-running production services that need stable infrastructure, not throwaway machines.
- Anything that requires secrets the agent should not even be near.
The boundary is simple: if the task needs a shell, a filesystem, dependency installation, and a preview surface, Sandbox starts to make sense. If it only needs an API call, use a function.
7. The caution: isolation is not permission
The repo and docs make the primitive look approachable, which is good. The danger is treating a sandbox as a policy engine. It is not.
I would still design the application around least privilege. Pass short-lived credentials. Scope network access. Log commands. Separate user workspaces. Cap runtime. Stop sandboxes promptly. Store snapshots intentionally. Make destructive actions explicit.
The better the sandbox gets, the more tempting it becomes to hand it broad authority. That is exactly when the product layer has to stay boring.
The takeaway
Vercel Sandbox feels like part of a broader shift in web infrastructure: agents need somewhere to act, not just somewhere to think. The teams that benefit first will be the ones that treat execution as a product surface with budgets, policies, and observability, instead of a hidden helper process behind the chat box.