Dora NodaE2B will hand your coding agent a fresh Firecracker microVM in about 150 milliseconds — and take it away again after one hour. On the Hobby tier, every sandbox has a hard one-hour maximum lifetime; on the $150/month Pro tier, the ceiling rises to 24 hours. Pause a sandbox instead of letting it die and the meter stops, but a second clock starts: paused sandboxes are auto-deleted after 30 days. For the stateless "spin up, run code, tear down" loop E2B was designed around, none of this matters. For an agent that needs its environment to persist across a multi-day build — installed toolchains, half-migrated databases, a debugger paused at a breakpoint overnight — the caps are the whole ballgame.
This post delivers the concrete accounting the title promises: every lifetime limit E2B publishes, what each one does to a specific three-day agent task, and which alternative fits once your agent outgrows disposability. (A companion post covered the dollar math — per-second wears versus a flat owned box. This one is about time, not money.)
The limits, all in one table
E2B's own numbers, current as of 2026, with the lifetime rows highlighted — those are the ones this post is about:
| Limit | Hobby ($0) | Pro ($150/month) |
|---|---|---|
| Max sandbox session | 1 hour | 24 hours |
| Concurrent sandboxes | 20 | 100 (add-ons to 1,100) |
| Usage credit | $100 one-time | Plan fee + per-second usage |
| Billing while paused | $0 (compute stops) | $0 (compute stops) |
| Paused-sandbox retention | 30 days, then auto-deleted | 30 days, then auto-deleted |
| Resume latency | ~1 second | ~1 second |
| GPUs in sandbox | None, at any tier | None, at any tier |
Two rows deserve unpacking because they quietly define the product. First, the meter runs on wall-clock provisioned capacity — roughly $0.0504 per vCPU-hour and $0.0162 per GiB-hour, so the default 2 vCPU box costs about $0.11–0.17 an hour — and it stops the moment a sandbox pauses, is killed, or times out. Pause captures the full state (filesystem, memory, running processes) and resume restores it in about a second; pausing itself costs on the order of 4 seconds per GiB of RAM. Second, the session clock is extendable but not removable: the SDK defaults new sandboxes to a 5-minute timeout, setTimeout() pushes the deadline out while the sandbox lives, and a lifecycle policy decides what expiry means — pause (state preserved) or kill (state gone). The ceiling you cannot negotiate is the tier cap: one hour, or twenty-four.
The scale behind the constraints is real. E2B raised a $21 million Series A in July 2025 led by Insight Partners — $32 million total — on the back of E2B's own claim that 88% of the Fortune 100 have signed up, with sandbox volume reportedly growing from tens of thousands to millions of sessions a month within a year. Hundreds of millions of short-lived microVMs is a fleet-management achievement, and the lifetime caps are load-bearing walls in it: a platform that promises 150-millisecond starts to everyone cannot also promise anyone's box lives forever.
Why the caps exist: disposability is the product
E2B's architecture makes the most sense read backwards from its unit economics. Firecracker boots a stripped guest kernel in roughly 125 milliseconds with about 5 MB of hypervisor overhead per microVM, and E2B pairs that with per-second billing — so "one fresh kernel per agent step" costs nothing in latency or money. That pairing is what the platform sells. The 1-hour Hobby cap, the 24-hour Pro cap, and the 30-day paused retention are the guardrails that keep the pairing true at fleet scale: they bound how much zombie state — idle-but-alive microVMs, forgotten paused snapshots — can accumulate per host, per region, per unpaid account.
For the workload E2B was built for, the guardrails are invisible. A code-interpreter agent that spins up a sandbox per task, runs untrusted model-generated code, and tears it down in minutes never sees a timeout. The Twenty engineering team demonstrates the disciplined version of this pattern in production: their E2B integration reuses one warm sandbox per conversation with an on-timeout-pause plus auto-resume lifecycle, so idle sandboxes freeze for free and wake in a second on the next message. Short tasks, explicit lifecycle ownership, pause as the default idle state — inside that envelope, the caps never fire.
The trouble starts the moment the agent's job stops fitting inside one envelope: not executing code snippets, but operating infrastructure. A multi-day migration. A flaky-test hunt that needs the exact failing environment kept warm between sessions. A dev sandbox an agent pair-programs in across a week. These are environment workloads, not execution workloads, and every lifetime cap in the table above taxes them specifically.
The three-day task: what breaks, day by day
Concretely, then. An agent starts a dependency-migration task on Monday morning in a default sandbox: installs toolchains, migrates half the test suite, leaves a reproduction running. Here is what each lifetime rule does to that task:
| When | What fires | Consequence | The mitigation, and its price |
|---|---|---|---|
| Monday, hour 1 (Hobby) | 1-hour session cap | Sandbox times out; without a pause policy, filesystem, memory, and processes are gone | Move to Pro ($150 before the first sandbox-second), or set on-timeout-pause and babysit the clock |
| Monday night (any tier) | Idle auto-pause | Sandbox freezes; compute billing stops; state preserved | Free — this is the happy path, and the Twenty pattern shows how to automate it |
| Tuesday, hour 25 (Pro) | 24-hour session cap | Same kill decision as Monday, one day later; a task spanning a long weekend cannot survive unattended | External orchestration must recreate state from snapshots or scripts — the sandbox will not bridge the gap itself |
| Next month, day 31 | 30-day paused auto-delete | The paused sandbox — the "I'll get back to this" environment — is deleted whether or not anyone is done with it | Anything that must outlive 30 days of inactivity needs its state exported somewhere E2B doesn't own: a template, a repo, an artifact store |
| Any resume, occasionally | Pause/resume fidelity | Resume is documented at ~1 second, but operators report rough edges around repeated pause/resume cycles, including at least one upstream filesystem-state bug report | Rebuild-from-script stays the only path you can prove correct; snapshots are convenience, not backup |
Read the timeline as a system, not a list of edge cases. Nothing in it surprises anyone who thinks of E2B as code execution; every row surprises anyone who thinks of it as a computer. The 24-hour Pro cap is the telling one: it is generous enough that almost no legitimate single task hits it, yet absolute enough that no environment can rely on outliving it. E2B is telling you, via the price list, that a sandbox is a place code runs, not a place work lives. The 30-day auto-delete says the same thing one level up: even frozen, your environment is a guest, and guests get evicted.
Two smaller taxes compound the big ones:
- Concurrency caps turn bursts into queues. Fifty parallel eval sandboxes on a Monday morning hits 20 Hobby or 100 Pro and waits or fails instead of degrading gracefully — exactly when a long-running orchestrator most needs the platform to absorb the spike.
- One region bounds lifetime in space as well as time. A sandbox cannot follow a team across geographies or fail over during a regional incident; the environment is pinned to wherever E2B's managed cloud runs.
The persistence landscape: who sells "stays up"?
Once the need is named — environments that persist, not executions that repeat — the market splits four ways, and the split is the actual buying guide:
- Daytona sells the workspace-shaped answer: persistent, stateful sandboxes with first-party snapshots, sub-90-millisecond starts, and GPU options. If E2B's caps are the complaint, Daytona's persistence model is the most direct alternative sentence.
- Vercel Sandbox, generally available since January 2026, made persistence the default: automatic filesystem snapshots keep sandboxes stateful unless asked otherwise, with up to 2,000 concurrent sandboxes on Pro. Ephemeral is the opt-in, not the opt-out.
- Fly Machines take the infrastructure route: Firecracker microVMs with persistent state as a platform primitive rather than a sandbox feature — closer to "a VM with a fast API" than "an SDK for code execution."
- Modal answers a adjacent question with GPUs: gVisor-isolated sandboxes backed by a serious accelerator catalog. If the long-running need is GPU-adjacent — inference-warm sandboxes, embedding batches — the lifetime debate is secondary to hardware E2B doesn't stock at any tier.
And one layer up, a category error is worth defusing: sandbox lifetime is not workflow durability. Temporal, Trigger.dev, and the LangGraph Platform all solve "a multi-day agent run survives crashes and retries" — durable orchestration of steps. None of them keeps a sandbox's filesystem warm. The correct architecture pairs the two: the orchestrator owns the plan and retries, the sandbox owns the moment, and state crosses the boundary through snapshots, artifacts, or git — never through assuming the microVM will still be there in the morning. Teams that conflate the layers discover the 24-hour cap at 3 a.m. Teams that separate them can run on E2B indefinitely, because no single sandbox ever needs to.
Owning the clock: what changes on your own fleet
There is exactly one way to remove every row in the first table simultaneously: own the machines the microVMs run on. On a fleet you control, the session cap is a config value, paused-snapshot retention is a disk-capacity question, and the 30-day eviction simply doesn't exist unless you write it. The isolation primitive doesn't change — Firecracker is Firecracker, ~125-millisecond boots and 5 MB overheads wherever it runs — which is why the self-hosting conversation here is narrower and more honest than "build your own E2B." You are not rebuilding the product; you are deleting its guardrails, because on your own hardware the fleet-scale pressures that required them don't apply to you.
The honest price of deleting them is operations, and yesterday's companion post priced it: E2B's infrastructure repo is open source under Apache-2.0, but running it means operating a Nomad-plus-Consul stack with Postgres, Loki, Grafana, and KVM hosts — or paying Enterprise BYOC rates starting around $3,000 a month. The middle path most teams actually take is smaller: Firecracker or Kata Containers on boxes they already rent, a warm pool, snapshot templates, and an idle reaper — the four automations that reproduce E2B's product surface minus its clocks. The decision rule from the dollar post carries over unchanged: managed sandboxes while your usage is spiky and uncertain, owned capacity once it is steady enough to plan around. Persistence follows the same curve — a long-lived microVM is a Firecracker feature, not a vendor favor.
The deeper pattern is the one to keep. Per-second billing plus sub-second starts made the sandbox disposable, and disposable sandboxes made agent architectures possible — that pairing is what turned an isolation primitive into an industry. But "disposable by default" and "deleted by policy" are different things, and the caps convert one into the other on someone else's schedule. An agent that executes code can live inside that schedule forever. An agent that operates infrastructure — keeps state, survives the weekend, picks up Tuesday where Monday left off — eventually needs a clock it owns. Know which agent you're building before the 30-day email tells you.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
