Stop Running LLM-Generated Code in Your Own Process

Vercel Sandbox now defaults to persistent microVM sandboxes, a shift from the ephemeral model, signaling that stateful isolation is the new standard for running LLM-generated code. The service, which uses Firecracker microVMs with dedicated kernels, offers one-API-call integration and boots in the low hundreds of milliseconds, making it a practical default for agentic applications. This move aligns with competitors like E2B, Modal, and Daytona, all converging on resumable sandboxes to support long-running coding agents.

Cloud & Infra https://sourcefeed.dev/c/cloud Article Stop Running LLM-Generated Code in Your Own Process MicroVM sandboxes are now a one-API-call default, and the ephemeral model is already obsolete. Ji-ho Choi https://sourcefeed.dev/u/jiho choi If you're building anything agentic, you've hit this moment: the model writes a snippet, and now something has to run it. The tempting answer is a child process.spawn in your API route. The correct answer is that the code your model just wrote is untrusted input that happens to be executable, and it should never share a kernel with your app. That argument is now settled, and Vercel Sandbox https://vercel.com/docs/sandbox is the clearest sign of it: microVM-per-execution has gone from exotic infrastructure to a one-API-call default. But the more interesting story is what happened after the industry agreed on the isolation boundary. The "ephemeral sandbox" — spin up, run, wipe, destroy — is already yesterday's mental model. Field notes circulating this week still describe Sandbox as ephemeral-by-design with filesystems wiped on stop. Vercel's own docs quietly disagree: persistence is now the default. That shift says a lot about where agent infrastructure is actually heading. Why a subprocess was never a boundary A child process inherits your environment variables unless you scrub them, shares your kernel, and sits inside your network context. One prompt-injected process.env dump or a curl to your metadata endpoint and your "sandbox" is a credential exfiltration tool. Containers narrow the blast radius but still share the host kernel — namespaces and cgroups are a policy layer, not a boundary, and container escapes are a recurring CVE genre. Vercel Sandbox, like E2B https://e2b.dev , runs each sandbox in its own Firecracker https://firecracker-microvm.github.io/ microVM with a dedicated kernel — the same VMM AWS built for Lambda. Escaping means a hypervisor exploit, a categorically harder problem than a kernel one. Each sandbox gets a private filesystem, its own network namespace with a configurable firewall, and nothing from your app's environment unless you explicitly pass it in. Boot times are in the low hundreds of milliseconds — fast enough that isolation no longer costs you interactivity. The developer experience is the point. This is the entire integration: js import { Sandbox } from '@vercel/sandbox'; const sandbox = await Sandbox.create { timeout: 60 000 } ; await sandbox.writeFiles { path: 'snippet.js', content: Buffer.from generatedCode }, ; const result = await sandbox.runCommand { cmd: 'node', args: 'snippet.js' } ; Hard timeout, isolated filesystem, no path back to your secrets. Compare that to the audit burden of proving your spawn wrapper handles every escape vector, and the build-versus-buy question mostly answers itself. Ephemeral was a phase, not a principle Here's the part that changed under everyone's feet. Since going GA in early 2026, Vercel has made sandboxes persistent by default: when a sandbox stops, the SDK automatically snapshots the filesystem and restores it — installed packages, working tree, all of it — the next time you call runCommand on that named sandbox. There are forks, lifecycle hooks, tags for multi-tenant platforms, and beta persistent drives. Wipe-on-stop is now the opt-out persistent: false , not the design. The reason is obvious once you've built a real agent. One-shot eval — "solve this math problem in Python" — is genuinely ephemeral. But a coding agent that clones a repo, installs dependencies, and iterates across a twenty-minute session cannot afford to re-run npm install on a blank VM every turn. State is the product. Every serious player has converged here: E2B ships 24-hour sessions, Modal https://modal.com offers sandboxes that can hold a GPU, and Daytona https://www.daytona.io built its whole pitch on sub-100ms resumable sandboxes. The trade-off deserves more attention than it's getting. Ephemerality was itself a security control: a compromised sandbox died with its session. A persistent sandbox that gets poisoned — a malicious postinstall script, a tampered .bashrc — resumes poisoned. You've moved the trust problem from "this execution" to "this workspace's history." If you're running genuinely untrusted third-party code rather than your own model's output, opt back out of persistence and eat the setup cost, or pin sandboxes to snapshots you control. The practical calculus Where Vercel lands well: pricing that rounds to zero for the common case. Active CPU is billed at $0.128/hour and only while the CPU is actually working — time blocked on I/O, including waiting on an LLM call, is free. A typical 5-minute, 2-vCPU code-validation run costs about three cents; Hobby accounts get 5 CPU-hours and 5,000 sandbox creations a month at no cost, which covers a lot of prototyping. Timeouts default to 5 minutes and stretch to 24 hours on Pro, with up to 8 vCPUs 32 on Enterprise and 10,000 concurrent sandboxes. Where it doesn't: Sandbox runs only in Vercel's iad1 region. If your users are in Europe or Asia, every keystroke-to-execution round trip crosses an ocean, which matters for interactive playgrounds even if batch agents won't care. There's no bring-your-own-cloud, and per-unit compute runs roughly 2–3x E2B's rates — third-party cost modeling puts Vercel meaningfully above E2B at sustained scale, though Vercel's active-CPU-only billing narrows the gap for I/O-heavy agent workloads. And you're deepening a Vercel dependency, which is either a feature or a liability depending on where the rest of your stack lives. My read: if you're already deploying on Vercel, Sandbox is the obvious default — the OIDC auth story alone no API keys to provision or leak makes it the path of least resistance, and least resistance is exactly what you want between "agent feature idea" and "agent feature shipped." If you're not on Vercel, E2B's open-source core, multi-region footprint, and cheaper compute make it the stronger standalone choice, and Modal owns the niche where the sandbox needs a GPU. The larger point stands regardless of vendor. Running model-generated code in your own process was always negligence with good ergonomics; now the safe version has better ergonomics than the dangerous one, and the excuse is gone. The isolation question is closed. The open question — and the one to watch — is how these platforms handle the tension they've just created between statefulness and safety, because persistent agent workspaces are about to be the biggest pile of semi-trusted mutable state in your architecture. Sources & further reading - Running AI-Generated Code Safely: Field Notes on Vercel Sandbox https://dev.to/ahmed mahmoud360/running-ai-generated-code-safely-field-notes-on-vercel-sandbox-3g4e — dev.to - Vercel Sandbox Documentation https://vercel.com/docs/sandbox — vercel.com - Vercel Sandbox Pricing and Limits https://vercel.com/docs/sandbox/pricing — vercel.com - Run untrusted code with Vercel Sandbox, now generally available https://vercel.com/blog/vercel-sandbox-is-now-generally-available — vercel.com - Automatic persistence now in beta on Vercel Sandbox https://vercel.com/changelog/vercel-sandbox-persistent-sandboxes-beta — vercel.com - E2B vs Vercel Sandbox: comparing AI sandbox environments in 2026 https://northflank.com/blog/e2b-vs-vercel-sandbox — northflank.com Ji-ho Choi https://sourcefeed.dev/u/jiho choi · Security & Cloud Editor Ji-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept. Discussion 0 No comments yet Be the first to weigh in.