E2B Pricing 2026: Plans, Runtime Costs and Examples

Do not index

E2B pricing combines a plan fee with per-second sandbox usage: Hobby has no monthly fee, while Pro costs $150 a month before usage. At 2 vCPU and 4 GiB RAM, compute is $0.1656 per running hour. Agent37 offers a lower list-price option for sustained workloads, with different runtime and storage tradeoffs.

The useful number is your cost per completed job. A cheap five-minute run can become expensive when it leaves a sandbox awake for another hour, or when your application needs a paid concurrency upgrade.

This guide separates those charges and works through three budgets. Prices were checked against official sources on October 22, 2026. The examples are calculations, not performance benchmarks, and exclude model tokens, external tools, taxes, and negotiated discounts.

E2B pricing: what each plan actually buys

Start with the plan that fits your session length and simultaneous workload. Then add compute.

Plan	Monthly plan fee	Continuous runtime limit	Included concurrent sandboxes
Hobby	$0 plus usage	1 hour	20
Pro	$150 plus usage	24 hours	100
Enterprise	Custom plus usage	Custom	Custom

E2B advertises a one-time $100 usage credit for new users, with no card required to start. Its rate card includes 10 GiB sandbox disk on Hobby and 20 GiB on Pro. These are published allowances, not a promise of unlimited storage. Check the current E2B pricing page when selecting your plan.

The $150 Pro fee is not a prepaid compute balance. Upgrading grants no additional usage credit, according to E2B's billing documentation. Budget for the subscription and the resources separately.

That distinction changes a small project's economics. A team needing Pro for its session limit can owe more in plan fees than in compute. An application that fits Hobby can keep its recurring plan fee at zero after the trial credit is spent, while paying for usage.

Calculate runtime from the resources you allocate

E2B's published rates are $0.000014 per vCPU-second and $0.0000045 per GiB-second. Its calculation guide says charges follow allocated resources, rather than measured CPU utilization.

For a chosen 2 vCPU, 4 GiB shape, the arithmetic is:

CPU per hour:    2 x $0.000014 x 3,600 = $0.1008
Memory per hour: 4 x $0.0000045 x 3,600 = $0.0648
Total per hour:                           $0.1656

A process waiting for an LLM response still occupies a running environment. Its low CPU activity does not remove the allocation charge. Count the full time between starting and successfully pausing or terminating the sandbox.

Also verify your template's actual memory allocation. The pricing page marks 4 GiB as a default, while the calculation guide describes a default sandbox with 512 MiB. At 2 vCPU and 0.5 GiB, the same formula gives $0.1089 an hour. Neither figure describes every template. Inspect the allocation returned by getInfo() before forecasting.

This matters when estimating a fleet. Use a separate line for each resource shape, multiply by its aggregate running hours, then sum the lines. A single average can hide a small number of large, long-running environments.

Three monthly budgets you can adapt

The following examples use an explicit 2 vCPU, 4 GiB allocation throughout. They assume usage credits are exhausted, no concurrency add-on, and sandbox disk within the plan's included allowance. External storage is excluded.

Illustrative workload	Aggregate runtime	Compute	Hobby total if limits fit	Pro total
1,000 jobs lasting 5 minutes each	83.33 hours	$13.80	$13.80	$163.80
10 workspaces running 2 hours per day for 30 days	600 hours	$99.36	Requires pauses within session limits	$249.36
730 hours spread across permitted sessions	730 hours	$120.89	$120.89 if each run fits	$270.89

For the first workload, each job costs $0.0138 in compute. Adding Pro raises the fully allocated cost to $0.1638 per job at this volume. At ten times the job count, the same fixed fee contributes one tenth as much per job. The plan fee belongs in your margin calculation even though it is absent from the hourly resource rate.

For the second workload, two uninterrupted hours exceed Hobby's one-hour limit. Use Pro if the process must remain continuously running, or design a valid pause-and-resume workflow. Do not assume that splitting a process is free engineering work.

The third row is a monthly comparison unit. It does not mean one E2B Pro sandbox runs uninterrupted for 730 hours. A production design must respect its plan's continuous runtime limit.

Finally, model failed work. If 10% of attempts repeat the entire five-minute job, 1,000 successful jobs require about 1,111 attempts on average under that assumption. Compute rises from $13.80 to roughly $15.33. Your retry policy, setup time, and cleanup behavior can matter more than rounding an hourly price.

Paused, idle, and deleted are different states

E2B supports pausing with filesystem and memory state preserved. Its persistence documentation says paused sandboxes remain available indefinitely until explicitly killed. That makes pause useful for workspaces that need to resume later.

An idle process inside a running sandbox is different. The environment remains allocated and billable. Treat a successful lifecycle transition as the event that ends a running interval; sending a pause request is insufficient evidence by itself.

E2B documents a case where a pause can be refused because a previous snapshot is still finishing. The sandbox keeps running. If your cleanup handler ignores that error, both your cost estimate and your operational state can be wrong. Retry according to the documented behavior and confirm the resulting state.

Paused sandboxes also do not consume running concurrency slots, and they incur no sandbox billing while paused. The paused-sandbox FAQ makes both points explicit. A fleet of saved workspaces therefore does not need a paid slot for every workspace, provided only a smaller subset runs simultaneously.

Choose deletion when you no longer need the environment. Pause preserves a workspace for reuse; deletion releases it permanently. Your application should make that choice deliberately instead of letting abandoned jobs decide your retention policy.

Auto-resume can create more runtime than you expect

E2B's auto-resume documentation explains how HTTP requests and supported SDK operations can wake a paused sandbox. Auto-resume must be enabled with a compatible pause configuration.

After an automatic resume, the timeout is at least five minutes, or the original longer timeout. Requests and commands do not continually reset a running sandbox's timeout; extending it is a separate operation.

That gives you a concrete budget test. At our 2 vCPU, 4 GiB shape, a five-minute running interval costs $0.0138. If a monitoring system wakes 100 paused environments once per hour for 24 hours, and each remains running for five minutes, that illustrative pattern adds 200 aggregate hours, or $33.12 of compute per day.

This is not an E2B benchmark or a claim that every request causes five billable minutes. It is the result of that specific wake pattern with no earlier manual pause or termination. Review health checks, preview traffic, and background clients when recorded runtime exceeds useful task time.

Concurrency has its own price and capacity limits

Job volume and concurrency answer different questions. A million sequential short jobs can require fewer simultaneous environments than a small batch launched all at once.

E2B sells Pro add-ons of 500 concurrent slots for $500 per month each, reaching a self-service maximum of 1,100 running sandboxes. The concurrency guide says these monthly add-ons are non-refundable, though you can remove them to stop future charges.

One add-on therefore means a $650 monthly fixed commitment including Pro, before compute. Two mean $1,150. Buying capacity does not prepay the runtime consumed in those slots.

As a planning estimate, ten arriving jobs per minute with five-minute average runtime need about 50 concurrently running environments in steady state. Real traffic needs headroom for bursts, slow jobs, and retries. Queueing a burst may be cheaper than buying a larger ceiling if the extra wait is acceptable.

Creation throughput is another limit: E2B's billing docs list one sandbox creation per second on Hobby and five per second on Pro. A plan that admits 100 running sandboxes does not necessarily start all 100 instantly. Separate admission limits, startup throughput, and monthly spend in your capacity review.

Compare Agent37 with the right runtime and disk size

Agent37 provides standard gVisor sandboxes and full VMs. For developers whose agents spend much of their time waiting on model or tool responses, the standard runtime can reduce the cost of keeping an environment available.

The Agent37 pricing page lists standard monthly-equivalent rates of $0.80 per vCPU, $0.70 per GB RAM, and $0.09 per GB disk, based on 730 hours. Compute meters while running, including idle time; disk meters while retained. Billing is by the minute, with no sandbox subscription or seat fee.

Here is a scoped comparison for 2 vCPU and nominal 4 GB/GiB memory. E2B specifies GiB; Agent37 labels its memory GB. These are advertised allocations, not proof of equivalent throughput or isolation.

Configuration	60 running hours in a 730-hour month	730 running hours
E2B Hobby, 4 GiB RAM, included 10 GiB disk	$9.94	$120.89
E2B Pro, 4 GiB RAM, included 20 GiB disk	$159.94	$270.89
Agent37 standard gVisor, 4 GB RAM, 4 GB disk	$0.72	$4.76
Agent37 full VM, 4 GB RAM, 4 GB disk	$1.26	$11.36

Both Agent37 rows retain the 4 GB disk for all 730 hours, including stopped time. E2B totals include the applicable plan fee and assume runs fit the plan limits. All rows exclude credits and model/tool costs. Disk capacities differ, so these are transparent configuration examples, not identical bundles.

The standard Agent37 calculation is (2 x $0.80 + 4 x $0.70) x running_hours / 730 + 4 x $0.09. The VM multiplies compute by 2.5 and keeps the same disk rate. Keeping every number visible lets you substitute your own workload.

Runtime requirements can override the price advantage. Standard gVisor cannot run a Docker daemon. Agent37's VM option supports Docker with its own Linux kernel; its Ubuntu template defaults to 12 GB disk when resources are omitted. That default costs $12.08 over 730 hours, rather than the explicit 4 GB disk example above. E2B also documents Docker and Compose templates, so Docker support is not exclusive to Agent37.

For a rarely used workspace, E2B's free paused retention can be attractive. Agent37 continues charging for retained disk. For sustained running time, Agent37's lower resource rates deserve a workload test. Use the broader E2B alternatives comparison if you need a provider shortlist.

Turn the estimate into a deployment decision

Pick one representative job and measure its complete lifecycle: setup, execution, model waits, output collection, and cleanup. Record peak memory and whether the workload needs Docker or special kernel features. Then repeat with a realistic batch rather than extrapolating from a hello-world command.

Compare cost per successful result and completion time together. A cheaper environment that takes substantially longer can erase part of the apparent saving. Conversely, a premium CPU allocation offers little value when nearly all elapsed time is a remote model request. Neither provider's rate card proves the answer for your application.

E2B is worth keeping when its SDK, lifecycle behavior, and free paused retention already fit your system. Price the required plan and concurrency capacity honestly. Agent37 is worth testing when ongoing sandbox compute is a meaningful expense and its runtime meets your requirements.

To test that budget, create an Agent37 sandbox and follow the instance API documentation. Choose the runtime first, set the disk size explicitly, and enable auto-sleep or stop the instance when finished. Use your measured running hours to decide what to deploy.

E2B Pricing in 2026: Plans, Runtime Costs, and Budget Examples