AI agent sandbox: compare the kernel boundary first, then the per-hour rate

Two specifications decide whether an AI agent sandbox is the right place to run code your agent wrote: where the kernel boundary sits, and what a vCPU-hour costs. Both are published. Cold-start numbers, the figure most comparison posts lead with, appear on none of the pricing or documentation pages we read, which is why the third-party benchmarks quoting them keep contradicting each other.

This is a comparison of what five options say about themselves on their own pricing and documentation pages, read on October 23, 2026. Where a page does not state something, we say so rather than fill the gap.

What an AI agent sandbox actually buys you

An AI agent sandbox is a disposable execution environment an agent gets instead of your laptop or your production host. It exists because an agent will run code it generated a second earlier, and because the text it read on the way - a web page, an email, a PDF - can carry instructions it then follows. That is prompt injection, and no amount of prompting fixes it. Containment does.

What you are buying breaks into four layers, and most products sell only the first two:

1. Compute isolation - a container, a microVM or a full VM around the process.
2. Egress policy - which hosts the sandbox may reach, checked before the packet leaves.
3. Credential brokering - the agent never holds the real token; something else attaches it to approved requests.
4. Human approval for irreversible actions.

The hosted sandbox SDKs are strongest on layer one. Layers two to four are usually yours to build, or come from a separate tool - the same split we found when we looked at what a password manager for AI agents covers today. Knowing which layers a vendor does not supply is the whole point of reading its docs rather than a feature grid.

Is a container enough to isolate an AI agent?

This is the one technical question worth arguing about, and the honest answer is: it depends on who wrote the code inside.

A Linux container shares the host kernel. That is fine for code you wrote and reviewed, and it is the reason containers start fast. A microVM or VM gives the workload its own kernel, so a kernel-level escape has one more wall to get through. For code an agent generated, or code a prompt-injected document talked an agent into fetching, in our view the extra wall is the thing you are paying for.

The vendors are not shy about which one they ship. Modal's sandbox documentation says Sandboxes run on either gVisor, Google's container runtime, or a VM runtime that gives each Sandbox its own Linux kernel, selectable through a runtime parameter - and that GPU Sandboxes support gVisor only. Daytona's sandbox management docs say sandboxes run as Linux containers by default, with separate VM sandboxes for workloads that need a full operating system. Cloudflare's sandbox overview describes container instances as microVMs with their own kernel and network, alongside Dynamic Workers that can reach your application only through the methods and data you hand them. E2B's sandbox docs call a sandbox an isolated Linux VM, and do not name a hypervisor.

Skip the VM tier if the agent only runs your own reviewed code against your own data. Insist on it the moment the agent can fetch and execute something you have not seen.

How much does an AI agent sandbox cost per hour?

All three of the usage-priced options publish per-second rates, which makes them comparable once you do the arithmetic.

E2B's pricing page lists $0.000014 per vCPU-second and $0.0000045 per GiB-second. That is $0.0504 per vCPU-hour and $0.0162 per GiB-hour, so a 2 vCPU, 4 GiB sandbox runs about $0.17 an hour on those rates - our arithmetic, not a number E2B prints.

Daytona's pricing page prints the hourly figures directly: $0.0504 per vCPU-hour and $0.0162 per GiB-hour. Those are the same rates as E2B's, to the hundredth of a cent. Daytona also lists storage at $0.000108 per GiB-hour with the first 5 GiB free, Windows at $0.0858 per vCPU-hour, and preemptible GPUs from $0.57 an hour for an RTX 4090 up to $4.08 for a B300.

Modal's pricing page is the outlier, and deliberately so: "Sandboxes are billed at non-preemptible rates of 3x list price." Those rates are $0.00003942 per core-second and $0.00000667 per GiB-second, where a core is one physical core, which the page equates to 2 vCPUs. That works out to roughly $0.071 per vCPU-hour and $0.024 per GiB-hour - about 40% more per vCPU than E2B or Daytona. You are paying for capacity that will not be preempted under you mid-task.

In our view the per-hour rate matters less than it looks, because agent sandboxes are short-lived by design. The plan fee and the concurrency ceiling usually cost more:

• E2B: Hobby is $0 with a one-time $100 in credits, 20 concurrent sandboxes and 10 GiB of storage. Pro is a $150 monthly plan fee plus usage, for 100 concurrent sandboxes. Enterprise carries a $3,000 monthly usage minimum.
• Daytona: no plan fee on pay-as-you-go, $200 in trial compute with no card, up to $50,000 in credits for eligible startups, and bring-your-own-cloud on Enterprise.
• Modal: Starter is $0 + compute with $30 a month in free credits, 3 seats and 100 containers. Team is $250 + compute with $100 a month in credits, unlimited seats and 5,000 containers.
• Cloudflare: the Sandbox SDK requires the Workers Paid plan, with container and Dynamic Workers usage billed separately.

All figures read on October 23, 2026. Usage pricing changes without an announcement, so re-check before you commit a budget.

How long can a sandbox session last?

Long enough matters more than fast enough for anything an agent does unattended, and the limits differ by an order of magnitude.

E2B's docs put a continuous run at up to 24 hours on Pro and 1 hour on Hobby, with the option to pause a sandbox when its timeout expires, keep full state indefinitely and resume later - pausing resets the runtime window. Modal's Sandboxes default to a 5-minute maximum lifetime, which you raise with a timeout parameter up to 24 hours; beyond that you save a filesystem snapshot and restore it into a new Sandbox. Both also expose an idle timeout, which is the setting that actually controls your bill.

Daytona's management docs describe auto-stop, auto-pause, auto-archive, auto-delete and a wall-clock TTL, and note that preempted spot GPU sandboxes stay retrievable for 24 hours, but the pages we read did not state the default values. Ask before you design around them.

Can you self-host an AI agent sandbox? OpenShell says yes

NVIDIA published OpenShell on October 22, 2026, describing it as a safe, private runtime for autonomous AI agents, under the Apache License 2.0. It had roughly 17,700 GitHub stars when we read the repository on October 23.

What makes it interesting, in our view, is that it covers all four layers above rather than only the first one, and does so in a project enough people are watching for the policy format to matter. Per its README: each agent runs in a kernel-level sandbox with limits on the files it can read and the system calls it can make; every outbound connection is checked against policy before it leaves; agents never see real credentials, which OpenShell attaches only to requests headed for approved endpoints; and policy changes go through formal verification that flags risky new access - such as a new host that would start receiving credentials - and holds those changes for human review. It ships SDKs for Python, TypeScript, Go and Rust, a Helm chart for Kubernetes, and runs on Linux, macOS on Apple Silicon and Windows via WSL 2, which the README marks experimental.

The catch is the one every self-hosted runtime has. The version line in the README is 0.1.x, you operate the fleet, and you pay for the compute underneath - from a general cloud or a GPU host like Runpod if the agents need accelerators. A hosted SDK bills you for someone else running that. Upfynd lists 211 open-source products as of October 23, 2026, in our Open Source category, and this trade-off is the same one every entry there presents.

When we would skip a sandbox SDK entirely

Three situations where the purchase is not worth it, in our view:

• The agent runs no code. An agent that calls three APIs and writes to a database needs scoped credentials and an audit log, not a disposable Linux VM. Buy layer three, not layer one.
• You already run a batch platform. If your team is on a serverless compute platform such as Modal, the sandbox is a feature of the thing you pay for, not a second vendor. The same reasoning applies to Cloudflare if your app already lives on Workers.
• One developer, one machine. A local container with a read-only mount and no network is free, and it is a real boundary for code you wrote.

How we would choose

Start with the question of who authored the code the sandbox will run. If an agent did, shortlist only options that can give the workload its own kernel - which today means Modal's VM runtime, Cloudflare's container instances, E2B, or OpenShell on your own hardware.

Then check the session ceiling against your longest task, because a 5-minute default and a 1-hour free-tier cap end runs in ways that look like bugs. Price last: at roughly $0.05 to $0.07 per vCPU-hour across these vendors, compute is rarely what decides it.

Upfynd lists 208 products in AI Agents and 157 in LLMs & AI Infrastructure as of October 23, 2026, which is where the frameworks, runtimes and gateways around this decision sit. If you build one of them and it is not listed, you can add it free.