E2B Pricing Explained: Plans, Limits, and Workload Costs

E2B pricing combines a plan with per-second usage. Hobby is free with a one-time $100 usage credit, Pro is $150 a month, and Enterprise is a custom one-year commitment with a $3,000 monthly minimum. On Hobby and Pro, a running sandbox costs $0.000014 per vCPU-second and $0.0000045 per GiB-second of RAM, which works out to $0.0504 per vCPU-hour and $0.0162 per GiB-hour. Below are typical workload costs and how Beam, Daytona and Modal compare.

E2B pricing plans: Hobby, Pro and Enterprise

E2B, an open-source sandbox platform that gives AI agents isolated Firecracker microVMs for running generated code, sells three plans. Hobby and Pro add the same published per-second usage charges on top, while Enterprise usage is priced in a committed-use contract. The plan decides your limits: how long a sandbox can run before it has to pause, how many run at once, and how fast you can create them. Upgrading to Pro adds no extra credit. It only raises those limits.

E2B bills at the start of each month for the previous month's usage, and the console has a budget page where you can set a spending limit. The full rate card is on E2B's pricing page, and the plan table above comes from its billing and limits docs.

What the E2B free tier covers

The Hobby plan needs no credit card. You get a one-time $100 usage credit, 20 concurrent sandboxes, up to an hour of continuous runtime per sandbox, 10 GiB of disk and community support. The credit doesn't renew. When it runs out and no payment method is on file, E2B blocks every project in the workspace shortly afterward.

Early-stage teams have a second route. E2B's startup program gives approved companies a one-time $20,000 credit plus Pro membership, provided they have raised less than $5 million, were founded less than three years ago and haven't used E2B before.

How E2B sandbox pricing works per second

E2B charges a running sandbox per second for the vCPU and RAM it has allocated, whether or not the code uses them. Disk is included in the plan, and paused or killed sandboxes cost nothing. E2B's docs give the formula directly:

On Pro a sandbox can have 1 to 8 vCPUs and 1 to 8 GiB of RAM, with more on request. E2B's pricing page lists custom CPU and RAM as a Pro feature, although its billing docs give Hobby the same 8 vCPU / 8 GiB ceiling. You set the size when you build a custom template, with cpuCount and memoryMB in JavaScript or cpu_count and memory_mb in Python.

Check the size before you budget, because E2B's own pages disagree on the default. The pricing page lists 2 vCPU and 4 GiB as the default sandbox. The billing docs describe the default as 2 vCPU and 512 MiB, which costs about $0.109 an hour instead of $0.166. Calling get_info() on a running sandbox returns its real cpu_count and memory_mb.

Each E2B sandbox runs in its own Firecracker microVM with its own guest kernel. Sandboxes are CPU-only: there is no GPU option in the SDKs, CLI, API or template definitions, and BYOC deployments work the same way.

What typical E2B workloads cost

At the 2 vCPU / 4 GiB size that E2B's calculator starts from, a sandbox costs $0.000046 per second, or about $0.17 an hour. Short runs are cheap, and the Hobby credit covers a lot of them. An always-on sandbox is only practical on Pro, and at that point the $150 fee is larger than the compute bill.

The per-second figure is 2 × $0.000014 + 4 × $0.0000045 = $0.000046. Multiply by 3,600 and you get $0.1656 an hour.

A few notes on those rows:

• The five-minute batch fits inside Hobby's limits as long as no more than 20 runs overlap. The $100 credit covers about seven batches of that size.
• The always-on row uses 730 hours, the length of an average month, and assumes Pro. On Hobby the sandbox would have to pause every hour, dropping client connections each time, and the $100 credit covers only about 600 hours.
• Even on Pro, an always-on sandbox must pause and resume at least once every 24 hours. Pausing disconnects any client talking to a server inside the sandbox, so plan for reconnects.

E2B limits for high-volume workloads

For high-volume workloads, concurrency is the main limit to plan around. Pro includes 100 running sandboxes, and each self-serve add-on adds 500 more slots for $500 a month, up to 1,100. Past 1,100 you need Enterprise, a one-year committed-use contract with a $3,000 monthly minimum.

That makes the concurrency tiers on Pro work out like this:

• Pro allows 100 concurrent sandboxes for the $150 plan fee.
• Pro+ allows 600 for $650 a month in plan and add-on fees.
• Pro++ allows 1,100 for $1,150 a month, before any usage.

Add-ons take effect as soon as you buy them. They are billed monthly and are non-refundable, but you can remove one to stop future charges.

The other limits matter once you run at scale:

• Creation rate: Hobby can start 1 sandbox per second and Pro can start 5. Filling 1,100 slots from zero at 5 per second takes about 220 seconds.
• API rate limits: listed read endpoints, such as listing sandboxes, snapshots or templates, allow 10 requests per second per project, per endpoint, on Hobby and 20 on Pro. Over the limit, the API returns HTTP 429 with a Retry-After header, and SDK versions from 2.49.1 retry for you.
• Template builds: both self-serve plans run up to 20 builds at once, with no cap on how many templates you keep.
• Forks: one fork call can create up to 20 sandboxes, and the count has to stay below your concurrency limit because the original keeps a slot.

Paused sandboxes don't count toward the concurrency limit. Reinforcement learning rollouts that run many sandboxes in parallel reach the concurrency ceiling quickly, which is one reason we compared E2B and Beam for RL environments separately.

Does E2B charge for paused sandboxes?

No. A paused sandbox isn't billed, doesn't count toward the concurrency limit and is kept indefinitely with its filesystem and, for a default (full) pause, its memory intact. E2B's pricing lists no storage charge for it either. The bigger cost risk is the default: when a sandbox's timeout expires, E2B kills it, and a killed sandbox can't be resumed.

Every sandbox has a timeout, five minutes unless you set another. The lifecycle setting on_timeout defaults to "kill". Setting it to "pause" keeps the state and still stops billing, and auto_resume wakes the sandbox on the next SDK call or HTTP request. This is the Python example from E2B's sandbox lifetime docs:

Pausing has a time cost. E2B's persistence docs put it at about 4 seconds per GiB of RAM, with resume taking about a second, so a 4 GiB sandbox spends roughly 16 seconds saving its state. A pause also resets the continuous-runtime clock, which is how a Pro sandbox outlives the 24-hour limit.

When memory doesn't matter, a filesystem-only pause is lighter: it saves the disk alone, is faster to take, and reboots the sandbox on resume. Snapshots and forks are a separate tool. They capture filesystem and memory by default, and they pause the source sandbox briefly while E2B captures it, which drops any open WebSocket, terminal or command stream. A fork captures one snapshot however many copies you request.

Since paused sandboxes never expire, they pile up. They don't add to the bill, but list them with Sandbox.list from time to time and kill the ones you won't resume.

E2B vs Beam, Daytona and Modal on per-vCPU price

The cheapest CPU sandbox rate among these four is $0.0504 per vCPU-hour, shared by E2B and Daytona. Beam Sandboxes cost $0.0675 and Modal Sandboxes about $0.0710, so for short CPU-only runs E2B is cheaper than Beam. Beam's persistent VMs are the exception, at $0.0252 per vCPU-hour.

CPU units differ between vendors. Modal and Beam Sandboxes bill per physical core, and one core equals 2 vCPU, so the table halves their per-core rates. Modal charges sandboxes at 3x its list price because they run on non-preemptible capacity. Daytona also bills disk at $0.000108 per GiB-hour after the first 5 GiB. Rates come from Daytona's pricing page, Modal's pricing page and Beam's pricing page.

Where E2B costs less

For brief, CPU-only code execution, E2B is cheaper than Beam Sandboxes: about 25% less per vCPU-hour and 30% less per GiB-hour. On the 1,000-run batch that is $13.80 against $18.93. If your agent fires off thousands of short executions and never needs a GPU or a long-lived machine, E2B's rate is hard to beat, and Daytona matches its vCPU and RAM rates exactly. Daytona adds a small disk charge past 5 GiB but lists no plan fee. Modal's sandbox multiplier puts it at the top of the range, which our Modal pricing breakdown covers in more detail.

Where E2B costs more

Persistent machines, plan fees for high concurrency and GPU access are where Beam comes out ahead. Beam has two products for this work. Sandboxes are isolated containers for short-lived code execution, and they can attach a GPU. Virtual machines are persistent CPU microVMs, each with its own kernel.

VMs change the math for long-lived agents. Pause keeps RAM and running processes, stop keeps the disk, and neither one accrues compute charges. VMs also fork, take snapshots, run Docker and systemd, and come with SSH, a browser terminal and an Ubuntu desktop with automation APIs. An idle timeout can pause a VM, and auto-resume wakes it on the next SDK call or request to a published URL. Billing is per second while the VM runs, and the VM docs list the full lifecycle.

Take the always-on row from the workload table. On E2B it costs $120.89 in usage plus the $150 Pro fee, $270.89 a month, with a forced pause every 24 hours. A 2 vCPU / 4 GiB Beam VM at the published rates costs about $0.072 an hour (2 × $0.0252 + 4 × $0.0054), or about $52.56 over 730 hours. VMs have no idle timeout by default, so one keeps running until you stop or pause it. The Developer plan's $20 monthly fee comes back as $20 of credits toward that usage.

Concurrency fees are the second gap. Beam's Team plan, at $89 a month plus usage, allows 1,000 concurrent CPU containers. On E2B self-serve, anything past 600 concurrent sandboxes means Pro++, $1,150 a month in fees for 1,100 microVM slots. At sustained volume, though, E2B's lower rate closes that gap. At 2 vCPU / 4 GiB, E2B costs less in total once usage passes roughly 17,000 sandbox-hours a month, which 1,000 busy sandboxes reach in under a day.

GPUs are the third. E2B has none at any price. A Beam sandbox can attach one, such as an RTX 4090, through the same Sandbox API, and full on-demand H100 machines start at $1.83 an hour with vCPU, RAM and NVMe included.

Starting a Beam sandbox takes a few lines with the beam-client Python package:

For a wider field than these three, our roundup of E2B alternatives compares isolation models, persistence and limits.

Can you self-host E2B to cut costs?

Yes, on a single machine. E2B Embed packages the full Apache-2.0 stack for one Linux x86-64 host with KVM, installed with Docker Compose, Terraform or Kubernetes, from the e2b-dev/runtime repository. Running sandboxes across many machines in your own cloud is BYOC, which E2B operates for Enterprise customers on AWS, GCP and Azure.

Self-hosting swaps the per-second rate for the cost of your own hardware and the time to operate it. Embed is one node by design, so it suits a self-hosted single machine, embedding E2B in a product, or deploying into one customer's tenancy more than a large fleet.

Beam's engine, beta9, is open source under AGPL-3.0 and can be self-hosted too, though it doesn't include every Beam Cloud feature. Beam also offers BYOC on AWS, GCP and Azure, with a management fee of $0.019 per vCPU-hour and $0.009 per GB-hour of RAM on top of your cloud bill. Our guide to self-hosting a code execution sandbox walks through the trade-offs.

FAQ

Does E2B have a free tier?

Yes. The Hobby plan costs $0 and includes a one-time $100 usage credit, 20 concurrent sandboxes, sessions of up to an hour and 10 GiB of disk, with no credit card required. The credit doesn't renew, so ongoing use means adding a payment method or moving to Pro.

How much does an E2B sandbox cost per hour?

A 2 vCPU / 4 GiB sandbox costs $0.000046 per second, about $0.17 per hour. Each vCPU adds $0.0504 an hour and each GiB of RAM adds $0.0162, and Pro adds a flat $150 a month on top of usage.

Does E2B charge for paused sandboxes?

No. Paused sandboxes aren't billed, don't count toward concurrency and stay available until you kill them, with files and (for a full pause) memory intact. The default timeout kills sandboxes rather than pausing them, so set on_timeout to "pause" to keep their state.

What are E2B's limits for high-volume workloads?

Pro allows 100 concurrent sandboxes and 5 new sandboxes per second. Add-ons at $500 a month per 500 slots raise concurrency to 1,100, and anything beyond that needs Enterprise, with custom limits, a one-year commitment and a $3,000 monthly minimum.

Does E2B support GPUs?

No. E2B sandboxes are CPU-only on every plan, including BYOC. GPU work in a sandbox needs another provider, such as Beam, Daytona or Modal.

Is E2B cheaper than Beam?

Per vCPU-hour, yes. E2B charges $0.0504 per vCPU-hour against $0.0675 for Beam Sandboxes, and its RAM rate is lower too. Beam costs less for persistent machines, where VMs run $0.0252 per vCPU-hour, and it's the only one of the two with GPUs.