CapabilitiesIdle and waking
Wakes on a request
A paused machine starts again by itself when a web request or message arrives.
Who offers it
Part of Idle timers, waking and session limits, which explains why it matters.
Fully: Agent 37, Blaxel, boxd, E2B, Morph, Runtime, Sandboxer, Sprites, Tensorlake and Vercel Sandbox. With a catch: Cloudflare Sandbox and InstaBox. Not at all: Boat, Daytona, Lizard and Modal.
- Agent 37Yes
A signed URL or any request to any of its URLs brings a sleeping instance back.
docs-confirmed “opening one is exactly the kind of request that wakes the instance.” Source
- BlaxelYes
Reconnecting to the sandbox brings it back from standby.
docs-confirmed “Reconnecting to the sandbox transitions it back to active mode.” Source
- boxdYes
The first inbound packet wakes it, though bot protection can answer webhooks with a 503 instead.
docs-confirmed “`boxd machine list` shows hibernated machines with `status: hibernated`. They wake automatically on the first inbound packet.” Source
- E2BYes
Connecting to a paused sandbox resumes it.
docs-confirmed “Set `autoResume` to have a paused sandbox wake up on the next SDK call or HTTP request to one of its URLs.” Source
- MorphYes
A request brings a sleeping devbox back with its memory.
docs-confirmed “Devboxes can branch to hundreds of parallel replicas or scale to zero after a period of inactivity, preserving all application and memory state.” Source
- RuntimeYes
The call waits while the sandbox wakes, then runs.
docs-confirmed “A paused sandbox wakes by itself when a request needs it.” Source
- SandboxerYes
A sandbox paused for being idle resumes by itself on the next use.
docs-confirmed “**Wake on use.** A sandbox paused for being idle resumes by itself” Source
- SpritesYes
A request to its URL brings it back.
docs-confirmed “The next request resumes it in 100–500ms” Source
- TensorlakeYes
Automatic resume can be switched off per sandbox.
docs-confirmed “Setting it to `true` allows the next proxied request to wake a suspended sandbox” Source
The call that arrives starts a new session and then retries.
docs-confirmed “If a persistent sandbox is stopped and you call `runCommand`, `writeFiles`, or other SDK methods on it, the SDK automatically starts a new session and retries the operation.” Source
- Cloudflare SandboxWith a catch
The catch: A request starts a fresh machine, not the one that stopped; files come back only from a snapshot your code saved.
docs-confirmed “Cloudflare does not wake the Durable Object when its instance stops.” Source
- InstaBoxWith a catch
The catch: Only a machine the platform paused for being idle wakes on a request; one you paused yourself has to be resumed.
docs-confirmed “Idle auto-pause wakes on use (exec, SSH, public URL, `instabox wake`). A pause or stop you requested does not: call resume or start.” Source
- BoatNo
A stopped machine no longer exists, so a web request cannot bring it back; you have to resume it.
inferred “There is no pause. A stop removes the virtual machine and keeps a copy of the disk.” Source
- DaytonaNo
A paused or stopped sandbox has to be started; a request to its preview URL does not start it.
inferred “Paused | The VM sandbox is paused with filesystem and memory state preserved. State is offloaded to nearby storage.” Source
- LizardNo
Connecting or opening a URL does not resume a paused or stopped sandbox.
docs-confirmed “`connect` attaches to an existing sandbox without changing its state, so it does not resume a paused or stopped sandbox.” Source
- ModalNo
A finished sandbox cannot be woken; the next request needs a new sandbox or a snapshot.
docs-confirmed “Once finished, no further commands can be executed inside the Sandbox.” Source
Related
Need several capabilities at once? Add more in the capability finder. Something wrong here? Use the report link at the bottom of the page.