E2B sandboxes: what they cost, and what else runs agent code

An E2B sandbox is an isolated VM your AI agent runs untrusted code in. You create one from the SDK, execute code, read files, and kill it. E2B bills $0.000014 per vCPU-second and $0.0000045 per GiB-second — $0.0504 per vCPU-hour and $0.0162 per GiB-hour — with a free Hobby tier of $100 in one-time credit and a Pro tier at $150 a month plus usage. The alternatives worth pricing against it are Daytona, which publishes the same vCPU and memory rates to the digit but meters disk on top and charges no monthly plan fee, Modal, which charges about 1.4× more per vCPU and bills a sandbox for as long as it runs, and Lizard Sandboxes at $0.0278 per vCPU-hour.
Written 20 August 2026, against published price lists.
What an E2B sandbox actually is
A cloud VM with an SDK in front of it. Your agent writes code it does not trust — code a language model generated, code a user pasted — and runs it somewhere that cannot reach your infrastructure. E2B gives that VM a filesystem, a process API, network access, and a code-interpreter mode that keeps a Python or JavaScript session alive between calls, so variables persist across executions the way they do in a notebook.
The job it does is narrow and real. Without a sandbox, "let the agent run this" means running it on your own machine or your own server, and one bad rm -rf later you understand why the category exists.
What E2B costs
| Tier | Price | What you get |
|---|---|---|
| Hobby | Free | $100 of one-time credit, 20 concurrent sandboxes, 1-hour session limit, 10 GiB storage |
| Pro | $150 a month plus usage | 100 concurrent sandboxes (500-slot add-ons at $500 a month each raise this to 1,100), 24-hour sessions, 20 GiB storage |
| Ultimate (Enterprise) | Custom | "Contact us for custom solution with special pricing" |
Compute meters per second: $0.000014 per vCPU-second and $0.0000045 per GiB-second, which is $0.0504 per vCPU-hour and $0.0162 per GiB-hour. Sandboxes come in 1, 2, 4, 6 or 8 vCPU sizes, with any even memory value from 512 MiB to 8,192 MiB. The default is 2 vCPU and 512 MiB; Hobby caps at 8 vCPU and 8 GiB, and Pro goes higher on request. A 2 vCPU, 4 GiB sandbox alive for one hour costs about $0.17.
Where the tier limits bite
The rate is rarely what forces a decision. These usually are.
Concurrency. Twenty at once on Hobby is enough for development and not enough for a product. If a hundred users can each trigger an agent run, you are on Pro from the first busy afternoon.
Session length. The published limit is continuous runtime: one hour on Hobby, 24 on Pro. Pausing resets that clock. E2B keeps a paused sandbox — filesystem, memory, running processes — indefinitely, does not bill it, and does not count it against your concurrency, so an overnight gap is a pause rather than a lost session. Set onTimeout: 'pause' at create and it parks itself.
The jump between tiers. Free to $150 a month is a real step for a product still finding its shape, and the step from 100 concurrent sandboxes to 1,100 is another $1,000 a month on top.
The others cap differently. Daytona sets no session limit and no fixed sandbox count — its free tier is a pool of 10 vCPU and 30 GiB you split as you like, with a per-sandbox ceiling of 4 vCPU, 8 GB and 10 GB of disk. Lizard's free tier is the tightest on concurrency: one sandbox at a time until you top up.
E2B, Daytona, Modal and Lizard on published rates
| Provider | Compute rate | Memory rate | Billed while idle | Free to start |
|---|---|---|---|---|
| E2B | $0.0504 per vCPU-hour | $0.0162 per GiB-hour | While running, yes — allocated vCPU and RAM bill whether or not the sandbox works. Pause, kill or timeout stops it at once. | $100 one-time credit, no card |
| Daytona | $0.0504 per vCPU-hour | $0.0162 per GiB-hour | Compute only while started. Stopped or paused bills reserved disk only; archived bills nothing. Auto-stops after 15 min idle by default. | $200 of credit, no card |
| Modal Sandboxes | $0.1419 per physical core-hour, which is $0.0710 per vCPU-hour — a Modal core is 2 vCPU | $0.0240 per GiB-hour | Yes — max(requested, used) for the whole running life, floor 0.125 cores. idle_timeout terminates rather than pauses. | $30 a month of credit on Starter |
| Lizard Sandboxes | $0.0278 per vCPU-hour, fixed 4 vCPU per sandbox | $0.0139 per GB-hour — 4 vCPU and 4 GB together come to $0.167 an hour | Running: metered on actual CPU and memory. Paused: nothing at all. | $5 of credit, no card, 1 concurrent sandbox |
Compute and memory only. Storage differs by vendor: E2B bundles it (10 GiB Hobby, 20 GiB Pro), Daytona charges $0.000108 per GiB-hour past 5 GiB free, Modal $0.09 per GiB-month past 1 TiB free, Lizard $0.000216 per GB-hour from the first GB. Of the four, only Lizard publishes an egress rate: $0.05 per GB. On a network-heavy agent that can exceed the compute bill.
Read that table twice before drawing a conclusion. Modal quotes per physical core, and a Modal core is two vCPU, so $0.1419 a core-hour is $0.0710 a vCPU-hour — about 1.4× E2B, not the 2.8× the headline figures suggest. Modal bills a sandbox at whichever is higher, the resources you asked for or the resources you used, for as long as it runs, with a floor of 0.125 cores; its idle_timeout terminates an inactive sandbox rather than pausing one. E2B and Daytona publish the same vCPU and memory rates to the digit, but the rest of the two price lists differs: Daytona meters disk past the first 5 GiB and charges no plan fee, E2B bundles disk and charges $150 a month for Pro, and Daytona starts you with $200 of credit to E2B's $100. The compute meter is a wash. The plan fee is not.
Northflank publishes lower still, at $0.01667 per vCPU-hour, on a platform aimed more at teams running their own infrastructure.
What to check before you pick
Boot time. If a sandbox takes seconds to start, you will build a warm pool, and a warm pool is a bill plus a bug source. Lizard publishes sub-100 ms cold starts: every node pre-builds a golden snapshot per template, so create is a restore rather than a cold boot. E2B resumes a paused sandbox in about a second.
Pause and resume, with state. The difference between "my agent session survived the night" and "my agent reinstalled its dependencies again". Pause freezes the micro-VM: memory, filesystem and running processes stay as they were, and resume picks up where it stopped. Check where that state is held, too — Lizard keeps it in the host's RAM, so a paused sandbox resumes almost instantly but does not survive a host failure; E2B trades the other way and persists the pause to disk. Check what the expiry does while paused. On Lizard the countdown is suspended: a paused sandbox is not reaped, and resuming pushes the expiry out by however long the pause lasted, so the five-minute SDK default measures runtime rather than wall-clock. One gap is worth knowing — the node agent's startup sweep reads the original expiry without checking the pause, so a self-update mid-pause can still collect a sandbox whose time had run out. Pass timeoutMs: 0 to opt out of expiry entirely if the sandbox has to survive that. E2B keeps a paused sandbox indefinitely; Daytona VM sandboxes pause too.
Isolation model. The four differ here more than anywhere else, and the pricing pages do not say so. E2B runs every sandbox in a Firecracker micro-VM with its own kernel, and so do Lizard Sandboxes. Modal Sandboxes run on gVisor, a user-space kernel that intercepts system calls — a real boundary, but not hardware virtualisation; a full VM runtime is a separate beta you opt into. Daytona sandboxes run as Linux containers by default, with a VM class you pick per sandbox and can only create from a VM snapshot. For code you did not write, check which of the three the rate you are quoted actually buys.
A path to production. Most sandbox products end at the sandbox. If the agent builds something that works, you still have to deploy it somewhere else. On Lizard the CLI ships inside the sandbox. Give it an API key — export LIZARD_TOKEN=liz_…, with the key minted outside the sandbox by lizard keys create <name> — then lizard up --project <project> deploys the working directory as a persistent service with a domain and TLS, on the same platform and the same bill. The --project flag matters here: inside a sandbox the CLI runs headless, and headless it will not create a project for you.
Language coverage in the SDK. TypeScript and Python are table stakes. Check what else you need before you commit.
Lizard Sandboxes
import { Sandbox } from '@lizard-build/sdk';
const sandbox = await Sandbox.create('base', { project: 'my-project' });
const { stdout } = await sandbox.process.exec('python train.py');
console.log(stdout);
await sandbox.pause(); // vCPUs frozen; memory, filesystem and processes kept
Each sandbox is a Firecracker micro-VM with its own kernel, filesystem, network, and process namespace — hardware isolation, sized down to one task. Two templates ship built in: base, with Debian, Node.js 26, and the Lizard CLI, and code-interpreter-v1, with Python 3.14 and Node.js 26 behind a code-execution HTTP API.
Sandboxes are a fixed size, 4 vCPU and 4 GB, because create restores a golden snapshot rather than booting a VM you sized. At the rates above that is $0.167 an hour per sandbox, whatever the workload.
Three things follow from the golden-snapshot design:
- Pause is not stop. Pause freezes the vCPUs. A paused sandbox keeps its memory and its running processes in the node's memory, and resume picks up where it stopped rather than starting a new session.
- Volumes outlive the sandbox. Attach one and anything written under
/datasurvives after the sandbox is gone. - A working sandbox becomes a service. Give the bundled CLI an API key and run
lizard up --project <project>, with no Dockerfile required.
Billing is per second on measured use, at the same rates as the rest of the platform: $0.0278 per vCPU-hour, $0.0139 per GB-hour, $0.000216 per GB-hour of sandbox disk — charged whether or not you attach a volume — and $0.05 per GB of egress.
Run agent code in a micro-VM
Free to start with $5 of credit and no card.
Get started free → lizard.build/login
FAQ
What is an E2B sandbox? An E2B sandbox is an isolated cloud VM that an AI agent runs untrusted or generated code in, controlled from a Python or TypeScript SDK. It gives the agent a filesystem, a process API, network access, and a code-interpreter mode where a Python or JavaScript session keeps its variables between calls.
How much does E2B cost? Compute meters at $0.000014 per vCPU-second and $0.0000045 per GiB-second — $0.0504 per vCPU-hour and $0.0162 per GiB-hour. The Hobby tier is free with $100 of one-time credit, 20 concurrent sandboxes, and a 1-hour continuous runtime limit. Pro is $150 a month plus usage, with 100 concurrent sandboxes and 24-hour sessions; 500-slot concurrency add-ons cost $500 a month each.
What are the best E2B alternatives? Daytona publishes the same vCPU and memory rates and a similar SDK, meters disk on top, and charges no monthly plan fee. Modal Sandboxes cost about 1.4× more per vCPU once you account for a Modal core being two vCPU, and bill for the sandbox's whole running life. Lizard Sandboxes are the lowest of the rates compared here at $0.0278 per vCPU-hour, freeze the micro-VM on pause, and ship a working sandbox into a deployed service from the CLI that is already inside it. Northflank publishes lower still, at $0.01667 per vCPU-hour.
Is E2B or Modal cheaper for agent sandboxes? E2B is $0.0504 per vCPU-hour, metered on allocated resources while the sandbox runs; pause, kill or timeout stops the meter at once. Modal is $0.1419 per physical core-hour, which is $0.0710 per vCPU-hour, billed at whichever is higher — the resources you requested or the resources you used — for the whole running life, with a floor of 0.125 cores. Per vCPU-hour, E2B is cheaper. Neither stops charging a running sandbox that sits idle, so the lever on both is pausing or terminating it, not leaving it open.
Do I need a sandbox to run AI-generated code? If the code came from a model or a user and touches a filesystem, a network, or a shell — yes. The alternative is executing it on your own machine or inside your own service, where a mistake or an injection reaches your data. A hardware-virtualised micro-VM is the boundary that makes the risk bounded rather than open-ended.
Can a sandbox keep state between agent runs? Only if the platform preserves it. E2B pauses a sandbox, saves filesystem and memory to disk, keeps it indefinitely and unbilled, and resumes in about a second. Lizard pause freezes the micro-VM and keeps memory, filesystem and running processes in the host's RAM rather than on disk; the expiry countdown is suspended while paused and pushed out by the pause duration on resume, so a pause does not eat the sandbox's remaining life. Create it with timeoutMs: 0 to opt out of expiry altogether. Without either, every resume means reinstalling packages and rebuilding caches.
How do I turn a sandbox into a production app? On Lizard, give the bundled CLI an API key and run lizard up --project <project> from the sandbox's working directory: it deploys the code as a persistent service with a generated <word>-<word>-<hash>.<region>.onlizard.com domain and TLS, with no Dockerfile required. On sandbox-only products, you export the code and deploy it somewhere else.
Sources
Build with AI. Ship with Lizard.
You don't need a platform team to go live. Your whole cloud, one CLI command away.
No credit card required