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 toset_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.
-1 and any longer timeout with 400, naming the limit. The anona-compute CLI takes positive durations only.
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.
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 throughenvd. 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 withanona-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.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.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.