> ## 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 & behaviors > Every hard limit, what happens at the bound, and the platform behaviors worth knowing. **Hard limits** (measured/enforced as of 2026-09-05; each is a real bound): | What | Bound | What happens at the bound | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `cpus` | 1–4 at launch | `400` before any host work | | `memory_mb` | 128–8192 at launch | `400` | | writable disk | 16 GiB sparse, fixed | `writable_size_bytes` other than 16 GiB → `400` | | processes per sandbox | one per MiB of `memory_mb` (four for `runtime="vm"`), floor 256 / cap 4096 (1024 / 16384 for vm) — 1024 at the default 1 GiB; a cgroup pids cap, independent of `cpus`; `ulimit -u` is not it (root is exempt from RLIMIT\_NPROC) | forks fail with `EAGAIN` inside the sandbox. A steady load recovers as processes exit. An exec or session whose processes reach the cap is treated as a fork storm and that exec's process group is killed; the sandbox stays up and answers | | sessions per sandbox | 256 concurrent `session()` shells; the 257th open returns 409 `session limit (256) reached` (ConflictError). `close()` frees a slot. | | | container memory | guest RAM minus max(128 MiB, 10 %) reserved for the guest agent and kernel | a process over the cap is OOM-killed inside the sandbox; the agent survives and keeps answering | | `exec` argv | 128 KiB (kernel `MAX_ARG_STRLEN`) | `400`; ship bulk data via `stdin` | | `exec` stdout / stderr | 16 MiB per stream, text (UTF-8; invalid bytes become U+FFFD) | truncated: `stdout_truncated` / `stderr_truncated` `true` (SDK `ExecResult.truncated`) + an inline notice; write large or binary output to a file and read it back | | synchronous `exec` | \~110 s at the edge | the call fails; use `run(…, background=True)`/sessions for long work | | request budget | per organization, per request class — the documented numbers are the EFFECTIVE fleet-wide budget | `429` + `Retry-After` (see [status codes](/reference/http-api#status-codes)) | **Rate limits** are per organization per minute (new organizations: 300 acquisitions — creates/snapshots/forks/exposes/templates/exports — and 12,000 other operations; DELETE is never limited). Each figure is a per-minute guarantee enforced as a fixed-window bucket per gateway replica (two), refilled in full each minute — so sustained throughput can measure up to \~2× the figure before any 429, and after a 429 the budget returns all at once; a 429 carries `Retry-After`, and successful responses carry `x-ratelimit-remaining` (`nv.rate.acquire` / `nv.rate.ops` in the SDK). ## Behaviors **Idle sleep policy (since 2026-09-07).** The platform never auto-sleeps a sandbox that is doing work: a process that outlived its exec, guest CPU above the idle floor, live network connections, or an exposed port all count as work. Only a sandbox idle by every measure, with no API call for \~60 s, is slept; the next call wakes it transparently. No maximum hold. **Fork bombs are contained** to their sandbox; a watchdog freezes and kills the storm near the pids cap and the sandbox's agent normally survives (measured 2026-09-05/07). If the guest wedges anyway: `SandboxUnhealthyError` → `reboot()` or delete. **`archive`/`unarchive` is a true resume**: processes, sockets and memory continue. `/tmp` is ordinary writable-disk space (not RAM), so it survives archiving and counts toward the disk. **`delete()` returns before the guest is gone**: the record answers 404 immediately (repeat DELETE = no-op 204) while the host tears down asynchronously — typically under a second. Its URL and in-flight execs fail during that window; that is teardown, not a leak. **Network policy.** Link-local `169.254.0.0/16` is blackholed for every sandbox. `disable_internet` is inherited by snapshots' restores and fork children; a no-egress connect blocks until the client's own timeout (no fast rejection) — give such clients short connect timeouts. Environment variables cannot be set per sandbox at create: bake them into the image or set them per run (`run("VAR=value cmd")` or a session's `export`). **Clock.** Guests boot with `clocksource=kvm-clock`: `CLOCK_MONOTONIC` is consistent across vCPUs. ### Harbor benchmarks The `nanovm-harbor` wheel (`/sdk/` on the console) is a Harbor environment provider (`--env nanovm_environment:NanoVMEnvironment`); it handles template builds, retries, compose tasks, and ships `python -m nanovm_prebuild images.txt`. README inside the wheel or the repo's `integrations/harbor/`.