Skip to main content
The SDK ships two clients with identical methods: SandboxClient for synchronous scripts and AsyncSandboxClient for concurrent workloads. Both are importable from prime_sandboxes.

Sync Client

SandboxClient is the simplest way to get started — no async/await needed.
Every method shown in the async sections below has an identical synchronous counterpart on SandboxClient.

Async Client

Most sandbox automations spin up more than one environment. The async client lets you fan out creates, waits, commands, and teardown without juggling threads.

Launch a Fleet

bulk_wait_for_creation polls via the list endpoint, backing off automatically if the API throttles you.

Run Commands & Collect Logs

Command responses include stdout, stderr, and exit code so you can short-circuit pipelines when something breaks.

Move Data In and Out

Note: File uploads are limited to 200MB per file. Uploads/downloads use short-lived gateway tokens stored in a local cache. Call sandboxes.clear_auth_cache() if you rotate credentials or hit 401s.

Expose Ports

Make services inside your sandbox accessible over the internet. Both HTTP and TCP protocols are supported. Ports must be in the range 22–9000. Ports 8080, 2222, and 8081 cannot be exposed.

HTTP

Expose an HTTP service and get a public HTTPS URL:

TCP

Expose a raw TCP service and get a public host:port endpoint:
TCP exposures return an external_endpoint (host:port) and external_port instead of a URL. Connect using any TCP client, for example Python’s socket.create_connection().

Start Command

By default, sandboxes run tail -f /dev/null to keep the container alive for interactive use. Pass start_command to override the image’s ENTRYPOINT with your own process:
If you omit start_command, the default keeps the sandbox idle and ready for execute_command calls.

Environment Variables & Secrets

Pass configuration and credentials when creating a sandbox:
Environment variables are stored in plain text. Secrets are encrypted at rest and never returned in API responses — use them for API keys, passwords, and other sensitive values. Both are injected into the container as standard environment variables. You can also pass per-command environment variables to execute_command:
Use user to run a command as a specific user, like docker exec -u. It accepts a username or numeric UID, optionally with a group ("agent", "1000", "agent:agent", "1000:1000"). The same user argument works on start_background_job.

Network Isolation

For running untrusted code, create sandboxes without internet access:
When network_access=False:
  • Outbound connections to the internet are blocked
  • DNS resolution for internal services still works
By default, network_access=True and sandboxes have full internet access.

Long-Running Commands

Commands can run up to 15 minutes using the timeout parameter:
For tasks longer than 15 minutes, use background jobs instead. They’re more reliable and won’t tie up your connection.

Background Jobs

Use start_background_job for tasks that run longer than 15 minutes. The job continues running in the sandbox while you poll for completion.
The timeout_minutes parameter controls how long the sandbox stays alive. Background jobs persist across API calls until completion or sandbox termination.

Idle Timeout

Set idle_timeout_minutes on CreateSandboxRequest (or UpdateSandboxRequest) to have the sandbox terminate itself when nothing has touched it for a while:
Any execute_command, upload_file, download_file, or file-read call resets the idle clock. Long-running execs stay pinned for their full duration.
  • Disabled by default — omit the field to keep the legacy lifetime-only behavior.
  • Validated client-side: 1 ≤ idle_timeout_minutes ≤ timeout_minutes and idle_timeout_minutes ≤ 1440.
  • Not supported for VM-backed sandboxes.
  • SSH sessions are not counted as activity yet.
When a sandbox shuts down for this reason, the response object exposes termination_reason="idle_timeout".

Error Handling

The SDK raises typed exceptions so you can handle specific failure modes. All exceptions are importable directly from prime_sandboxes.

Sandbox Lifecycle Errors

These are raised when a sandbox is no longer in RUNNING state. They form a hierarchy — catch the base class for broad handling, or specific subclasses for targeted recovery. SandboxOOMError, SandboxTimeoutError, and SandboxImagePullError are all subclasses of SandboxNotRunningError.

Operation Errors

Raised during specific operations when the sandbox is still running but the operation itself fails.

API Errors

Raised for HTTP-level failures when communicating with the platform API.

Clean Exit

Delete a single sandbox or use bulk_delete to tear down many at once by IDs or labels:
You must pass either sandbox_ids or labels, not both. For a full script, see prime-cli/examples/sandbox_async_demo.py, which covers create → wait → run → logs → delete.