{"slug": "stop-running-llm-generated-code-in-your-own-process", "title": "Stop Running LLM-Generated Code in Your Own Process", "summary": "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.", "body_md": "[Cloud & Infra](https://sourcefeed.dev/c/cloud)Article\n\n# Stop Running LLM-Generated Code in Your Own Process\n\nMicroVM sandboxes are now a one-API-call default, and the ephemeral model is already obsolete.\n\n[Ji-ho Choi](https://sourcefeed.dev/u/jiho_choi)\n\nIf 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()`\n\nin 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.\n\nBut 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.\n\n## Why a subprocess was never a boundary\n\nA child process inherits your environment variables unless you scrub them, shares your kernel, and sits inside your network context. One prompt-injected `process.env`\n\ndump 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.\n\nVercel 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.\n\nThe developer experience is the point. This is the entire integration:\n\n``` js\nimport { Sandbox } from '@vercel/sandbox';\n\nconst sandbox = await Sandbox.create({ timeout: 60_000 });\nawait sandbox.writeFiles([\n  { path: 'snippet.js', content: Buffer.from(generatedCode) },\n]);\nconst result = await sandbox.runCommand({ cmd: 'node', args: ['snippet.js'] });\n```\n\nHard timeout, isolated filesystem, no path back to your secrets. Compare that to the audit burden of proving your `spawn()`\n\nwrapper handles every escape vector, and the build-versus-buy question mostly answers itself.\n\n## Ephemeral was a phase, not a principle\n\nHere'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`\n\non 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`\n\n), not the design.\n\nThe 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`\n\non 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.\n\nThe 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`\n\n— 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.\n\n## The practical calculus\n\nWhere 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.\n\nWhere it doesn't: Sandbox runs only in Vercel's `iad1`\n\nregion. 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.\n\nMy 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.\n\nThe 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.\n\n## Sources & further reading\n\n-\n[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 -\n[Vercel Sandbox Documentation](https://vercel.com/docs/sandbox)— vercel.com -\n[Vercel Sandbox Pricing and Limits](https://vercel.com/docs/sandbox/pricing)— vercel.com -\n[Run untrusted code with Vercel Sandbox, now generally available](https://vercel.com/blog/vercel-sandbox-is-now-generally-available)— vercel.com -\n[Automatic persistence now in beta on Vercel Sandbox](https://vercel.com/changelog/vercel-sandbox-persistent-sandboxes-beta)— vercel.com -\n[E2B vs Vercel Sandbox: comparing AI sandbox environments in 2026](https://northflank.com/blog/e2b-vs-vercel-sandbox)— northflank.com\n\n[Ji-ho Choi](https://sourcefeed.dev/u/jiho_choi)· Security & Cloud Editor\n\nJi-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.\n\n## Discussion 0\n\nNo comments yet\n\nBe the first to weigh in.", "url": "https://wpnews.pro/news/stop-running-llm-generated-code-in-your-own-process", "canonical_source": "https://sourcefeed.dev/a/stop-running-llm-generated-code-in-your-own-process", "published_at": "2026-08-09 07:08:34+00:00", "updated_at": "2026-08-09 09:56:45.094176+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "ai-tools", "ai-safety"], "entities": ["Vercel Sandbox", "Firecracker", "E2B", "Modal", "Daytona", "AWS", "Ji-ho Choi"], "alternates": {"html": "https://wpnews.pro/news/stop-running-llm-generated-code-in-your-own-process", "markdown": "https://wpnews.pro/news/stop-running-llm-generated-code-in-your-own-process.md", "text": "https://wpnews.pro/news/stop-running-llm-generated-code-in-your-own-process.txt", "jsonld": "https://wpnews.pro/news/stop-running-llm-generated-code-in-your-own-process.jsonld"}}