E2B sandboxes: pricing, lifecycle and alternatives

An E2B sandbox gives an application a remote environment in which to execute code and work with files. To choose a sandbox provider, compare the execution API, session lifetime, concurrency, network controls, retained state and complete cost. A low CPU rate alone does not tell you whether an agent can finish its task reliably.

This guide comes from Lizard. We checked the linked pricing and SDK documentation on 9 September 2026. It compares documented behaviour and an illustrative calculation, not measured provider performance.

What a sandbox adds to an agent

An agent can generate a program without having anywhere appropriate to run it. A sandbox supplies an execution environment separate from the application that coordinates the agent.

The coordinator sends code or commands, collects output and files, and decides what to do next. It must also handle a failed command, a timed-out session and cleanup. Isolation is useful, but access to credentials, external systems and private data still requires a deliberate policy.

E2B's quickstart demonstrates code execution and file access through its SDK. Start with a small task and inspect both output and errors before connecting it to a larger agent loop.

E2B pricing: separate the plan from runtime

E2B lists a free Hobby plan with a one-time $100 credit, sessions up to one hour and 20 concurrent sandboxes. Pro lists a $150 monthly base plus usage, sessions up to 24 hours and a higher concurrency allowance. The plan fee is not the runtime bill. E2B pricing.

For an illustrative workload of 1,000 total running hours at 2 vCPUs and 4 GiB, use the published per-second rates:

CPU:    1,000 × 3,600 × 2 × $0.000014 = $100.80
Memory: 1,000 × 3,600 × 4 × $0.0000045 = $64.80
Runtime subtotal: $165.60
With the $150 Pro base: $315.60 before tax and other charges

This E2B example excludes trial credits, tax, paid concurrency add-ons and other usage. Total runtime spans all sandboxes; check session and concurrency limits separately.

The same compute example on Lizard

Lizard sells Sandboxes by size at a flat price per second. The Small size has 2 vCPUs and 4 GiB of memory, the same allocation as the E2B example, for $0.0162 per hour. CPU, memory, idle time, a 5 GB workspace disk and egress up to 2 TB per account over 30 days are included.

Small sandbox: 1,000 × $0.0162 = $16.20 of usage
Lizard Pro: $19/month, includes $19 of usage
Monthly bill: $19.00

Lizard has the lower compute cost in this example: $16.20 versus E2B’s $165.60. Lizard Pro’s $19 a month, taxes included, covers that usage, so the bill is $19. Compare it with $165.60 on E2B Hobby, or $315.60 with E2B Pro’s monthly base before tax. Neither figure includes extra storage or other services. E2B Hobby has no base fee; do not add Pro’s fee when Hobby meets the requirements.

This is a rate calculation, not a measured performance result. Check limits and retained state before choosing a provider. Sources checked 15 September 2026: E2B pricing and Lizard pricing.

Compare the operating contract

Daytona lists compute, memory and storage separately. Modal's sandbox documentation describes execution, networking and lifecycle controls. Use those specific docs when comparing behaviour; a common word such as “pause” need not mean the same storage guarantee.

Lifecycle

Lizard Sandboxes run short-lived commands and agent tasks as Firecracker microVMs, each with its own kernel. A sandbox that attaches an existing pod-backed Persistent Volume, or restores an older pod snapshot, runs as a Kubernetes pod instead (runc, sharing the host kernel); getInfo().runtime tells you which. Restrict credentials and network access when running code you do not trust.

Create a sandbox, run commands, then call kill. connect attaches to an existing sandbox without changing its state; it does not resume a paused or stopped one. Pause, resume, snapshot and restore are available. Fork works on Firecracker sandboxes (sandbox.fork({ count })); it returns 409 when a volume is attached and 501 in a pod. File watching is not available yet. lizard sandbox ssh opens an interactive shell with your CLI credentials; SSH protocol access is not available.

The SDK and CLI default to a five-minute lifetime. The raw API and dashboard default to no expiration. Set an explicit lifetime: timeoutMs: 0 at creation disables expiration; a positive value sets a deadline. setTimeout accepts 1000–2147483647 ms, not zero. Commands do not reset the deadline. This is not an idle timer.

Files and running processes remain available while the sandbox runs. After it stops, only files written to an attached Persistent Volume at /workspace can be reused by a later sandbox. Without a volume, /workspace is temporary. Each volume attaches to one sandbox at a time and uses node-local storage; export files that must survive node loss.

Each size has a flat hourly price, billed by the second while the sandbox runs, idle time included. Egress is included up to 2 TB per account over a rolling 30 days. A sandbox restored from an older pod snapshot is billed by measured usage. A paused sandbox is not billed; Persistent Volumes bill separately while you keep the data. Pause or kill a sandbox when the task ends.

Sandboxes

A small Lizard SDK example

Install @lizard-build/sdk in a Node project and provide LIZARD_API_KEY through the environment. Replace my-project with a project you can use. This example creates a short-lived environment, runs one command and releases it in a finally block:

import { Lizard } from '@lizard-build/sdk';

const client = new Lizard({ project: 'my-project' });
const sandbox = await client.create('interpreter', { timeoutMs: 300000 });
try {
  const result = await sandbox.process.exec("python -c 'print(6 * 7)'");
  if (result.exitCode !== 0) throw new Error(result.stderr);
  console.log(result.stdout);
} finally {
  await sandbox.kill();
}

The command should print 42. The example illustrates the API and cleanup pattern; it is not a throughput or startup benchmark. Production code should also handle a failed cleanup request and preserve outputs it needs before termination.

Test the workflow, not just the first command

Use the same task and dependency set on each candidate. Record time to a usable environment, command execution time, failures, resource consumption and retained outputs. Separate image preparation from session startup so the comparison measures the same stages.

Then test the cases an agent will encounter: a command that fails, a process that hangs, concurrent sessions, a large output and a session that expires. Confirm the coordinator records enough information to retry safely.

If the output is a production application, deploy it as a service with a normal release process. A sandbox URL and a successful test run are not a substitute for deployment configuration, monitoring and durable data. Our Claude Code deployment guide covers that next step.

FAQ

Is E2B free? Its Hobby plan has no base fee and includes a one-time credit, while runtime has published usage rates. Check the applicable limits and what happens after credit is used.

Is Lizard cheaper for the example above? Yes. Its usage is $16.20, compared with E2B’s $165.60 in usage or $315.60 with Pro’s base. Lizard Pro costs $19 a month and covers that usage, so the bill is $19. Add any extra storage on either host.

Does E2B Pro include unlimited runtime? No. Its base fee and usage charges are separate.

Does pausing Lizard Sandboxes make their state durable? Until you resume it. pause() saves the sandbox's memory and running processes, keeps /workspace on its node and stops billing; resume() brings it back with the same ID. Pausing closes open network connections. After a sandbox stops (kill or expiration), only files written to an attached Persistent Volume at /workspace can be reused by a later sandbox. Each volume attaches to one sandbox at a time and uses node-local storage; export files that must survive node loss.

Which provider is fastest? This guide does not establish a speed ranking. Measure the same image, dependencies, region and readiness condition, and report repeated results rather than a single successful start.