Which sandbox is best for running AI agent code?

For AI agents that run code for hours at a time, Nodus Sandboxes are the best fit. Network access is off by default, every sandbox can carry a hard dollar cap, and a 2 vCPU, 4 GiB sandbox is listed at $0.0357/hr on the Nodus pricing page. Pick E2B to pause an agent with its memory and processes intact, Modal when your code already runs on Modal, and Daytona when the agent needs Windows or a full Linux VM.

We build Nodus. Every fact about E2B, Modal and Daytona below links to their own pages, prices were checked on October 31, 2026, and there is a section on where each of them is the better choice.

How do E2B, Modal, Daytona and Nodus compare at a glance?

All four give an agent an isolated Linux environment it can run commands in, read and write files in, and throw away. They differ in defaults, limits and billing.

	Nodus Sandboxes	E2B	Modal Sandboxes	Daytona
Billing	Prepaid credits, hourly price quoted before create	Per second, plus a $150/month Pro plan for long sessions	Per second, at 3x list CPU and memory rates	Per second, pay as you go
2 vCPU, 4 GiB per hour	$0.0357	$0.1656	$0.2380	$0.1656
Longest single sandbox	720 hours (maxLifetime)	1 hour (Hobby), 24 hours (Pro)	24 hours (default 5 minutes)	No fixed cap; auto-stops after 15 idle minutes by default
Pause with memory and processes	No, files only	Yes	Filesystem snapshots	Stop and archive
GPUs	On-demand, non-interruptible	Not listed on pricing page	Yes	On-demand and spot
Free usage	Starter credit for new orgs	$100 one-time credit	$30/month credit	$200 free compute

Sources: Nodus pricing, Nodus Sandboxes guide, E2B pricing, E2B internet access, E2B persistence, Modal pricing, Modal Sandboxes guide, Daytona pricing, Daytona sandboxes docs. Prices checked October 31, 2026; per-hour figures are CPU plus memory only, without disk.

What does an agent sandbox actually cost per month?

At the listed rates, 1,000 hours of a 2 vCPU, 4 GiB sandbox costs $35.70 on Nodus, $165.60 on E2B or Daytona, and $237.96 on Modal. That is a team running 50 agents for 20 hours each, or one always-on agent for about six weeks.

We priced the same shape on each provider's own page and did the math once:

• Nodus: the pricing page lists 2 vCPU with 4 GiB and 80 GiB of included disk at $0.0357/hr, so 1,000 hours is $35.70.
• E2B: 2 vCPUs at $0.000028/s is $0.1008/hr, and 4 GiB at $0.0000180/s is $0.0648/hr. That is $0.1656/hr, or $165.60. Sessions longer than an hour need the $150/month Pro plan, which makes it $315.60.
• Daytona: $0.0504 per vCPU-hour times 2 is $0.1008, and $0.0162 per GiB-hour times 4 is $0.0648. That is also $0.1656/hr, or $165.60, with the first 5 GiB of storage free.
• Modal: Sandboxes bill one physical core (2 vCPU) at $0.00003942/s, which is $0.141912/hr, and 4 GiB at $0.00000667/s per GiB, which is $0.096048/hr. That is $0.23796/hr, or $237.96.

At list prices, the same 1,000 sandbox-hours cost about a fifth as much on Nodus as on E2B or Daytona.

Two things move these numbers in practice. Free credit covers small workloads: at the rates above, E2B's $100 credit buys about 604 hours of this shape, Daytona's $200 about 1,208 hours, and Modal's $30 monthly credit about 126 hours a month. And idle time is where agent bills leak: an agent that thinks for 40 seconds between commands still holds its sandbox. On Nodus a sandbox stops after 5 idle minutes by default and keeps /workspace, so the next command starts it again in a few seconds.

Which sandbox isolates untrusted agent code best?

Nobody can honestly promise a sandbox that cannot be escaped, so compare the layers each one documents and the defaults you get when the agent's author forgets a setting.

Nodus runs production CPU Sandboxes behind a user-space kernel that passes only a filtered set of system calls to the host, each in its own network namespace with a default-deny firewall. Commands run as a non-root user with no Linux capabilities, inside a cgroup capped at the CPU and memory you asked for and 256 processes. Machines are packed per organization, so another company's sandbox never shares the machine with yours. All of this is described in the Sandbox isolation docs.

E2B describes each sandbox as an isolated Linux VM in its lifecycle docs. Modal offers two sandbox runtimes, a container runtime and a VM runtime with its own Linux kernel for workloads such as Docker inside the sandbox. Daytona runs sandboxes as Linux containers by default, with Linux VM and Windows sandboxes as options.

The default that matters most is the network. E2B gives every sandbox outbound internet access unless you set allow_internet_access=False. Nodus starts with no route out at all, and private ranges and cloud metadata addresses stay blocked even when you open egress. If the agent holds an API key and gets prompt-injected, a closed network is what keeps the key from leaving.

How long can an agent keep its sandbox?

Session limits decide whether a sandbox fits a coding agent that works on one repository for days. Nodus allows up to 720 hours per sandbox, Modal and E2B Pro allow 24 hours, and E2B Hobby allows 1 hour.

A multi-day coding agent fits in one Nodus sandbox; elsewhere it needs a snapshot and a new sandbox each day.

The limit is only half of it. Reconnecting matters too, because agent processes crash and restart. On Nodus, creating a sandbox with the same name and spec returns the existing one and starts it if it was stopped, so an agent can run the same create call every time it boots. Modal recommends filesystem snapshots for work past 24 hours, and E2B lets you connect() to a paused sandbox by ID.

Which one should you pick for your agent?

Use the shape of the agent's work as the decision rule.

• Long-lived coding agents that edit one repository for hours or days: Nodus, for the 720-hour lifetime, reconnect-by-name and /workspace kept across idle stops.
• Many short code-interpreter calls inside a chat product: E2B, whose pause and resume keep memory and running processes.
• Agents that call GPU functions you already deploy on Modal: Modal Sandboxes, which sit next to your existing Modal apps.
• Agents that drive a desktop, a browser in a full VM, or Windows software: Daytona, which offers Windows and Linux VM sandboxes.
• Any agent whose spending you cannot watch: whichever you pick, put a hard cap on it. On Nodus that is maxCostUSD on the sandbox plus a Budget on the project.

Where are E2B, Modal and Daytona the better choice?

E2B is better when the agent's state lives in memory. Its persistence docs say a paused sandbox resumes with its running processes and loaded variables, and paused sandboxes are kept with no automatic deletion. A Nodus stop keeps files but restarts processes, so a Jupyter kernel with a loaded dataframe has to reload.

Modal is better if your team already ships on Modal. Sandboxes can use the same Modal account, apps and GPUs, and the VM runtime can run Docker inside the sandbox.

Daytona is better for agents that need Windows, a full Linux VM, or cheap preemptible GPUs, since its pricing page lists spot GPU sandboxes from RTX 4090 up to B300.

Nodus has gaps too. The Python SDK does not yet accept port tunnels, volumes or an allow-list egress policy, filesystem snapshots are Beta, and GPU sandboxes are on-demand only and start empty after a stop. Check the Python Sandboxes guide before you design around any of those.

How do you start a Nodus sandbox for an agent?

Install the SDK, sign in, and create a sandbox with a cost cap:

pip install nodus-compute
nodus login

This is the example from our Python Sandboxes guide:

import nodus

sb = nodus.Sandbox.create(
    cpu=1,
    memory="2Gi",
    idle_timeout="5m",
    max_cost=1,
)
try:
    p = sb.exec("python", "-c", "print(6 * 7)")
    print("stdout:", p.stdout.read().strip(), "exit:", p.wait())
finally:
    sb.terminate()

Egress is denied unless you pass a network policy, and the sandbox stops itself once it has cost $1. For agents that also launch training or batch jobs, infrastructure for background coding agents covers handing long work to a job, and Nodus vs E2B goes deeper on that one comparison.

FAQ

Can an AI agent sandbox use a GPU?

Yes on Nodus, Modal and Daytona. Nodus GPU sandboxes run on dedicated on-demand machines that are never preempted, and their local files do not survive deletion, so keep durable data in an external filesystem.

What happens when an agent's sandbox runs out of money on Nodus?

The sandbox stops when its maxCostUSD or the project Budget is reached, and commands answer 402 BudgetExceeded until you raise the limit. A CPU sandbox keeps its /workspace while stopped, so the agent picks up where it left off once you raise the limit.

Do I need a sandbox if the agent only writes code and never runs it?

No. A sandbox matters once the agent executes what it writes, installs packages or browses, because that is when untrusted code touches your machine, your network and your keys.

Can one sandbox serve several agents?

It can, but give each agent its own. Separate sandboxes keep one agent's files, secrets and runaway processes away from another's, and on Nodus the per-sandbox cap then limits each agent's spend.

Originally published on the Nodus blog.