What it is

“My app lets users or an LLM run code, and I need somewhere safe to run it.”

This is infrastructure you build into a product, not something your users log into. Your server asks the provider's API for a sandbox, runs the code, collects the result and throws the sandbox away.

The code is untrusted by definition, so isolation is the first question: whether each run gets its own kernel, and what it can reach on the network. The isolation and outbound network pages compare that.

What it needs from a machine

From its own documentation, each line linked to the page it comes from

Machine size

Small. Provider minimums run from 0.125 of a core and 128 MiB on Modal upwards. Battleships' interpreter workload uses 1 vCPU / 2 GiB / 5 GiB and fills 80% of that memory, so 2 vCPU / 4 GiB / 10 GiB is the safer size.

modal.com

Does it stay on?

No. Each run lasts seconds to minutes; 20,000 one-minute runs a month is about 650 a day.

battleships.dev, built by the Boat team

What must survive a restart

Usually nothing. Results go back to your app or your own storage.

battleships.dev, built by the Boat team

How busy it is

About 17% CPU on average in Battleships' interpreter workload. Charging by the second, and only for CPU actually used, both matter here.

battleships.dev, built by the Boat team

Setting it up on each provider

Easiest first. “Without a terminal” means someone who does not type commands can get it running from the provider's website.

ProviderHowWithout a terminal?What it involves
Cloudflare SandboxOfficial guide or templateNoSandboxes started from a Worker, with CPU billed only while working.Cloudflare Sandbox SDK ↗
DaytonaOfficial guide or templateNoSandboxes started from an SDK, billed per second, with $200 of free compute.Daytona docs ↗
E2BOfficial guide or templateNoIts original use: a code-interpreter SDK and per-second billing.E2B docs ↗
ModalOfficial guide or templateNoSandboxes from Python or JavaScript, sized down to a fraction of a core.Modal: sandboxes ↗
TensorlakeOfficial guide or templateNoWrap `sandbox.run()` as a `run_code` tool and keep one sandbox per session so installed packages and written files carry between calls; the Tool Calls page has Claude, OpenAI and OpenAI Agents SDK examples. Pre-install the usual libraries in a snapshot so each session starts warm, and turn egress off or to an allowlist before running model-written code.Tensorlake: tool calls ↗
Vercel SandboxOfficial guide or templateNoFirecracker sandboxes from an SDK, with CPU billed only while working.Vercel Sandbox ↗

Read from each provider's documentation on 29 October 2026. A provider not listed as one click can still be the right home; it means someone has to follow its instructions.

Where to start

Three starting points for different people, each with its catch

The default choice

E2B

Built for exactly this. At the workload below it is about $55 a month at list price, and the free plan's one-time $100 credit covers most of the first two months.

Catch: The free plan limits sessions to an hour and disk to 10 GiB. Concurrency limits are per plan.

e2b.dev ↗

If runs mostly wait

Runtime

CPU is billed only while working, so the same workload is about $13 a month.

Catch: Smaller company, one US region, and a free tier capped at four sandboxes at once.

withruntime.com ↗

If your app already runs on Cloudflare

Cloudflare Sandbox

Started from a Worker next to your code, with CPU billed only while working.

Catch: The smallest size that has 2 vCPU also has 8 GiB of memory, which you pay for. There is a $5 monthly account minimum.

developers.cloudflare.com ↗

Beyond these providers. Anthropic's hosted code-execution tool runs Claude's code for you with no sandbox to manage: 1 CPU, 5 GiB, no internet, 1,550 hours included and then $0.05 per container-hour.

Compare these three head to head: features and cost side by side.

What it would cost

20,000 one-minute runs a month on 2 vCPU / 4 GiB / 10 GiB machines, thrown away after each run; results go to your own storage. The CPU works about 17% of the time. Change any number; open a row for the arithmetic.

Start from

The machine
How it runs
How busy it is

Only providers that bill for CPU actually used look at this. An agent waiting for messages is near 0%; a build or a test run is near 100%.

For providers that put an idle machine to sleep and wake it on a request: the share of its hours it has to be awake. An agent that only answers webhooks can sleep; one that holds a chat connection open cannot.

The AI model (optional)

For most agents the model costs more than the machine. Each message re-sends the agent's instructions and history, so tens of thousands of tokens is normal. Prices are the median of the providers that keep no data, from TokenWatch, read 2026-10-29.

    List prices only, excluding model tokens, egressData the machine sends out to the internet, such as downloads to a user or uploads to another service. Some providers charge per GB; most agents send very little., taxes and anything a provider does not publish. How the numbers are made.

    The features that decide it

    Each page compares every provider, with a source for every row

    1. 01

      Isolation: what kind of computer you get — Every provider says “sandbox”. Underneath, it is a container, a gVisor container, a microVM or a full virtual machine, and that decides what your agent can install, run and break.

    2. 02

      Outbound network: egress, allowlists and static IP — What the agent can reach, what can be blocked, and whether the outside world sees a stable address. This is where an agent that browses meets a firewall that was designed for a web app.

    3. 03

      Ways to drive it — Dashboard, API, SDK, CLI, MCP, SSH, desktop. A provider can have all seven and still be unusable without a terminal, or have three and be genuinely click-driven.

    4. 04

      Billing models — The meter decides your bill more than the hourly rate does. Four shapes are in play: flat per size, per vCPU and per GB, a plan fee that returns as credit, and measured CPU.

    Sources