E2B vs Modal: Sandbox Costs, Persistence and Workload Fit

Do not index

E2B vs Modal comes down to how your agent uses resources and what must survive between sessions. E2B suits CPU workspaces with pause/resume state; Modal adds elastic resource billing, GPU sandboxes and a choice of runtimes. If your priority is inexpensive persistent CPU infrastructure, include Agent37 in the same workload test.

A cheap hourly rate can become an expensive application if you reserve too much memory, keep idle sessions running, or lose the state a user expects to recover. Compare a complete task: prepare the environment, execute code, save the result, wait, and resume.

This guide compares the hosted sandbox products using official documentation checked November 10, 2026. Cost examples are calculations, not performance benchmarks. We build Agent37; the provider recommendations below depend on your workload.

E2B vs Modal: which fits your agent?

Choose E2B when a CPU-based execution environment and a documented pause/resume workflow fit your application. Choose Modal when elastic sizing or GPU execution matters, especially if other parts of your application already run there.

Decision	E2B	Modal Sandboxes
CPU billing model	Allocated vCPU and RAM while running	Greater of requested and actual CPU and memory use
Work between sessions	Pause and reconnect to a saved workspace	Filesystem and directory snapshots; experimental memory snapshots
GPU inside the sandbox	CPU-only	Available on the gVisor runtime, subject to preemption
Docker workloads	Docker and Compose template recipes	Use the VM runtime
Runtime planning	Continuous runtime depends on plan	Set a timeout; maximum 24 hours per sandbox

These differences create separate buying decisions. A data-analysis tool may need preserved Python variables. A coding agent may only need its repository and installed dependencies. A training workflow may need a GPU and tolerate retries. Write down which state and resources your application actually needs before choosing a provider.

Compare resource bills before plan fees

E2B's pricing page lists $0.000014 per vCPU-second and $0.0000045 per GiB-second. A specified 2 vCPU, 4 GiB sandbox therefore costs $0.1656 per running hour. That allocation keeps billing while the sandbox waits for a model or user.

Modal's Sandbox rates are $0.00003942 per physical-core-second and $0.00000667 per GiB-second. These are the Sandbox rates, not the lower Function rates. Modal describes one physical core as two vCPUs.

The table models the listed billable resources throughout each period. Modal's one-core row uses its published CPU equivalence for accounting; it does not establish equal throughput across providers. Both comparison rows specify 4 GiB RAM. Storage and other charges are considered separately below.

Resources	Per hour	60 hours	730 hours
E2B: 2 vCPU, 4 GiB	$0.16560	$9.94	$120.89
Modal: 1 physical core, 4 GiB	$0.23796	$14.28	$173.71
Modal: 0.25 physical core, 1 GiB billable throughout	$0.05949	$3.57	$43.43

These are gross usage amounts before plan fees and credits. They exclude model tokens, paid tools, GPU charges, storage additions, network charges and taxes. The 730-hour column is aggregate usage across sessions or sandboxes, not a promise of one uninterrupted session.

The third row illustrates why a fixed-size comparison cannot settle the decision. Modal bills the greater of request and actual use for CPU and memory. Its default request is 0.125 physical cores and 128 MiB, with bursting when host capacity is available. A smaller request can reduce cost, but usage above it still bills. Resource limits cap how far a workload can burst.

The 0.25-core example assumes that CPU and memory are billable at those amounts throughout the period. It is a different resource scenario, not a measured way to run the same job faster or cheaper. If your process holds 4 GiB while waiting, its memory bill does not fall to 1 GiB just because CPU activity stops.

Measure representative usage before choosing a reservation. If a lower request introduces CPU pressure, memory eviction or retries, include that extra work in the cost per completed task.

Add credits, subscriptions and retained storage

E2B Hobby has no monthly base fee and a $100 one-time usage credit. Pro adds $150 per month plus usage. At the specified shape above, 60 hours on Pro is approximately $159.94 before other charges, and 730 aggregate hours is $270.89. The introductory credit is not a monthly allowance.

Modal Starter has no base fee and includes $30 in monthly credits. Team costs $250 per month with $100 in monthly credits. An eligible Starter workload using only $14.28 of covered compute can fit within its monthly credit; other workspace usage consumes the same allowance. Check plan eligibility and included charges before treating gross usage as the invoice. Sources: E2B plans and Modal plans.

E2B's billing documentation lists one-hour continuous runtime on Hobby and 24 hours on Pro. Pause/resume resets that continuous-runtime limit. Its pricing page and billing table currently disagree on Hobby concurrency, showing 20 and 10 respectively. Confirm your account's effective limit before designing a concurrent launch around either number.

E2B lists 10 GiB of included sandbox disk on Hobby and 20 GiB on Pro. Those capacities are distinct from any separate volume product. Modal lists Volumes at $0.09/GiB-month with 1 TiB free; check how your chosen persistence mechanism is billed rather than applying a Volume allowance to every snapshot.

A useful budget separates running resources, retained state, plan fees and model spend. For more detailed calculations, see our E2B pricing guide and Modal pricing guide.

Decide what must survive a pause

E2B's persistence documentation describes preserving both filesystem and memory when pausing. Paused sandboxes remain until explicitly killed, and compute billing stops while paused. Reconnecting resumes the environment, but disconnected network clients still need to reconnect.

There is a recovery caveat: the docs describe a rollout where repeated refusal of a memory auto-pause can fall back to a filesystem-only pause. Files survive, but resume reboots the environment. Keep durable application state on disk and make your startup path recover from that case.

Modal offers several snapshot types. Its current snapshot documentation gives filesystem and directory snapshots a default 30-day retention period, configurable to another duration or no expiry. Memory snapshots expire after seven days and remain experimental.

Those memory snapshots have operational limits: open TCP connections close, snapshotting terminates the sandbox, and an active exec command prevents the snapshot. Background processes launched through exec are not restored correctly. A new memory snapshot derived from an earlier one also inherits the original expiration date.

For a repository-editing agent, saving files and restarting a process may be sufficient. For a long-lived interpreter, losing loaded variables can change the product experience. Test your actual state requirement rather than treating all forms of persistence as interchangeable.

Match Docker, GPUs and network controls

E2B publishes Docker and Docker Compose template examples. A claim that it can only execute isolated Python snippets would be misleading. Its GPU documentation says sandboxes are CPU-only, although code can call external inference APIs.

Modal supports gVisor and VM runtimes. Its sandbox guide directs Docker, FUSE and nested-cgroup workloads to the VM option. Set the runtime explicitly when it is a requirement; leaving it unset lets Modal choose. GPU sandboxes require gVisor and can be preempted. A VM sandbox with a GPU is therefore not a configuration to assume is available.

Isolation also needs an application policy. E2B enables outbound internet by default, with a switch and finer allow/deny rules to restrict it. Modal provides outbound controls for both runtimes and does not give sandboxes the default workspace permissions of Functions.

Keep platform credentials in your trusted controller. Pass only task-scoped credentials into the environment, limit allowed destinations, and authenticate any exposed preview service. Before starting generated code, decide who can execute commands, read artifacts, reconnect and delete the workspace. An isolation boundary does not make every credential inside it safe to expose to the agent.

Where Agent37 belongs in the comparison

Consider Agent37 when your workload needs persistent CPU sandboxes at a low running cost. The current pricing is metered per minute from a prepaid wallet, with no sandbox subscription or seat fee. Models and tools are separate.

For standard gVisor, the published 730-hour rates are $0.80/vCPU, $0.70/GB RAM and $0.09/GB disk. Full VM compute costs 2.5 times the standard rate; disk pricing stays the same.

At an explicitly chosen 2 vCPU, 4 GB RAM and 4 GB disk, standard compute is $4.40 per 730 hours. Retaining the disk for the full period adds $0.36. Running for 60 hours while retaining that disk for all 730 hours costs about $0.72; running for all 730 hours costs $4.76.

For the full VM at the same shape, those totals are about $1.26 and $11.36. If you instead delete the instance after 60 hours, compute plus disk is approximately $0.39 standard or $0.93 VM. These examples exclude model/tool spend and use Agent37's published GB units; they are not hardware-equivalence benchmarks against GiB-denominated competitor rows.

Standard gVisor shares host resources and cannot run a Docker daemon. Choose a full VM for Docker/Compose or workloads needing their own Linux kernel. The Ubuntu VM defaults to 12 GB disk when resources are omitted, making that default approximately $12.08 for 730 running hours.

Awake idle instances still bill compute. Stop or sleep pauses compute while disk continues billing; auto-sleep must be enabled. Keep durable state on disk because wake can fall back to a cold boot. The instance lifecycle reference explains the controls to build into your application.

Run a buying test that includes recovery

Use one representative task with the same dependencies, input and success condition. Record package installation time separately from actual execution. Separate the first run from a warm resume, and count retries as work your application paid for.

Then test the awkward transitions. Interrupt a command midway through writing an artifact. Resume after the user has been away. Expire a session. Verify that another user cannot retrieve its files. Confirm the application can find a saved workspace without accidentally creating and billing a second one.

Keep these acceptance criteria concrete: the final artifact is intact, its owner can retrieve it, the process recovers within your product's tolerance, and cleanup leaves no unintended running resources. Include a storage inventory so forgotten paused environments or snapshots do not accumulate unnoticed.

Compare cost per successful task and per retained user workspace. A recurring free allowance may win for a small application; a lower ongoing infrastructure rate may matter more as retained workspaces grow.

If that workload fits Agent37, create a sandbox and repeat the same acceptance test. Use the measured result to choose the platform and runtime.

Frequently asked questions

Is E2B cheaper than Modal?

In the specified fixed-resource example, E2B has lower gross compute cost. Modal's elastic billing and recurring credits can change the payable amount. Compare your measured resources and required plan, including persistence, rather than one headline rate.

Does Modal support persistent sandboxes?

It supports persisted state through snapshots and storage options. Filesystem retention is configurable; experimental memory snapshots have shorter retention and recovery restrictions. Select the mechanism your application can recover from.

Can both platforms run Docker?

Yes, with the documented environment setup. E2B has Docker/Compose template recipes. Modal directs Docker workloads to its VM runtime. Validate your actual images, mounts and services before migrating.

Are model calls included in sandbox prices?

The compute figures here cover execution infrastructure. Model APIs and paid tools add their own charges. Track them separately so a change in model usage does not hide the effect of a sandbox migration.