> ## Documentation Index > Fetch the complete documentation index at: https://docs.nanovm.dev.lithosai.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Limits and behavior > Resource limits, request budgets, and the actions to take when a limit is reached. ## Sandbox resources | Resource | Limit | When reached | | --------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Active sandboxes per organization | 20; includes creating, running, paused, and sleeping sandboxes | Create or fork returns `403` with `kind="cap"`. Archive or delete an unused sandbox. | | CPU | 1–4 vCPU per sandbox; default 2 | An invalid value returns `400`. | | Memory | 128–8192 MiB per sandbox; default 1024 | An invalid value returns `400`. | | Writable disk | 16 GiB, fixed | A different `writable_size_bytes` value returns `400`. | | Fork copies | Up to 4 per call, within the organization limit | Reduce the count or free active sandbox slots. | | Shell sessions | 256 concurrent per sandbox | Opening another session returns `409`. Close unused sessions. | | GPU | Not supported | Use CPU-compatible workloads. | 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 | Input or output | Limit | How to work within it | | ------------------------- | --------------------------------------------- | ---------------------------------------------------------------- | | One command argument | 131,071 bytes; no NUL characters | Send data through `stdin` or a file. | | Standard input | 4 MiB per call | Transfer larger inputs in chunks or download inside the sandbox. | | Standard output and error | 16 MiB each | Check `ExecResult.truncated`; save larger results to files. | | Synchronous command | About 110 seconds, including session commands | Use `background=True` and collect results later. | | `files.write()` | 4 MiB; replaces the whole file | Use an append command for chunks, not repeated writes. | | `files.read()` | Approximately 16 MiB of text | Transfer larger files through another method. | | `files.read_bytes()` | Approximately 12 MiB | Transfer larger files through another method. | | System log read | 256 KiB per call | Request the tail you need. | Command output is UTF-8 text; invalid sequences are replaced. Use `read_bytes()` for binary files. See [Run commands](/guides/run-commands) and [Work with files](/guides/files#transfer-larger-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. The `vm` 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: | Request group | Requests per minute | | ----------------------------------------------------------------------------- | ----------------------- | | Creates, restores, snapshots, forks, public endpoints, templates, and exports | 300 | | Other operations, including commands and reads | 12,000 | | DELETE requests | Exempt from rate limits | 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](/reference/http-api#status-codes). ## Waits and time ranges | Operation | Default or maximum | | ----------------------------- | --------------------------------------------------- | | Ordinary SDK request | 120-second timeout | | Create request | At least a 300-second SDK timeout | | Wait for image preparation | 900 seconds; configure `warm_timeout` on `create()` | | Wait for snapshot durability | 120 seconds; configure `timeout` | | Wait for a template or export | 900 seconds; configure `timeout` | | Recent metrics | Approximately 2 hours at 30-second intervals | | Historical metrics | Up to 15 days, in minute intervals | | Organization usage query | Up to a 32-day window | 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](/guides/serve). ## 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](/guides/lifecycle). ### Harbor benchmarks The LithosBox Harbor provider runs benchmark tasks in sandboxes. In your existing Harbor Python environment, install the provider: ```sh theme={null} python -m pip install https://console.sandbox.lithosai.cloud/sdk/lithosbox_harbor-0.1.0-py3-none-any.whl ``` Add `--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: ```sh theme={null} python -m lithosbox_prebuild images.txt ```