Sandbox resources
Templates and snapshots retain their CPU and memory configuration when used to
create another sandbox. Pausing or sleeping does not release an active sandbox
slot; archiving does.
Commands and files
Command output is UTF-8 text; invalid sequences are replaced. Use
read_bytes()
for binary files. See Run commands and
Work with files for examples.
Processes and memory
For the default runtime, the process limit is one process per MiB of configured memory, with a minimum of 256 and a maximum of 4096. At the default 1 GiB, that allows 1024 processes. Thevm runtime allows four per MiB, with a minimum of
1024 and a maximum of 16,384.
At the process limit, new processes may fail to start with EAGAIN. An execution
that creates too many processes can be terminated. Reduce concurrency or choose
more memory. If the sandbox becomes unresponsive, reboot it or create a new one.
In the default runtime, application memory is the configured memory minus a
reserve of the greater of 128 MiB or 10%. For configurations below 256 MiB, half
the memory is available to applications. Processes that exceed the available
memory may be terminated. Account for that allowance when choosing memory for a workload.
Request rates
The default request budgets are per organization:
A
429 response includes Retry-After. Wait for that interval before retrying.
Rate-limit headers describe the budget observed by that response; they are
advisory, not an exact counter of what another concurrent request can use.
In the SDK, a rate limit is QuotaError(kind="rate"). It differs from
QuotaError(kind="cap"), which requires releasing a sandbox slot, and
CapacityError, which indicates temporarily unavailable capacity. See
HTTP status codes.
Waits and time ranges
A timeout while waiting does not cancel image preparation, saving, or export.
Check the resource’s status before retrying. If a create loses its response,
inspect the sandbox list before issuing a new create.
Networking
Outbound connectivity uses IPv4. Access to link-local addresses (169.254.0.0/16)
is blocked. Set disable_internet=True when creating a sandbox to disable outbound
internet access; forks and snapshot restores keep that setting.
A blocked outbound connection can wait until the application’s own timeout. Set
finite connection timeouts in applications that may run without internet access.
Public endpoints accept HTTP/1.1 and HTTP/2 and require application authentication
if the content should be private. See Expose a web service.
Lifecycle behavior
Idle sandboxes can sleep after about 60 seconds without activity. Active background processes, connections, and exposed services keep them awake. Running a command or accessing a file wakes a sleeping sandbox. Paused and archived sandboxes require an explicit resume or unarchive. Files, including files in/tmp, survive archive/unarchive and reboot. Reboot ends
processes and sessions. Delete removes the sandbox’s working state; retained
snapshots must be deleted separately. See Manage sandbox lifecycle.
Harbor benchmarks
The LithosBox Harbor provider runs benchmark tasks in sandboxes. In your existing Harbor Python environment, install the provider:--env lithosbox_environment:LithosBoxEnvironment to your Harbor run command.
Provide LITHOSBOX_TOKEN through that environment’s secret configuration and set
LITHOSBOX_API_URL=https://api.sandbox.lithosai.cloud.
To prepare a list of images before a run, put one image reference on each line of
images.txt, then run: