Agents wait.
Your hours shouldn't.
An agent session is mostly waiting — on the model, on the user, on I/O. agent-next Sandbox gives every session its own Firecracker microVM that pauses with memory and processes intact and resumes in ~160 ms — and only running time draws down your hours. The public beta is free: one one-time grant of 100 sandbox-hours per account.
# Already on E2B? Two env vars and nothing else changes.
import os
os.environ["E2B_DOMAIN"] = "sbx.agent-next.com"
os.environ["E2B_API_KEY"] = "anx_your_key" # from your beta invite
from e2b import Sandbox # pip install e2b==2.40.0
sbx = Sandbox.create()
print(sbx.commands.run("echo hello").stdout)
sbx.pause() # memory + processes kept
back = Sandbox.connect(sbx.sandbox_id) # auto-resumes in ~160 ms
sbx.kill()Three pillars
A real VM per session
Every sandbox is a Firecracker microVM with its own kernel and root access. Run untrusted, model-generated code without sharing a kernel with anyone.
Pause keeps everything
Pause snapshots memory and running processes; resume measured at ~161 ms (p50, sequential). Paused time doesn't consume your hours.
Metering you can query
Per-sandbox metering of running and paused time plus CPU-seconds, reported as JSON through the usage API. Only running time draws down your hours.
E2B-compatible API · internet on by default · default beta template to be listed in the docs once published.
What runs inside
Real coding agents, unmodified. All seven CLIs below passed real bug-fix tasks inside our sandboxes — up to 300 running concurrently on one node.
| Agent CLI | Version tested | Status |
|---|---|---|
| Claude Code | 2.1.283 | tested |
| Codex CLI | 0.157.1 | tested |
| opencode | 1.18.32 | tested |
| aider | pip aider-chat | tested |
| cline | 3.0.65 | tested |
| grok-cli | 1.0.1 | tested |
| mini-swe-agent | pip | tested |
| Capability | Status |
|---|---|
| Shell exec, file read/write, streaming output | measured E2B-conformance 18/19 |
| Pause / resume with memory intact | measured ~160 ms p50 |
| Internet on by default (SMTP egress blocked) | beta |
| Default beta template — contents to be listed in the docs once published | beta |
Benchmarks, measured
Every number below was measured on our self-hosted substrate — one 16-vCPU DigitalOcean node — not estimated. Full tables and raw logs →
100 concurrent realistic users for 10 minutes: 0 create errors, ~0.04% platform errors.
FAQ
I already use E2B. What changes?
Two env vars: E2B_DOMAIN and your E2B_API_KEY. We verify e2b==2.40.0 on Python and e2b@2.26.0 on JS end to end; newer Python SDKs (≥ 2.51, /v2 API) also work. See the quickstart.
Is there a session time limit?
The gateway imposes none. The sandbox timeout sets its lifetime — the v2 API defaults it to 300 s; raise it at create time or with setTimeout. Idle sandboxes auto-pause after 300 s without traffic — unless your paused-sandbox quota is full — and the next request resumes them.
What happens to an idle sandbox?
After 300 s without activity it pauses automatically: memory and processes are kept, and paused time doesn't consume your 100-hour grant. Resume on the next request, measured at ~160 ms. Exception: if your account is already at its quota of paused sandboxes (50 by default), an idle sandbox is not paused — it stays running and keeps consuming your grant until a paused slot frees up.
Can a sandbox reach the internet?
Yes — outbound internet is on by default. SMTP egress (ports 25/465/587) is blocked.
How is usage metered?
The beta is free: each account gets a one-time grant of 100 sandbox-hours. A sandbox-hour is an hour of running time — the gateway meters running wall-clock per sandbox and reports running, paused and CPU-seconds per sandbox at GET /v0/usage. Paused time doesn't consume the grant.
Where does it run?
US region during the beta. Sandboxes have no disk backups — treat them as ephemeral and push results out.