Evaluating Managed Sandbox Platforms for Agent Developers

The infrastructure decision that matters most for agent developers right now isn't which large language model to call. It's what runtime holds the agent's code while it executes. Most teams get this backwards: they pick a sandbox platform the way they'd pick a cloud region, on price and brand, and only find out which dimension actually mattered once something breaks in production. Isolation strength, cold-start speed, session persistence, SDK fit, and deployment control: no platform leads on all five, and the platforms that claim otherwise are usually hiding the tradeoff in fine print. The honest exercise isn't ranking platforms. It's figuring out which of those five dimensions breaks the product first if the choice goes wrong, then picking the platform that protects that one, and refusing to pay for strength in dimensions that don't matter to the workload at hand.

Why does this keep tripping people up? The market rewarded speed over rigor for a while, and now the bill is coming due. Over 80% of AI projects never reach production, and a lot of that gap traces back to the runtime layer buckling under real workload rather than the model underperforming. Gartner projects 40% of agentic AI projects get canceled by 2027 over cost overruns, unclear payoff, or missing risk controls, and the sandbox layer sits at the center of all three. Cursor alone reportedly produces close to a billion lines of accepted code a day. At that scale, manual review stops being a workflow option. Isolated execution becomes the thing standing between a working product and a security incident, not a nice-to-have bolted on afterward.

What agents actually demand from a runtime that generic infrastructure cannot provide

Agents don't just answer questions. They write code and run it, install packages, clone repos, poke around a filesystem, spin up dev servers, and generally act like a developer with a terminal open. That's a different demand than serving an API response, and it assumes something most infrastructure was never built to offer: a full, controllable compute surface that stays up for as long as the task actually takes, not as long as a request-response cycle allows.

The standard serverless model runs into a wall here, and it's worth being precise about why. Standard serverless functions impose strict execution time limits, typically measured in minutes. Those aren't arbitrary numbers picked to annoy developers; they fall out of a synchronous HTTP model, where a connection has to stay open the entire time work happens. Agent tasks don't fit that shape. A coding agent might need to install a large dependency tree, run a test suite, wait on a slow build, then pick back up an hour later once a human reviews a diff. Force that into a fifteen-minute window and the problem doesn't disappear. It just hides behind retry logic until something times out at the worst possible moment.

Perpetual execution is the answer several platforms have landed on: the agent runs inside a sandbox independent of any client connection. Send it a task, disconnect, come back hours later, and it picks up exactly where it left off. No re-provisioning, no lost state. That architectural shift, more than any SDK feature or pricing page, is what separates a runtime built for agents from a serverless function stretched past its design. Teams that keep trying to duct-tape long-running agent behavior onto Lambda or Vercel functions are fighting the platform's own architecture, and the retry logic they build to paper over that fight is itself a cost center nobody budgeted for.

Cost curves punish teams that miss this. One documented case showed a mid-sized team's infrastructure spend jump from $5,000 a month in prototyping to $50,000 a month in staging, a tenfold increase driven largely by unoptimized retrieval queries pulling far more context into the model than the task needed. That's not a usage-volume story. It's an architecture story, and it's exactly the failure mode a well-chosen sandbox layer should catch before it reaches production.

The isolation technology stack and why it is not a single checkbox

Isolation sounds like one feature until you look at what's actually running underneath it. Then it splits into three tiers, and the gaps between them are where the real risk lives. Most teams shop for a single isolation number the way they'd shop for a horsepower rating, and that instinct is the wrong one: the tier is the floor, not the whole building, and treating it as the whole building is exactly how a team ends up with a spec-sheet-strong platform and a real-world breach.

MicroVMs, the Firecracker and Kata Containers approach, give each workload its own kernel. A vulnerability inside one sandbox stays inside that sandbox; there's no shared kernel to exploit across to another tenant. Firecracker boots a microVM in under 125 milliseconds, and a single host can spin up as many as 150 of them per second, numbers that used to sound implausible for hardware-level isolation and now read as table stakes.

gVisor takes a different approach: it intercepts system calls in user space, cutting the kernel attack surface without giving every workload a fully separate kernel. Lighter than a microVM, faster to start, but the boundary it draws is softer. Plain container-level isolation sits at the bottom, sharing a kernel across tenants. It's the cheapest and fastest option on paper, and it's the wrong tier for genuinely untrusted, AI-generated code. One kernel exploit exposes every tenant on that host, and no amount of speed makes that an acceptable trade for a team running code it didn't write.

Strong compute isolation at the bottom guarantees nothing about the policy sitting above it, and that gap is where teams actually get burned. Security research from BeyondTrust on AWS AgentCore found that Firecracker's compute isolation held up exactly as designed. The failure sat one layer up: a network policy meant to block all external access still let outbound DNS A and AAAA queries through. Researchers used that gap to build a command-and-control channel over DNS, then rode the code interpreter's IAM role straight into S3 buckets holding PII and credentials. AWS initially treated the DNS behavior as intended functionality before shipping a fix for the tunneling issue in April 2026.

That case reframes the whole evaluation, and it should embarrass anyone who still leads a vendor conversation with "what isolation technology do you use." The better questions are what network egress policy sits on top of that isolation, what the IAM scope actually allows, and what happens the moment code tries to tunnel out. A microVM with a leaky egress policy can end up less safe in practice than a tightly configured container, even though the microVM reads stronger on a spec sheet. Buyers who stop at the isolation tier and never check the egress rules are grading the wrong test, and they usually don't find out until DNS logs surface something they can't explain.

The threat model is real and spans multiple vendors. CVE-2025-34291, found in Langflow, let attackers bypass authentication and execute arbitrary Python. Underneath all of it sits a subtler problem: LLM-generated patches introduce new security vulnerabilities in roughly 9.5% of cases, even while fixing the bug they were meant to fix. That number alone argues for treating all agent-generated code as potentially hostile by default, not just the code that trips an obvious red flag.

For any team where a wrong isolation call means a compliance failure or a breach, the checklist isn't "is isolation present." It's which layer it sits at, and what the policy surface looks like above it.

Session persistence and cold-start speed as a paired tradeoff, not independent sliders

These two get evaluated separately more often than they should, and that habit produces bad decisions, because the two pull against each other by design. Treating them as independent sliders is the second place teams go wrong, right after underrating egress policy. Any vendor pitch that claims a platform nails both without a real tradeoff underneath deserves a follow-up question before anyone signs.

Ephemeral sandboxes make sense for isolated code execution, one-off analysis, quick tests, anything where starting clean every time is a feature. Nothing carries over because nothing needs to. Stateful environments solve a different problem: coding agents, multi-step research, anything where installed packages or intermediate files need to survive from one call to the next. Lose that state and the agent starts from zero every time, which defeats the point of a long-running task in the first place.

The tension is structural, not a vendor failing to try hard enough. MicroVMs carry more startup weight because they're providing hardware-level isolation closer to a full virtual machine. Containers start faster because they share a kernel that's already running. Faster starts and stronger isolation don't naturally sit at the same end of the spectrum, so most platforms lean toward one and try to make up for the other with engineering.

Snapshot, pause, and resume mechanics are the practical workaround, giving a platform something close to a warm start without fully re-provisioning. What gets captured in that snapshot varies more than most teams check for. Some platforms snapshot just the filesystem, cheap and fast. Others aim for a more complete resume, capturing additional state beyond the filesystem. Some platforms are exploring deeper snapshot capabilities, though those efforts remain early-stage and not something to plan a roadmap around yet.

Session duration caps trace back to that same synchronous HTTP model, and working around a tight cap usually means building polling logic or reconnect handling on top of the platform, engineering cost that compounds once it's running at scale. Persistent volumes that live outside any single sandbox and mount across multiple environments solve an adjacent but separate problem: sharing a large dataset or dependency set without copying it fresh into every new environment.

So the real question for any team whose failure mode is losing agent state mid-task isn't "what's the max session duration." It's what exactly gets kept on pause, how long resume actually takes, and whether paused state sticks around or quietly times out.

Platform profiles: what each option actually delivers against the five dimensions

Northflank runs Kata Containers with Cloud Hypervisor, Firecracker, and gVisor side by side, letting teams choose isolation tier rather than getting locked into one. Cold-start figures are unpublished in available sources, so treat that as unannounced rather than inherently slow. Session duration is unlimited, and the platform takes any OCI container image rather than an SDK-defined format, which matters for teams with an existing registry they don't want to rebuild around a proprietary spec. Its real differentiator is bring-your-own-cloud deployment: Northflank runs inside a team's own AWS, GCP, Azure, Oracle, CoreWeave, Civo, or Nebius account while still handling orchestration, which matters a great deal for regulated industries where data residency is a hard requirement. It is a full platform with managed databases, API hosting, and background workers built in, extending well beyond sandboxing alone. It reports processing over 2 million isolated workloads a month, with GPU options extending up through H100, H200, and B200. Best fit: enterprise teams that need BYOC, more than one isolation tier on the table, or a platform that does more than run sandboxes.

One platform in the field reports a median cold start of 78 milliseconds as of January 2026, sessions running up to 24 hours on its Pro tier, and paused sandboxes held indefinitely with no automatic expiration. Pausing costs roughly 4 seconds per gigabyte of RAM, resuming takes about a second, and both filesystem and memory state get captured in that snapshot. Pricing runs $0.000014 per vCPU-second ($0.0504 per vCPU-hour) and $0.0000045 per gibibyte-second ($0.0162 per GiB-hour), with a free tier offering a one-time $100 in credits, 1-hour sessions, and up to 20 concurrent sandboxes. The $150-a-month Pro plan stretches sessions to 24 hours and concurrency to 100, expandable to 1,100. Its Python and JavaScript SDKs are built specifically for agent integration, with a Jupyter-based code interpreter ready out of the box, and integrations span Perplexity, Hugging Face, Groq, and Manus. The gap: no GPU support, and that 24-hour session cap forces workarounds for anything longer-running. Best fit: teams that want strong microVM isolation and a clean AI-first SDK, and don't need GPU access or sessions past a day.

A different platform leans hard into GPU breadth, confirming support across T4, L4, A10, L40S, A100 variants, RTX PRO 6000, H100, H200, and B200, with no quotas or reservations in the way, and concurrency scaling to very high simultaneous session counts. Cold starts are engineered to be fast, with Memory Snapshots (currently in alpha) trimming initialization-heavy startups further, and Memory Snapshots remaining in that same alpha bucket. Sessions run configurable up to 24 hours, with longer-running workloads requiring workarounds at that boundary. The constraint: it only takes SDK-defined images, not arbitrary OCI containers, a real limitation for teams with container infrastructure already built, and it's Python-centric, with JavaScript and Go SDKs available but clearly secondary. Deployment is managed-only, no BYOC, no on-prem, though it does carry SOC 2 Type II certification and HIPAA support on Enterprise plans through a BAA. It reports over 10,000 teams in production, including Lovable, Quora, Ramp, and Suno, running millions of untrusted code snippets daily. Best fit: teams running GPU-heavy workloads, inference, fine-tuning, compute-intensive analysis, where Python-first tooling and managed-only deployment aren't dealbreakers.

Another platform's standout number is cold-start speed: sub-90 milliseconds, the fastest confirmed figure among the platforms profiled here. Its sandboxes are fully stateful: filesystem, environment variables, and process memory all persist across interactions, and snapshots capture the OS, installed packages, dependencies, and configuration, so an agent starts from a fully prepared environment instead of a blank one. Persistent volumes can be mounted across multiple sandboxes at once. It supports Linux and Windows virtual desktops, with macOS desktop support in private alpha, relevant for any team building computer-use agents that need a graphical environment rather than just a terminal. SDK integrations cover Mastra, the OpenAI Agents SDK, LangChain, LangGraph, and the Vercel AI SDK, along with several coding-agent systems, and it ships built-in LSP support, useful for serious code editing. Deployment is open-source and Docker-native, so teams bring an existing stack without rewriting it, with customer-managed compute available in a team's own cloud and SOC 2, HIPAA, and GDPR compliance in place.

The one gap worth flagging, and it's a real one: it defaults to container-level isolation, so any team with a strict microVM requirement has to explicitly opt into Kata, then go verify the network egress policy actually matches that stronger tier. That is the exact lesson from the AgentCore case above, a lesson that applies across vendors, and skipping that verification step is precisely how a team ends up with the AgentCore outcome under a different logo. Best fit: teams where cold-start speed is the dimension a wrong call would break, interactive agents, high-concurrency orchestration, particularly where long-running stateful sessions and enterprise compliance both matter.

Together Code Sandbox uses VM-style isolation with snapshot resume landing around 500 milliseconds. Specific per-unit pricing isn't confirmed in available sources, though it's described as VM-style pricing, and deployment is managed-only. It suits teams already working inside the Together AI ecosystem, where the integration story matters more than a standalone comparison would suggest.

Vercel Sandbox runs on Firecracker microVMs, giving it hardware-level isolation, but its session window runs from 45 minutes up to 5 hours, the tightest hard cap among every platform profiled here. That is an architectural fact of the platform, and any agent workflow running longer than that window needs a workaround built in from day one. Deployment is managed-only. Best fit: teams already building inside the Vercel ecosystem, running short agent tasks that comfortably fit that boundary. Teams that outgrow that window and try to force it anyway are the ones who show up in the next round of postmortems about agents losing state mid-task.

Lined up against each other, the pattern holds: nobody wins on all five dimensions, and the platforms leading on GPU breadth tend to trail on deployment flexibility, while the ones offering the widest isolation choice don't always publish the cold-start numbers a latency-sensitive team wants to see first. That reflects what this kind of infrastructure actually asks for: tradeoffs, made on purpose, that only make sense once a team knows which of the five dimensions its own product can least afford to get wrong. Pick the platform that protects that one, and treat everything else as a number worth knowing but not the number that decides it. Anyone still shopping on price and brand after reading this far is welcome to, but they should at least know which of the five they're gambling with.