Skip to main content

Timeouts

Every sandbox has a timeout: the number of seconds from now until its timeout action runs. The action is delete by default, or pause if you ask for it. Each call to set_timeout replaces the previous value, counted from that moment.

No time limit

On plans without a maximum lifetime, a timeout of -1 means no deadline: the sandbox runs until you pause or delete it. It reports endAt as 9999-12-31T23:59:59Z, because the E2B schema requires a date. A sandbox without a deadline that you pause and resume keeps having no deadline.
A plan with a maximum lifetime (the free plan’s is one hour) refuses -1 and any longer timeout with 400, naming the limit. The anona-compute CLI takes positive durations only.
A sandbox without a deadline is billed for as long as it runs. Let it pause when idle: paused sandboxes cost only snapshot storage.

Pause and resume

Pausing snapshots the sandbox’s memory and disk and stops the VM. Resuming restores it: running processes, open files and /dev/shm carry on where they were. Paused sandboxes are kept until you delete them; they count against your plan’s paused-sandbox limit, and their snapshot storage is billed per GB-month.
On the engine’s test hosts, a pause took 0.1 to 0.3 s and a resume 0.8 to 0.9 s, with memory, uptime and a detached process kept. Production numbers are not published yet.

Pause on timeout

Ask for pause instead of delete when the timeout runs out. The sandbox then waits, paused, until you resume it:
auto_resume (resume when a request reaches the sandbox’s URL) is accepted with pause-on-timeout, but waking on traffic is Coming soon: a request to a paused sandbox’s URL gets 409 today. Resume with connect.

Pause when idle

A sandbox can pause itself once nothing has used it for a while: no request to any of its ports, no open terminal, live view, SSH session or byte pipe, and no running process started through envd. Starting to run again (resume) restarts the clock. This is what the dashboard’s lifetime No limit (pauses when idle) sets up, with 15 minutes.
idleMinutes ranges from 1 to 10080 (one week); 0 turns it off. The SDK’s lifecycle={"on_timeout": "pause"} (autoPause: true on the wire) pauses at the timeout, and idles only if your organization has a default idle time. Resume a paused sandbox with Sandbox.connect(id).

Delete

Delete a sandbox with anona-compute delete, the dashboard, or kill() in the SDK: the SDK keeps the E2B method name, so code written for E2B works unchanged. It returns as soon as the gateway has the request (it waits up to 2 s for the engine) and finishes in the background with retries. The sandbox disappears from list at once.

Fork

Fork copies a running sandbox - memory, files and running processes - into new sandboxes. Each copy starts from the exact state the original was in, which is the point: get an agent to an interesting state once, then try ten things from there. The original is briefly frozen while its memory is written (about 0.1 s, longer right after it has touched a lot of memory), then keeps running on its own node with the same ID and the same deadline. The snapshot is taken once however many copies you ask for.
Each fork is a new sandbox and behaves like one: it takes a slot of your concurrent-sandbox limit, it is billed like any other sandbox for as long as it runs, and it inherits the original’s template, metadata, timeout policy and network policy, with the lifetime you pass to fork. A fork of ten on a plan with room for three is not an all-or-nothing failure. The copies that fit are created, and every other entry of the result says why it was not - 429 when your plan’s limit is reached, 503 when the platform is at capacity. The SDK gives you those as exceptions in the same list, in request order. A non-201 from the API means nothing was forked at all: the sandbox was not running (409), or there was no room for even one copy (429), in which case the original is not frozen either.
Forking needs the sandboxes:create scope, and an API key restricted to particular sandboxes cannot fork. In the dashboard, Fork on a running sandbox’s page asks how many copies and how long they should live, shows what the batch will cost before you commit, and lists the outcome of each copy.
Each fork request keeps a checkpoint of the source sandbox, which the copies read from, and this engine cannot delete one yet - deleting the copies does not free it. So forking is capped per team (32 checkpoints by default); past that, fork answers 429 and says so. Ask support to raise it, and tell us what you are building with fork: the cap exists only until checkpoints can be reclaimed.

Snapshots

Coming soon: named snapshots you can keep and create from later (POST /sandboxes/{id}/snapshots, GET /snapshots). Fork takes a snapshot for you and uses it immediately.