E2B is the more complete sandbox product, with a Firecracker microVM for every sandbox and pauses that keep running processes alive. Nodus Sandboxes fit better when the agent that runs code also trains or evaluates models, because sandboxes and GPU jobs share one account and one budget. At listed rates, a 2 vCPU, 4 GiB sandbox on Nodus also costs about a fifth of what it does on E2B.
Nodus is our product, so read this as a vendor's comparison and check the links: each E2B claim points to E2B's own pricing page or docs, and the arithmetic is shown. There is also a section on where E2B is the better pick.
How do Nodus and E2B sandboxes compare at a glance?
| E2B | Nodus | |
|---|---|---|
| How you pay | Per second for vCPU and RAM while running, plus a plan: Hobby $0, Pro $150 a month | Prepaid credits, with listed hourly rates for CPU and memory sizes |
| Isolation | A Firecracker microVM with its own kernel for each sandbox | A container behind a user-space kernel that filters system calls, on machines that serve one organization at a time |
| Sizes | 1 to 8 vCPU and 1 to 8 GiB, more on Pro by request | 0.25 to 64 vCPU and 128 MiB to 256 GiB |
| GPUs | None, sandboxes are CPU-only | No GPU sandboxes yet; GPU Jobs, Workspaces and training (Beta) in the same account |
| Outbound network by default | Open, with allow and deny lists | Denied, with an allow list or open access as options |
| Default end of a sandbox | Killed 5 minutes after creation unless you extend the timeout or set it to pause | Stops after 5 idle minutes and keeps /workspace; deleted 24 hours after creation unless you raise maxLifetime (up to 720 hours) |
| What a pause or stop keeps | Files and memory, so running processes survive | Files; processes start fresh |
| Longest continuous run | 1 hour on Hobby, 24 hours on Pro; pausing resets the clock | Until it goes idle, you stop it, maxLifetime passes or a spending limit stops it |
| Inbound access | A public URL for each port, open to anyone with the URL unless you restrict it | No public inbound traffic; nodus port-forward through your signed-in session |
| Sandbox limit | 20 running on Hobby, 100 on Pro, up to 1,100 with add-ons | 10 live sandboxes (stopped ones count) before your first credit purchase, 100 after |
| Free credit | $100 once, on Hobby | $30 once for a new org, valid for 30 days |
Sources: E2B pricing, billing and limits, security, sandbox lifetime, persistence, internet access and public URLs; the Nodus pricing page, Sandboxes guide and Sandbox isolation. Checked October 14, 2026.
How is each sandbox isolated from other customers?
E2B draws the boundary at the hypervisor. Each sandbox is a Firecracker microVM with its own kernel, and sandboxes never share a kernel, filesystem or memory with another customer's.
Nodus stacks several layers instead. System calls go through a user-space kernel that passes only a small, filtered set to the host. Each sandbox gets its own network namespace with a default-deny firewall that always blocks private ranges and cloud metadata addresses.
A cgroup holds CPU and memory to what you asked for and caps processes at 256. Commands run as a non-root user with no Linux capabilities.
The biggest difference is tenancy. A Nodus machine serves one organization at a time, and an empty machine is destroyed after 10 minutes rather than handed to someone else. Code that escaped a Nodus sandbox would land on a machine holding only your own work.
On paper a microVM is the stronger single boundary. If your security review asks for hardware virtualization by name, that settles it in E2B's favor.
What happens when an agent forgets to clean up?
This is where the two products behave most differently, and it is the failure you will actually hit. Agents start sandboxes and then crash, or sit waiting on a human.
E2B's timeout is a clock that starts at creation, defaults to 5 minutes, and restarts when you call set_timeout(). When it runs out, the default is to kill the sandbox, and a killed sandbox cannot be resumed. An agent that spends six minutes cloning a repo and installing dependencies with default settings loses the sandbox at minute five.
Nodus counts idle time instead. A running command, even a silent one, keeps the sandbox busy. After 5 minutes with no command, file request or terminal input, it stops, saves /workspace and stops charging for compute. The next command starts it again with the files back.
Here is what each product's documented defaults do in three common cases:
| If you change nothing | E2B | Nodus |
|---|---|---|
| A 6-minute install | Killed at 5 minutes | Finishes; each command may run 10 minutes by default |
| The agent goes quiet for an hour | Killed at 5 minutes, state gone | Stopped at 5 idle minutes, /workspace kept |
| Nobody ever comes back | Gone at 5 minutes | Deleted 24 hours after creation |
Our rule for both: set the end-of-life behavior explicitly on day one. On E2B, create sandboxes with lifecycle={"on_timeout": "pause"} and a timeout longer than your slowest step, since a paused sandbox is kept until you kill it. On Nodus, set maxLifetime to the longest a session should last, plus a maxCostUSD cap, so a forgotten sandbox ends on a date and a dollar amount you chose.
Which is cheaper for a fleet of agent sandboxes?
Nodus is cheaper at listed rates, by roughly 4.6 times for E2B's default size of 2 vCPU and 4 GiB. E2B charges $0.000014 per vCPU-second and $0.0000045 per GiB-second. For 2 vCPU and 4 GiB that is 2 x $0.0504 + 4 x $0.0162 = $0.1656 per hour. The Nodus pricing page lists the same size at $0.0357 per hour.
Here is what a month of busy sandbox time costs at each rate. The Pro column adds E2B's $150 plan fee, which you need for more than 20 sandboxes at once or for runs over an hour without pausing.
| Sandbox-hours in a month | E2B usage | E2B usage plus Pro | Nodus at the listed rate |
|---|---|---|---|
| 200 (a prototype) | $33.12 | $183.12 | $7.14 |
| 2,000 (10 sandboxes, 200 hours each) | $331.20 | $481.20 | $71.40 |
| 20,000 (100 sandboxes, 200 hours each) | $3,312.00 | $3,462.00 | $714.00 |
Prices checked October 14, 2026, on the E2B pricing page and the Nodus pricing page.
Two things the table leaves out. Both free credits are one-time, so we ignored them. Stopped Nodus sandboxes keep their files as storage, while E2B includes sandbox storage in every plan at no extra cost.
On either product, the cheapest sandbox-hour is the one you do not run. Both stop charging for compute when a sandbox is paused or stopped, so stop sandboxes that sit waiting on a model or a person.
Can the same agent also run GPU jobs?
On E2B, no. Its pricing page says sandboxes are CPU-only and there are no GPU sandboxes, so GPU work needs a second platform with its own keys and its own bill.
Nodus has no GPU sandboxes yet either, but the same account runs GPU Jobs and, in Beta, training. An agent can test generated code in a Sandbox, then price a capped GPU run before starting it:
nodus run --dry-run --gpu L4 --max-cost 2 --timeout 30m -- python train.py
Without --dry-run, the same command starts the Job.
Reinforcement learning is where this pays off most. A Nodus TrainingJob (Beta) runs program graders in grading Sandboxes that Nodus creates for it, with no network access, and their cost counts toward the TrainingJob's own maxCostUSD. Generated code, grading and GPU training then sit under one budget instead of two. We cover how to set those limits in how to stop an AI agent from overspending on GPUs.
Can Claude Code, Codex or Cursor drive each one?
Yes, from different directions. E2B is built to host the agent, with guides for running Claude Code, Codex and Amp inside a sandbox. Its MCP gateway gives code in the sandbox access to tools from the Docker MCP Catalog.
Nodus starts from the agent you already run on your laptop. nodus mcp install claude (or cursor, or codex) adds the Nodus MCP server to its config. The server's exec and files tools run commands in a Sandbox, up to 300 seconds per call, and read and write its files. The setup is in how to give Claude Code, Codex or Cursor GPUs with MCP.
When is E2B the better choice?
E2B is the better choice in these cases:
- You need processes to survive a pause. E2B saves memory as well as files, so a Jupyter kernel, a dev server or loaded variables are still there on resume. Nodus restores files and starts processes fresh.
- You want to fork a live sandbox. E2B snapshots capture filesystem and memory and can boot new sandboxes from that exact state. Nodus filesystem snapshots are in Beta and cannot start a sandbox yet.
- You need a public preview URL for an app the agent built, or a Linux desktop for a computer-use agent. Nodus accepts no public inbound traffic and does not offer desktop sandboxes.
- Your buyer asks for compliance paperwork. E2B is SOC 2 Type II and signs HIPAA BAAs on Enterprise plans.
- You want to run it yourself. E2B's runtime is open source under Apache-2.0, and Enterprise plans offer deployment into your own AWS, Google Cloud or Azure account.
- You need options the Nodus Python SDK does not support on Sandboxes yet, such as
volumes=andports=.
If your agents only run code, never touch a GPU and the sandbox bill is small, E2B is the safe default. Nodus earns its place when the bill grows or GPU work enters the picture.
How do you move E2B sandbox code to Nodus?
The calls map almost one to one. Here is a typical E2B snippet that writes a file, runs it and cleans up:
from e2b import Sandbox
sbx = Sandbox.create(timeout=600)
sbx.files.write("/home/user/solution.py", code)
result = sbx.commands.run("python /home/user/solution.py")
print(result.stdout)
sbx.kill()
The Nodus version, after pip install nodus-compute and nodus login:
import nodus
sb = nodus.Sandbox.create(cpu=2, memory="4Gi", idle_timeout="5m", max_cost=1)
try:
with sb.open("/workspace/solution.py", "w") as f:
f.write(code)
p = sb.exec("python", "/workspace/solution.py")
print(p.stdout.read())
p.wait()
finally:
sb.terminate()
Two changes catch people out. The working directory is /workspace, not /home/user. Outbound network is off, so code that runs pip install needs network=nodus.Egress.open() in create.
FAQ
How does an agent reconnect to its sandbox after it restarts?
On Nodus, create a Sandbox with the same name and the same spec, and you get the existing one back, started again if it was stopped. On E2B, keep the sandbox ID and call Sandbox.connect(id), which also resumes a paused sandbox.
Can two agents edit the same file without overwriting each other?
On Nodus, send the SHA-256 of the version you read as expectedSHA256 with the file write. If someone changed the file in the meantime, nothing is written and you get 412 SHA256Mismatch, so you can re-read and merge.
What happens to a Nodus sandbox when credits run out?
It snapshots its filesystem and stops with the reason InsufficientCredits. Once you add credits, the next command or file request starts it again with /workspace intact.
How long does a stopped Nodus sandbox take to come back?
A few seconds. The first request answers 503 SandboxStarting with a 2-second Retry-After, and the CLI and SDK wait and retry for you.
More guides like this on the Nodus Compute blog.
Top comments (0)