Skip to main content
Sandboxes launch with the configuration you need and run until you stop them or they time out. By default, this is based on your team’s default Session Timeout setting which you can change on the Settings page. You can also configure the timeout per sandbox during creation. timeoutMinutes is the sandbox’s total lifetime beginning when its VM starts, not a timeout applied separately to each SDK operation. For GPU sandboxes, the lifetime begins when provisioning finishes and the sandbox starts running.

Wait for a GPU sandbox

GPU creation returns 202 Accepted with status: "provisioning". At this point, runtime and token are null. Poll GET /api/sandbox/{id} until status is active before running commands. Stop polling if the sandbox enters a terminal state and inspect closeReason. The CLI’s --wait-for-provisioning flag waits for an active GPU sandbox. Ending that wait does not stop the sandbox. To cancel, call the normal stop endpoint or use hx vm stop with its ID, even while it is still provisioning. Provisioning time is not billed. Once active, allocated GPU, CPU, and memory resources are billed until the sandbox ends, including time spent idle. See GPU pricing. GPU sandboxes can be interrupted and do not resume running processes after an interruption. Their disk is ephemeral: save checkpoints and results to external storage while the sandbox is running. See GPU limits.

Set a lifetime

macOS sandboxes (Beta) save disk changes asynchronously when stopped. Wait for the disk to become ready and detached before starting a new sandbox with its diskId. Running processes and memory are not preserved.
For example, set a custom session timeout when creating the sandbox:

Getting a Sandbox

Fetch a detailed sandbox handle by ID:
The REST API returns VM sizing fields as vcpus, memMiB, and diskSizeMiB. The Node SDK exposes the same values as cpu, memoryMiB, and diskMiB; the Python SDK exposes them as cpu, memory_mib, and disk_mib. duration is the elapsed runtime in milliseconds after a sandbox ends, so it is 0 while the sandbox is active. timeoutMinutes is the configured total lifetime.

Listing Sandboxes

List your sandboxes with optional filtering:

Refreshing and Connecting

Connect to an existing sandbox or refresh the runtime token.
Create and get responses for an active sandbox include a runtime token that is valid for 24 hours. The Node and Python SDKs automatically obtain a fresh token shortly before expiry and retry a replayable runtime HTTP request once with a fresh token after a 401. Call refresh() when you also want to refresh the handle’s cached sandbox metadata. For a more detailed guide to runtime tokens, see Sandbox Runtime URLs.

Stopping a Sandbox

Always stop a sandbox when you are done with it:
Stopping a sandbox is safe to call more than once.

Exposing Ports

Expose a port when you need a custom process to be accessible from outside from the sandbox. This provides a custom runtime URL for that exposed port.
If auth is enabled, send the sandbox bearer token when calling the exposed URL:
For a dedicated guide to runtime URLs, exposed service URLs, browser auth links, and end-to-end examples, see Sandbox Runtime URLs.
Port 4001 is reserved for the sandbox runtime API url and cannot be exposed.