# Stop Running LLM-Generated Code in Your Own Process > Source: > Published: 2026-08-09 07:08:34+00:00 [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.