E2B, Daytona, Modal, Vercel Sandbox and local options: how AI sandboxes differ

01How should you compare AI sandbox providers?

Compare attributes, not brands. Two teams with different workloads will reasonably pick different providers, and the same team may use one for short code execution and another for long-running coding agents. The attributes below are the ones most likely to change a design: the runtime underneath, the lifetime of one sandbox, what state survives a stop, the billing model, and where the sandbox can run.

Providers are listed alphabetically in each section. Every fact comes from that vendor's documentation or pricing page as read on 31 October 2026. Limits and prices change often, so treat the numbers as a dated snapshot and recheck them before you commit. For the isolation boundary and network controls of each option, see our earlier map of AI agent sandboxes; this post does not repeat it.

02What does each sandbox run on?

The runtime decides what code can do inside the sandbox, such as running Docker or FUSE, as well as how strong the boundary is. Several providers offer more than one runtime, so the answer can differ per sandbox.

Whether code can run privileged workloads also varies. Modal's VM runtime and Vercel Sandbox both document running container runtimes such as Docker inside the sandbox, which matters for agents that build images or run integration tests.

• Cloudflare Sandbox SDK: sandboxes run on Containers or Dynamic Workers, started and driven by a Durable Object in your Worker. It requires the Workers Paid plan.
• Daytona: Linux containers by default. VM sandboxes run a dedicated Linux or Windows system and add VM-only features such as forking and pause and resume.
• E2B: each sandbox is a Linux VM that can be paused and resumed.
• Modal: a gVisor runtime, or a VM runtime with its own Linux kernel for workloads such as Docker or FUSE, chosen with the runtime parameter.
• Vercel Sandbox: each sandbox runs in a Firecracker microVM with its own filesystem and network.

03How long can one sandbox run?

Lifetime limits matter most for coding agents, which can work for hours. Read two numbers for each provider: the default, which catches you when you forget to set it, and the maximum, which bounds the longest task.

Pausing or stopping often resets the clock. E2B says a pause and resume resets its running-time limit, and Vercel says its maximum applies to one session, so a persistent sandbox's total lifetime is effectively unbounded.

• Cloudflare: an instance runs while its Durable Object is active. Without a timeout it stops shortly after the Durable Object goes inactive, and setInactivityTimeout() allows up to 6 hours.
• Daytona: auto-stop after 15 minutes by default, auto-archive after 7 days by default, and no automatic deletion unless you set one.
• E2B: continuous running time is capped at 1 hour on Hobby and 24 hours on Pro.
• Modal: a default lifetime of 5 minutes, adjustable up to 24 hours, plus an optional idle_timeout.
• Vercel Sandbox: a default timeout of 5 minutes; the maximum session is 45 minutes on Hobby and 24 hours on Pro and Enterprise.

04What state survives when a sandbox stops?

This is where providers differ most, and it decides whether you can pause an agent mid-task or only skip setup on the next run. Files-only persistence restarts processes. Memory persistence brings running processes back.

Retention is part of the answer. A snapshot or paused sandbox that expires before you need it is not a backup, and one that never expires keeps adding storage charges, so set expiry on purpose.

• Cloudflare: files and processes end with the instance. A snapshot restores the writable root filesystem, not memory or processes.
• Daytona: stopping keeps the filesystem but not the memory state. VM sandboxes add pause and resume.
• E2B: pausing saves both filesystem and memory, including running processes. Paused sandboxes are kept until you kill them.
• Modal: filesystem and directory snapshots, kept 30 days by default, and memory snapshots, documented as alpha, that expire after 7 days.
• Vercel Sandbox: sandboxes are persistent by default, and a filesystem snapshot is taken automatically when a session stops. Snapshots expire 30 days after last use by default, adjustable to never, and stay in their region.

05How are AI sandboxes billed?

Billing models reward different workloads. Per-second billing on provisioned resources charges for the whole time a sandbox is up. Billing on active CPU charges less while an agent waits on a model. Local tools cost your own hardware. The rates below are the published list rates on 31 October 2026 and exclude plan fees, credits and discounts unless stated.

Agents spend much of their time waiting on model calls, so ask each provider what an idle but running sandbox costs. That number, multiplied by how long your agents sit waiting, often matters more than the headline CPU rate.

• Cloudflare: billed under Containers or Dynamic Workers pricing, on the Workers Paid plan.
• Daytona: billed per second; vCPU at $0.0504 an hour and memory at $0.0162 per GiB an hour, with $200 of compute included and BYOC on Enterprise.
• E2B: running sandboxes billed per second for provisioned CPU and RAM, at $0.000014 per vCPU-second and $0.0000045 per GiB-second, plus a plan fee; Hobby is $0 and Pro is $150 a month.
• Modal: sandboxes are billed at the greater of requested and actual resources.
• Vercel Sandbox: Active CPU at $0.128 an hour on Pro, where time waiting on I/O such as model calls does not count, plus provisioned memory, creations and outbound data.
• Docker Sandboxes: the sbx CLI and local compute are free to use; cloud compute is pay-as-you-go.

06Cloud vs local sandbox: where can each one run?

Location is often decided by data rules before anything else. A managed cloud sandbox runs in the vendor's regions. Some vendors offer bring-your-own-cloud on enterprise plans. A local sandbox runs on the developer's machine, which keeps code and data there and makes you the operator.

SDK support follows the same split. E2B documents JavaScript and TypeScript and Python SDKs, Modal documents Python, JavaScript and Go, Vercel shows TypeScript and Python, and Cloudflare's package is @cloudflare/sandbox for Workers.

• Managed cloud: Cloudflare, Daytona, E2B, Modal and Vercel Sandbox. Vercel lists 19 regions, and its snapshots cannot move between regions.
• Bring your own cloud: listed on Daytona's and E2B's enterprise plans. E2B's infrastructure repository is Apache-2.0 licensed and describes itself as the runtime behind its cloud, enterprise and your-own-machine setups.
• Local: Docker Sandboxes runs agents locally or on Docker-managed cloud, and microsandbox is an Apache-2.0 licensed, local-first microVM runtime and library.