Best AI Agent Code Sandboxes 2026

The best AI agent code sandbox in 2026 is the smallest trustworthy boundary that matches the job: Vercel Run SDK for approved in-app tools, E2B for a general remote Linux microVM, and Vercel Sandbox for Vercel-native agents that need an operating system. Perplexity SPACE adds a self-hosted option for engineers prepared to operate that boundary themselves.

The short answer: three winners for three different jobs

The new default is not “send every generated program to a remote machine.” Vercel Run SDK gives agent-written JavaScript and TypeScript a fresh QuickJS context with no ambient Node.js, filesystem, module, environment-variable, or network access. Your application exposes only the host functions the program may call. If the work is “list invoices, filter them, request approval, then issue a refund,” that narrower boundary can remove an entire remote-sandbox line from the architecture.

It does not replace a machine. Choose E2B when the agent must clone a repository, install arbitrary packages, compile code, or work in any Linux-compatible language. Choose Vercel Sandbox when those same OS-level jobs already sit beside Vercel Functions, the AI SDK, or Claude Managed Agents. The decision flips on one question: does generated code need an operating system, or merely permissioned tools?

Prices and product claims below were verified against primary pages on October 23, 2026. Usage rates exclude model tokens and any external database, API, network, or observability charges unless stated.

Watched option: Google Agent Compute Engine

Since October 22, 2026, Google has announced Agent Compute Engine (ACE), the service it says already powers Gemini as an agent for work tasks. Google describes a hardware-isolated Cloud Hypervisor microVM per agent, its own guest kernel and root access, Hyperdisk persistence, checkpoint/restore, and service credentials injected outside the guest. Customer preview is “in the coming months.” The post publishes no price and offers an interest form rather than open-preview access, so ACE stays outside the ranking. A builder choosing a runtime today should keep using an available option. Google's announcement.

Run it yourself: Agent Substrate, NVIDIA OpenShell, and OpenSandbox

These belong in a short self-hosted evaluation list alongside SPACE. Choose by the infrastructure you want to own: Kubernetes scheduling, agent access policy, or a common sandbox API. Each is open source under Apache-2.0; you still fund the hosts, storage, networking, and operations.

• Agent Substrate is Google's Kubernetes-native execution runtime, with local and Google Kubernetes Engine (GKE) setup paths. It snapshots idle agents and restores them onto a pool of workers, using gVisor or Cloud Hypervisor microVM backends. Evaluate it when you already operate Kubernetes and need per-agent identity, external credential injection, and stateful scheduling. Its repository explicitly says pre-1.0, with no backward-compatibility guarantee. Select the microVM backend when your requirement is hardware isolation; gVisor is a different boundary.
• NVIDIA OpenShell is a self-hosted, policy-enforced agent runtime. It controls filesystem access, system calls, and outbound connections, and adds real credentials only to approved requests outside the workload. Evaluate it when enforcing what an existing agent may touch is the main job. You operate its gateway and chosen compute backend, and the default minimal Ubuntu image has no agent preinstalled. NVIDIA publishes stable releases for production within its support matrix; that is a deployment commitment, not a hosted compute allowance.
• OpenSandbox provides a common API for sandbox lifecycle, commands, files, and code execution across Docker and Kubernetes. The Agentic AI Foundation (AAIF) accepted Alibaba's contribution on the same day. Evaluate it when that portable API and its browser or desktop workflows fit your product. Its Fast Sandbox integration can use Firecracker microVMs; the configured backend determines the isolation boundary. Foundation stewardship does not configure or operate that boundary for you.

The boundary budget: which meter reaches the invoice

A sandbox bill is mostly a meter-selection problem disguised as an infrastructure choice. Some providers charge for the whole time a machine is running. Others separate active CPU from provisioned memory. Run SDK keeps execution inside the application, so there is no second remote runtime to meter at all.

The illustration below uses one million tasks, each requiring 30 seconds of environment time but only five active CPU-seconds. That produces 8,333.33 environment-hours and 1,388.89 active CPU-hours. These are workload assumptions, not measured performance. The environments are reused within the same tenant in runs lasting whole minutes, with no additional setup or idle time; this is not a recommendation to share a guest between tenants.

The pictured estimates are rounded, partial compute totals using the rate cards above: Upstash Small charges the active core time; Runloop uses one CPU plus one GB across the open time; Vercel uses active CPU plus its required two GB of RAM per vCPU. Storage, model calls, plan fees, credits, creation charges, network, and actual minimum machine sizes can change the invoice.

A fresh sandbox per task changes the result. Vercel bills provisioned memory in at least one-minute increments. If you create a new sandbox for every 30-second task, the pictured Vercel amount does not apply: its memory component doubles. Apply that minimum before treating any short-job comparison as a quote. Vercel's billing rules explain the distinction.

SPACE moves the calculation to your own hosts, storage, control plane, and operating time. Open source removes a software license bill; it does not remove the machines or the engineers responsible for them. Run SDK can remove a remote machine entirely when a program only coordinates approved host functions, but its application host, model, database, and API calls still cost money.

1. Vercel Run SDK: best for bounded tool orchestration

Vercel Run SDK is the best first boundary when an agent writes JavaScript or type-stripped TypeScript to coordinate capabilities your application already owns. Each invocation gets a fresh hardened QuickJS context inside a worker thread; it can reach the outside world only through functions you explicitly expose. The database client, API credentials, and authorization logic remain in trusted application code. Its wall is equally clear: it is not Linux and cannot install native packages or start arbitrary processes. It is also not a separate operating-system process, so do not mistake its restricted language environment for hardware isolation. Run SDK isolation model.

A useful example is a support agent that must fetch an order, inspect invoices, calculate an allowed refund, request a manager's approval, and publish the result. The generated program can perform the branching and parallel calls, while orders.get, billing.listInvoices, and orders.refund remain narrow host functions. If execution pauses for approval or authentication, the SDK returns a signed continuation; when the decision arrives, completed host calls are replayed from their recorded results instead of firing twice.

That replay behavior matters commercially. A normal restart can duplicate a charge, send a second message, or rerun a slow lookup. Run SDK makes “pause, approve, resume” an execution primitive, while your host functions remain responsible for authorization and idempotency. It also lets the application set timeout and memory limits globally or per run.

Best for: TypeScript agent plans that calculate, branch, and call a small approved tool surface
Standout: Signed approval/auth continuations without repeating settled host calls

1. 1

   Inventory ambient authority

   List every database client, secret, filesystem path, network destination, and service method the current agent code can touch. Anything not required for the task should disappear from the generated program's world.

2. 2

   Define narrow host functions

   Expose business operations such as orders.list, refunds.quote, or drafts.publish, not a generic HTTP client. Validate the user, tenant, resource, and allowed action again inside every host function.

3. 3

   Set a hard execution envelope

   Choose memory and timeout limits from observed payload sizes and latency. Treat serialization across the boundary as a feature: it prevents a live database client or secret-bearing object from leaking into generated code.

4. 4

   Add the approval seam

   Interrupt before irreversible actions, store the signed continuation beside the approval request, and resume only after a recorded decision. Keep the host operation idempotent even though settled calls are not repeated.

5. 5

   Route OS jobs elsewhere

   If a task asks for apt, Docker, a compiler, a repository checkout, Python, or a server process, send it to the remote-sandbox pool. Do not weaken the Run SDK boundary to make one exceptional job fit.

2. E2B: best general-purpose microVM default

E2B is the strongest general default when “run this code” genuinely means “give the agent a Linux computer.” Every sandbox uses E2B's microVM runtime built on Firecracker, and the platform supports commands, files, custom templates, package installation, code-interpreter sessions, and any language or framework that runs on Linux. It is the clean middle ground between an application-scoped evaluator and a persistent personal machine. The main wall is economic: E2B meters CPU and memory for every second the sandbox is running, not only the moments when code is busy.

E2B fits a repository-repair agent that starts from a prepared template, clones a project, installs missing dependencies, runs tests, changes files, and returns a patch. Code Interpreter adds a convenient stateful notebook surface for analysis, while the lower-level Sandbox API handles normal Linux commands and files. A custom template can move repeated setup out of the hot path. E2B also supports pausing with filesystem and memory preserved; it is not limited to disposable sessions. E2B documentation.

The free Hobby plan is useful for evaluation, but its one-hour continuous-run limit needs planning for larger builds. Pro stretches continuous execution to 24 hours and raises concurrency. Pausing and resuming resets the runtime window while preserving state, so these limits do not cap the workspace's total lifetime. Teams should decide whether those limits justify a recurring plan before moving a prototype onto it. E2B lifecycle limits.

Best for: Multi-language code execution, repository work, data analysis, and package-heavy agents
Standout: Firecracker microVMs with a mature Linux sandbox and Code Interpreter surface

3. Vercel Sandbox: best for Vercel and AI SDK teams

Vercel Sandbox is the best full-machine choice when the application, agent loop, and deployment already live on Vercel. Each sandbox is a Firecracker microVM with its own Linux filesystem and network; Ubuntu, apt-get, sudo, Docker, FUSE, package installs, background services, snapshots, and up to 15 exposed ports are supported. Active CPU pricing makes bursty execution attractive. The hard wall is provisioned memory: even while the CPU is idle, RAM remains on the bill while the sandbox is open.

Claude Managed Agents can keep Anthropic's model, harness, tools, and session state while using a Vercel Function as the control plane and one Vercel Sandbox per session. Credential brokering at the firewall means an outbound request can receive a secret without that credential entering the microVM. The same pattern works for an AI SDK agent: broad package access during setup, then a tighter network policy before untrusted execution. Vercel's integration guide.

Hobby is useful for non-commercial experimentation, but it cannot buy overages and caps a session at 45 minutes and four vCPUs. Pro raises the duration to 24 hours and compute to eight vCPUs; Enterprise reaches 32. The default five-minute timeout is a helpful cost guard. The duration cap applies to one session, not the lifetime of a persistent sandbox. Persistence is now the default, with state saved on stop; choose a disposable lifecycle deliberately for untrusted jobs that must start clean. Current Sandbox documentation.

Best for: Vercel-hosted agents, AI SDK code execution, Claude Managed Agents, previews, and I/O-heavy Linux work
Standout: Firecracker isolation plus active CPU billing, runtime network policy, credential brokering, and snapshots

4. Daytona: best for speed, runtime choice, and GPU range

Daytona is the best choice here when one agent product needs several execution environments. Its current documentation describes sandboxes with a dedicated kernel, filesystem, and network stack, plus OCI/Docker compatibility, snapshots, and volumes. Windows computer-use environments and GPUs expand the range, while SSH, browser VS Code, and terminals support human intervention. The wall is operational choice: record the isolation, resource requirements, and lifecycle of each route instead of assuming every workload behaves alike. Daytona docs.

Daytona suits a coding product that handles many repository jobs but occasionally routes work to Windows or a GPU. Its stateful sandboxes and snapshots keep setup reusable, and its secrets feature substitutes credentials at network egress. Confirm that the particular OS and accelerator combination your job needs is supported before choosing it. Product capabilities.

The public rate card separates CPU, memory, storage, Windows, and GPU usage. GPU offers now distinguish preemptible capacity from on-demand capacity. Choose the interruption policy alongside the hardware; a cheaper route that restarts an expensive job can be the wrong purchase.

Best for: High-churn coding sessions, heterogeneous runtimes, Windows tasks, and optional GPU execution
Standout: Programmable sandboxes with snapshots, Windows options, and GPU capacity

5. Upstash Box: best persistent container with a coding agent included

Upstash Box is the most practical all-in-one option for a persistent container that already understands coding-agent work. Every Box has a filesystem, shell, process tree, network stack, git, and optional Claude Code or Codex agent; state survives across runs and a standard Box freezes when idle. Active CPU billing can make bursty repository work unusually cheap. Its hard wall is security policy: Box documents an isolated-container boundary rather than a hardware microVM guarantee, and currently runs only in AWS us-east-1.

This is a strong fit for a small product team that wants one durable environment per project or customer. The agent can clone a repo, install packages, leave files and git history in place, pause, and reconnect later. A network policy can reduce the default open outbound access, which should be part of setup rather than a later hardening task.

The billing model rewards CPU-light waits, but Small still provisions two vCPUs and four GB RAM. The current Fixed plan keeps a box always on and includes its CPU and storage, while PAYG charges active core-hours and storage separately. Choose between them from sustained activity, not the word “serverless.” Box security documentation also makes clear that secrets placed in environment variables can be read by untrusted code; use header injection when appropriate.

Best for: Persistent repository agents, built-in Claude Code or Codex sessions, and bursty CPU use
Standout: Durable filesystem and coding agent with active-core billing and automatic pause

6. Cloudflare Sandbox: best for Workers-native execution at the edge

Cloudflare Sandbox is the best fit when the control plane is already a Cloudflare Worker and the agent needs Linux execution. The current Linux path runs container images inside microVMs with their own kernels and networks, coordinated by Durable Objects. Cloudflare also offers Dynamic Workers for code that only needs a language runtime and explicit application methods. The Linux path uses the Durable Object scheduling policy, which remains in public beta. The pricing row above covers the Linux Containers path, not Dynamic Workers. Cloudflare's environment guide.

Choose the Linux path for a coding playground, data-analysis surface, terminal, or preview server. Commands, files, and background processes live in the instance. Keep credentials in the Worker and intercept authorized outbound requests instead of placing tokens in the guest; disabling general Internet access limits the container to the intercepted destinations. Network controls.

Files on the instance disk disappear when it stops unless you save them. Snapshots, automatic saves, directory backups, and R2 mounts cover different persistence needs. The billing wall remains: provisioned memory and disk, active CPU, Workers, Durable Objects, logs, and regional egress are separate things to budget. File persistence.

Best for: Workers-native applications, previews, terminals, and controlled outbound access
Standout: Worker-controlled Linux microVMs, with a separate lightweight Dynamic Workers option

7. Modal Sandboxes: best for data and GPU workloads

Modal Sandboxes are the strongest pick when sandboxed code sits beside serverless data or GPU work. Choose gVisor for GPU Sandboxes or the VM runtime for a full Linux kernel and Docker. If you leave the runtime unset, Modal chooses it. Sandboxes can burst beyond requested CPU and memory; set upper limits when generated code controls the workload. The key wall is the split: VM Sandboxes do not currently support GPUs, while GPU Sandboxes can be preempted. A team that needs both full VM semantics and GPU execution in the same sandbox must look elsewhere.

Modal makes sense for an analysis agent that executes Python, transforms a dataset, renders a result, then occasionally escalates a job to a GPU. Resource limits can cap bursts when an agent controls the workload. Billing uses the higher of requested or actual CPU and memory, so requests should be set near observed demand rather than an imagined peak; the vendor recommends tuning CPU around the middle of observed use and memory nearer the upper tail.

The Starter plan includes recurring compute credit. Team buys higher container capacity, more GPU concurrency, and unlimited seats. One Modal physical core equals two vCPUs, so normalize that unit before comparing rate cards. Sandbox resource and billing rules.

Best for: Python analysis, scientific workloads, burstable compute, and agents that sometimes need GPUs
Standout: Serverless sandbox execution beside a broad GPU catalog and resource caps

8. Runloop Devboxes: best for repeatable coding-agent evaluation environments

Runloop Devboxes are the best choice here when repeatable coding-agent environments matter more than the cheapest execution meter. Devboxes are isolated virtual machines with Blueprints for reusable images, snapshots, network policies, and credential gateways. That makes them a useful foundation for running the same repository tasks across agent versions. The wall is price positioning: compute is relatively expensive, and production-oriented Pro adds a recurring fee. Devbox capabilities.

That premium can be rational when it replaces environment plumbing for an evaluation system. A repository-editing agent needs reproducible starting states and comparable results. Blueprints and snapshots supply the environment layer; define your own scenarios, scoring, and regression criteria rather than assuming the sandbox alone proves an improvement.

Basic is enough to prove the workflow. Pro adds suspend/resume, connected repositories, beta access, Slack support, and more included storage. Enterprise adds a VPC deployment route. Keep evaluation policy in the application so you can compare runs without tying the meaning of success to a hosting vendor.

Best for: Coding-agent benchmarks, regression evaluation, reproducible repository tasks, and enterprise rollout
Standout: Reusable Blueprints and snapshots for reproducible repository work

9. Blaxel Sandboxes: best for fast-resume stateful fleets

Blaxel Sandboxes are the best choice when an agent needs a personal microVM that can disappear from the compute bill and wake with memory, processes, and files intact. An idle sandbox can enter standby with its memory, processes, and filesystem preserved. Exact idle behavior depends on its connections; check the lifecycle settings rather than treating one timer as universal. REST and MCP surfaces expose processes and files, while ports, previews, network controls, volumes, and custom images fill out the machine. The wall is standby storage: active memory stops billing, but snapshots or attached volumes continue, and premium support can dwarf compute spend.

This lifecycle fits a customer-facing coding agent whose environment should feel continuous across many short visits. The process tree and filesystem can return from warm standby rather than rebuilding a repository and development server. Long-cold projects can be archived to preserve files without preserving live memory, with a different recovery path from warm standby.

The active rate is tied to allocated RAM, with CPU scaling alongside memory instead of appearing as a separate line. Standby stops compute charges but retains billable snapshot storage; attached volumes have their own storage charge. External network connections do not survive restoration, so reconnect database clients and other sessions. Blaxel lifecycle documentation.

Best for: Stateful agent sessions, per-customer computers, MCP-driven environments, and fast resume
Standout: MicroVM standby that restores memory, processes, and filesystem

10. Fly.io Sprites: best persistent Linux computer for one agent

Fly.io Sprites are the best fit when the product metaphor really is “one durable Linux computer per agent.” A Sprite has a normal POSIX filesystem, 100 GB volume capacity billed on actual use, live and automatic checkpoints, restore, service URLs, and Connectors that let the machine call external services without holding provider credentials. Running is billable; warm and cold compute states are not. The wall is retained-state economics: compute stops while idle, but cold storage remains billable for as long as you keep the data. Sprites documentation.

Sprites suit a long-running coding agent that installs tools once, keeps its repository and local database in familiar paths, serves previews, and returns to earlier disk checkpoints after a bad change. A checkpoint captures the writable filesystem overlay, so restore rewinds files and packages while leaving the base image unchanged. Warm pauses can preserve running processes; a cold wake or checkpoint restore starts processes afresh. Connectors separate credentials from the guest while preserving the ordinary Linux workflow. Checkpoint behavior and warm/cold lifecycle.

The current rate card has no subscription plans, tiers, or per-Sprite fee. CPU and actual memory are usage-based; hot storage bills while the Sprite is awake and cold storage bills while the data is retained. Plan names still visible in older material should not drive a new purchase.

Best for: Durable Linux workspaces, long-lived coding agents, local databases, and checkpoint-based recovery
Standout: A persistent ordinary filesystem with automatic checkpoints and zero compute charge while warm or cold

11. Perplexity SPACE: best for owning the sandbox platform

Perplexity SPACE, short for Sandboxed Platform for Agentic Code Execution, is the self-hosted choice for an engineer who needs to inspect and operate the sandbox infrastructure. It runs code in Firecracker microVMs through an HTTP API, with a Linux environment and writable filesystem per sandbox. Its advantage is control over the platform; its wall is that your team owns deployment, capacity, upgrades, and recovery.

Perplexity has made the sandbox platform behind Computer available as open source. That changes the build-versus-buy decision for teams that need their own execution infrastructure, but it does not make a hosted sandbox unnecessary for teams that want someone else to operate it. Perplexity's announcement.

The repository is licensed under Apache License 2.0. It includes service and CLI source, shared Rust libraries, API examples, Firecracker template recipes, Dockerfiles, and deployment scripts. The architecture comprises an API backed by PostgreSQL, controllers, worker services, a separate command-stream data plane, template builders, object storage, and an optional UI. Your application still supplies the agent logic and decides what results to retain. This is the execution platform, not a self-hosted copy of Computer's complete agent product. Architecture and included components.

For a repository agent that pauses for approval, the state distinction matters: pause keeps memory resident on the worker and is not a durable snapshot; suspend captures memory, runtime state, and the root filesystem while releasing active VM resources. Network policy and platform-held credentials are controlled outside the untrusted guest. Evaluate those boundaries and recovery paths under your own threat model before replacing a managed provider.

Best for: Platform teams that need self-hosted, inspectable agent execution infrastructure
Standout: Open-source Firecracker sandbox platform with lifecycle and host-side security controls
Operating cost: Your compute, storage, networking, and engineering time; no hosted usage allowance is bundled with the source

How to self-host SPACE for evaluation

Start with the official local installation guide. It requires an apt-based Linux x86_64 host with KVM, /dev/kvm, /dev/net/tun, loop devices, btrfs support, and Docker configured for privileged containers. A VM must expose the devices and support nested virtualization; the documented setup does not run directly on macOS.

Clone the repository, run its prerequisite and Firecracker installers, then its bootstrap script. That path deploys a local Kind cluster, which runs Kubernetes in Docker, and publishes the starting template. Authenticate and follow the first-sandbox walkthrough to create an environment, run a command, collect its output, and delete it. The architecture also has a direct worker adapter without Kubernetes, but the local installation guide covers Kind.

Treat this as an evaluation setup: the guide uses development credentials and signing keys and says to keep it private. Production needs deliberate authentication, network policy, storage, and operational ownership. The repository's security policy supports security fixes only on the most recent minor release, so staying current is part of the commitment.

Who should pick what

Pick Vercel Run SDK when the generated program can be described as “calculation plus approved application calls.” The choice flips away from Run SDK the first time the task truly needs a shell, arbitrary network client, native dependency, another language, or an untrusted repository.

Pick E2B when a cloud-neutral Linux microVM is the product primitive. It is the sensible default for code interpreters, repository agents, and package-heavy execution, especially before special persistence, GPU, or edge requirements appear.

Pick Vercel Sandbox when the application is already on Vercel and active CPU, AI SDK integration, Claude Managed Agents, network policy, and credential brokering remove more engineering than a neutral vendor would save. Compare its provisioned-memory line carefully for slow, wait-heavy sessions.

Pick Daytona when compute diversity is a requirement: ordinary repository jobs, Windows-specific tasks, or GPU work. Confirm the supported combination and interruption policy for each route before making runtime variety part of the product promise.

Pick Upstash Box when state should persist, the CPU is bursty, and container isolation passes the threat model. It is the most direct choice for a small team that wants Claude Code or Codex inside each durable workspace without assembling the agent layer separately.

Pick Cloudflare Sandbox when Workers and Durable Objects are already the control plane. Its edge-native value disappears if the rest of the stack lives elsewhere, so ecosystem fit should be treated as the primary criterion rather than a bonus.

Pick Modal when sandboxed execution is attached to a data, scientific, or GPU pipeline. Compare Daytona for a broader compute menu, or E2B if the workload is ordinary Linux without serverless ML adjacency.

Pick Runloop when the business problem is repeatable repository execution for coding-agent evaluations. Blueprints and snapshots can remove environment work, but you still need explicit scenarios and scoring. Its premium is hard to justify for a generic code interpreter.

Pick Blaxel when thousands of agent computers must feel present while mostly sleeping. Pick Fly.io Sprites when durable Linux, conventional paths, and checkpoint recovery matter more than the fastest process-memory resume.

Pick SPACE when self-hosting and control over the implementation are requirements, and the team can own the virtualization hosts and control plane. It belongs beside the hosted choices as an operating-model decision, not above them because the license is open source.

For a deeper threat-model pass, pair this guide with the AI sandbox security tools comparison. If the sandbox is only one layer in a larger coding-agent product, the embeddable coding-agent harness roundup covers the agent loop above it, while the AI code hosting guide covers where the resulting applications live.

How these were picked

This is a compared and verified ranking, not a claim that every vendor was deployed under production load. Prices, limits, isolation statements, and capabilities were checked against primary pages on October 23, 2026. The illustration is arithmetic under explicit lifecycle assumptions, not a measured bill or a performance benchmark.

The selection criteria were:

• Boundary clarity: Is this QuickJS, a container, gVisor, a microVM, or a persistent full computer, and does the vendor say so plainly?
• Agent fit: Can it manage commands, files, processes, packages, previews, repositories, approvals, or agent-specific state without a homemade control plane?
• Lifecycle economics: What is billed while code runs, waits, sleeps, snapshots, or persists?
• Operational escape hatches: Are there timeouts, resource caps, network policies, secret brokering, snapshots, regions, and an enterprise route?
• Honest wall: Every winner needs a reason to skip it. A ranking with universal recommendations is sales copy, not buying advice.

The order rewards the architecture that prevents unnecessary spend first, then the strongest general remote default, then increasingly specialized wins. SPACE is the specialist for teams that need to own the infrastructure. That is why a lightweight SDK can rank above a more capable VM without pretending it does the VM's job.

The ones to avoid for this exact job

Raw eval() and Node's vm module

Do not treat a language feature as a multi-tenant security boundary. Generated code should not inherit application secrets, network clients, or filesystem reach merely because it is convenient to execute. If the job is small enough for in-process execution, use a hardened evaluator with explicit capabilities; if it needs ambient OS access, move it to an actual isolated environment.

Plain shared-host Docker as the only untrusted-code boundary

Docker is valuable packaging, but a container shares the host kernel. Upstash documents an isolated-container model; Cloudflare now explicitly documents a microVM around each Linux container instance. Packaging alone does not tell you the isolation boundary. A homemade docker run on a shared production host is a different risk decision. Use a microVM when hostile tenant code, regulation, or the blast radius demands hardware isolation.

Human-first cloud IDE workspaces used as a per-task backend

GitHub Codespaces, Replit workspaces, and similar developer environments can be excellent places for a person to build. They are not automatically the right API primitive for creating and destroying thousands of untrusted agent jobs. Buy them for the human development experience; buy an agent sandbox for programmable lifecycle, isolation, metering, concurrency, and machine-readable outputs.

A persistent computer for a disposable calculation

Fly.io Sprites and Blaxel are compelling precisely because state survives. If every task begins from a clean template and returns one result, persistence adds snapshot storage, cleanup policy, and tenant-state risk without creating user value. Use the cheapest disposable boundary that satisfies the work.

The Monday move

Start with the generated-code paths already in production, not a vendor bake-off. An inventory can reveal that “agent code execution” is three different jobs hiding behind one queue.

1. 1

   Label the authority

   Mark each path host tools, full OS, or persistent computer. Host tools means every effect can be an explicit application function. Full OS means packages, processes, repositories, or arbitrary languages. Persistent computer means yesterday's filesystem or process state is part of the product.

2. 2

   Route the light path first

   Move one reversible, high-volume TypeScript plan behind Run SDK-style host functions. Keep the existing remote sandbox as the fallback for unsupported jobs. This makes the saving measurable without betting the workflow on a full migration.

3. 3

   Instrument all the clocks

   Log environment-open seconds, active CPU seconds, provisioned memory, startup time, storage growth, transfer, retries, and approval waits. A provider comparison without these fields will optimize the rate-card headline instead of the invoice.

4. 4

   Prove the security seam

   Attempt forbidden network calls, secret reads, filesystem escape, excessive output, infinite loops, and duplicate side effects around approval. Route failures by class; do not silently widen the boundary.

5. 5

   Review after one billing cycle

   Keep the lightweight route if it removes remote runtime without increasing failures. Keep the heavier provider only for jobs that used its OS, persistence, GPU, evaluation, or region advantage. Evaluate SPACE and the other self-hosted options separately only if operating your own platform is an explicit requirement. The goal is not one vendor, it is one explicit reason for every meter on the bill.

Frequently asked questions

Which sandbox tool is considered the best?

Vercel Run SDK is the best first boundary for agent-written JavaScript or TypeScript that only coordinates approved application tools. E2B is the best general-purpose remote Linux microVM. Vercel Sandbox is the best full-OS fit for teams already using Vercel, the AI SDK, or Claude Managed Agents. The requirement that flips the choice is operating-system access.

What are the best free AI agent code sandboxes in 2026?

Run SDK is open source for host-function-only JavaScript and TypeScript. SPACE is open source for a full self-hosted sandbox platform, with infrastructure and operations still yours to fund. Hosted services offer different free plans, credits, and trials, summarized in the table above; none should be read as unlimited free production infrastructure. Check session, concurrency, commercial-use, and overage limits before choosing.

How do I set up an agent sandbox to continue Codex?

Use a persistent environment such as Upstash Box, Blaxel, or Fly.io Sprites when Codex should return to the same repository and installed tools. Store the sandbox ID against the project, pause rather than delete after a session, checkpoint before risky changes, and keep repository or provider credentials outside the guest through scoped tokens or credential brokering. If every job starts clean, use a snapshot-backed disposable microVM instead.

How do you deploy AI agents on Kubernetes?

For SPACE, the documented evaluation route deploys a local Kind cluster on a suitable Linux/KVM host, then runs agent code inside Firecracker microVMs. Kubernetes coordinates the platform; it is not the security boundary by itself. Give every untrusted job a clearly isolated pod or VM-backed runtime, apply CPU/memory/ephemeral-storage limits, default-deny egress, inject short-lived credentials outside generated code, and delete or archive state on an explicit lifecycle. A managed Kubernetes platform can reduce that operational load, but a purpose-built sandbox API is usually faster for the first production agent.

Want the authority, risk, and cost questions in one working sheet? Download the AI Business Workflow Audit Checklist and classify the first three execution paths on Monday.