Comparison · checked
Ephemeral vs E2B
E2B is a cloud sandbox for code your own agent produces: an isolated Linux VM that your application creates and drives through E2B's Python or JavaScript SDK, while the agent and its model calls are yours to run, in your code or inside the sandbox. Ephemeral runs a complete background agent task instead: your prompt, files and allowed connections go in, a fresh microVM does the work with a budget reserved up front, and the machine is destroyed when it finishes.
As of October 22, 2026, E2B's Pro plan costs $150 a month plus usage at $0.000014 per vCPU-second and $0.0000045 per GiB-second of memory, and its free Hobby plan comes with a one-time $100 usage credit[1]. Ephemeral charges $0.005 per run plus $0.0002 per second of run time, with model calls at the provider's price plus 15%, from prepaid credits with no subscription.
Side by side
| Feature | Ephemeral | E2B |
|---|---|---|
| Isolation unit | A fresh microVM for every run, destroyed when the run ends. No machine, file or process is shared between runs. | An isolated Linux VM per sandbox.[2] |
| Who runs the agent loop | Ephemeral. You send a prompt, input, files and the connections it may use; the agent runs inside the microVM with the model you choose and returns the output. | You do, in your application or in an agent you install in the sandbox. E2B provides the sandboxes in which agents execute code, process data and run tools.[3] |
| Credentials | Never enter the machine. Ephemeral holds HTTP API and MCP server credentials, adds them outside the machine, allows only the HTTP methods or MCP tools you list, and removes credential values from responses. | Stored secrets are added by an egress proxy, outside the sandbox, to outbound HTTPS requests to hosts with a matching rule. Values passed as environment variables are readable inside the sandbox.[4] |
| Spending control | A hard budget per run, reserved from prepaid credits before it starts. A model call or web request that would go past it is refused. | Spending limits, set on the budget page of the dashboard.[5] |
| Scheduling | Built in: cron schedules in any IANA time zone start saved workflows. | No scheduler in the documentation; start sandboxes from your own scheduler.[6] |
| Callbacks | A signed POST (HMAC-SHA256) with the run to your server when the run finishes. | Webhooks for sandbox lifecycle events (created, updated, paused, resumed, checkpointed, killed), signed with a secret you set.[7] |
| Zero data retention | A per-run setting: only model endpoints that neither keep nor train on requests, events deleted minutes after the run, output returned once. 10% more on the hosted service. | Not applicable: E2B does not make the model calls. Your model provider's terms apply.[3] |
| Self-hosting | A licensed edition in your own AWS account, from $490 a month or $4,900 a year (Team plan, 14-day free trial). | BYOC for Enterprise customers: E2B deploys and operates sandboxes in your own cloud account and VPC. E2B Embed, an open-source (Apache-2.0) runtime for one machine, can be self-hosted.[8] |
| Where it runs | Hosted in Japan, where run data is stored. The self-hosted edition runs in your own AWS account. | E2B Cloud, or your own cloud account with BYOC.[8] |
| Pricing model | Prepaid credits from $5, no subscription and no free credit: $0.005 per run plus $0.0002 per second of run time, model calls at the provider's price plus 15%, $0.001 per web fetch and $0.015 per web search. | Plan fee plus per-second usage: Hobby $0 with a one-time $100 credit, Pro $150 a month, Enterprise custom with a $3,000 monthly minimum. $0.000014 per vCPU-second, $0.0000045 per GiB-second of memory.[1] |
| Longest session or run | 1 hour: the timeout is 1 to 3,600 seconds, 300 by default. | 1 hour of continuous runtime on Hobby, 24 hours on Pro, custom on Enterprise. Pausing resets it.[5] |
| State between sessions | None by design: every run starts clean. Its output and events are kept for 30 days; uploaded files stay until you delete them. | Pause and resume keeps the filesystem and memory; a paused sandbox is kept until you kill it. Snapshots and volumes are also available.[9] |
| GPUs | None in the machine. Models run at AI model providers; the microVM runs the agent and its tools. | None: sandboxes are CPU-only.[10] |
| Languages and SDKs | An HTTP API with an OpenAPI description, a CLI for macOS, Linux and Windows, and an MCP server. No language-specific SDK. | Python and JavaScript/TypeScript SDKs, a CLI and an API.[3] |
The prices are not like for like. E2B's rates pay for the sandbox only: you run the agent loop, and its model calls are billed by your model provider. Ephemeral's run fee and per-second rate pay for the machine and the agent loop together, and model calls are billed through Ephemeral at the provider's price plus 15%. See the pricing page for an estimator and measured runs.
Which to choose
Choose E2B when…
- You already run an agent loop and want a sandbox it can call to execute code, from Python or JavaScript.
- A session must outlast an hour, or pause with its memory and files and resume later.
- A user works with the same sandbox over many turns, as in a code interpreter or a coding agent.
- You want to run the open-source runtime on your own machine, or have E2B operate sandboxes in your own cloud account.
Choose Ephemeral when…
- You want to hand over a whole task (prompt, files, connections and budget) and get the result back, without building and hosting the agent loop.
- The agent must call your APIs or MCP servers with only certain HTTP methods or MCP tools allowed, not just certain hosts.
- Each run needs a hard spending limit, reserved before it starts, covering model calls, web access and run time together.
- Work should start on a cron schedule in a given time zone and report back with a signed callback.
- Sensitive runs need zero data retention, or run data should be stored in Japan.
What this comparison does not cover
This page compares published features, limits and list prices as E2B and Ephemeral state them on October 22, 2026. It does not measure speed, start-up time or reliability, and it leaves out enterprise and negotiated pricing as well as E2B's templates, snapshots and volumes in depth, its SOC 2 and HIPAA programmes, and its concurrency add-ons. Prices and plans change, so check the sources before you decide. If something here is wrong or out of date, tell us through the support page and we will correct it.
Sources
- https://e2b.dev/pricing, checked
- https://docs.e2b.dev/sandbox, checked
- https://docs.e2b.dev/, checked
- https://docs.e2b.dev/secrets, checked
- https://docs.e2b.dev/billing, checked
- https://docs.e2b.dev/llms.txt, checked
- https://docs.e2b.dev/sandbox/lifecycle-events-webhooks, checked
- https://docs.e2b.dev/byoc, checked
- https://docs.e2b.dev/sandbox/persistence, checked
- https://docs.e2b.dev/faq/gpu-support, checked
Ephemeral's side comes from its pricing page, whose prices it shows as they are today, and from its documentation on security and data, runs, connections, budgets and billing, schedules, callbacks, self-hosting, files and the CLI.
More comparisons
- Ephemeral vs DaytonaDaytona fits long-lived sandboxes your own agent controls, including GPUs, Windows machines and five SDK languages.
- Ephemeral vs Modal SandboxesModal Sandboxes fit teams already building on Modal in Python who want sandboxes beside their functions and GPUs.
- Ephemeral vs your own serversYour own servers fit when you need full control of the runtime, GPUs, long-lived processes or a network with no outside access.