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

The example assumes no applicable credit, paid concurrency add-on or other usage. It uses total runtime across all sandboxes, not the lifetime of one session. Check concurrency and session limits separately. A monthly plan does not make an individual session last for a month.

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.

Pause is not a backup

For Lizard Sandboxes, pause freezes vCPUs and retains memory and running processes in the host's RAM. It does not write a durable disk snapshot of the whole machine. A host failure can therefore lose that paused state.

The sandbox lifetime also continues while paused. The Lizard SDK documents a default five-minute timeout; opting out of expiration is a separate setting. Save important outputs outside the sandbox and set a lifetime that fits the task. See the Lizard SDK and Sandboxes documentation.

Do not build recovery around a claim such as “resume instantly with everything saved” unless you have checked the exact failure case. Test process failure, expired sessions and unavailable hosts as separate events.

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('base', { timeoutMs: 300000 });
try {
  const result = await sandbox.process.exec('node -e "console.log(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.

Does the Pro fee include unlimited runtime? No. The cited E2B pricing separates the Pro base from usage and optional additions.

Does pausing Lizard Sandboxes make their state durable? No. Paused memory stays in host RAM, and the lifetime continues. Export important data and plan for expiration or host failure.

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.