--- title: "Resources and scaling" description: "CPU, memory, and disk limits — and how the agent resizes the sandbox" canonical_url: "https://hoplite.sh/docs/sandboxes/resources" markdown_url: "https://hoplite.sh/docs/sandboxes/resources.md" --- # Resources and scaling URL: /docs/sandboxes/resources LLM index: /llms.txt Description: CPU, memory, and disk limits — and how the agent resizes the sandbox Related: /docs/sandboxes, /docs/sandboxes/previews, /docs/threads # Resources and scaling Sandboxes scale compute elastically. On a burstable provider, the CPU and memory a sandbox is created with are a *reservation* — a guaranteed paid floor — while the workload can use spare host capacity up to a separate conditional *burst limit*. So a small reservation is not a cap, and a heavy install, build, or dev server does not require a resize. The agent's `sandbox_status` tool reports the `resourceModel`, `reservation`, `burstLimit`, health, and disk context separately. ## Limits On the default platform policy a sandbox's reservation can grow up to: | Resource | Ceiling | | --- | --- | | CPU | 16 vCPU | | Memory | 32 GiB | | Disk | 10 GiB | Limits are policy-layered — platform, plan, workspace, user, and thread levels can each tighten (never loosen) the bounds above them, so your effective ceilings may be lower. The same layered ceiling also bounds bursting: a sandbox may climb above its reservation up to that enforced limit, and `sandbox_status` reports it under `burstLimit` so the agent can tell conditional headroom from a hard wall. ## How resizing behaves - **Bursting comes first.** Because compute scales up and down on demand, most heavy work needs no resize at all. On Modal, raising the paid reservation does not raise `burstLimit`, so Hoplite skips a disruptive replacement when it would add no usable capacity. Reduce memory or parallelism, or raise the plan, project, or provider ceiling instead. - **Scaling up** (`sandbox_resize_up`) is usually automatic. Policies can set approval thresholds, so a large jump may pause for your sign-off even below the ceiling. - **How a change is applied depends on the active provider.** A provider can update a resource live, restart the runtime, or reject an unsupported axis. Hoplite reports the mode and never assumes that running background processes survived a disruptive change. - **Scaling down** (`sandbox_resize_down`) covers CPU and memory only and requires your [approval](/docs/threads) because the provider may restart the runtime. Modal, the default provider for new workspaces, bills whichever is higher — the reservation or actual usage — so bursting costs what the work costs. Changing the reservation replaces the sandbox with a snapshot restore: it takes a couple of minutes and restarts running processes; the agent is told this so it can restart dev servers afterwards. Modal does not support disk resizing — the agent reports that axis as unsupported instead of claiming a change was applied. A provider restart stops running [previews](/docs/sandboxes/previews) and background processes. The result reports whether the operation was disruptive. ## Running out of space Daytona compatibility workspaces automatically grow their disk by 50% when they report `ENOSPC`, rounded up and capped at the effective disk ceiling. Setup then retries once, because dependency installation is safe to repeat. Other failed commands are never replayed automatically — the agent inspects the preserved failure and retries deliberately after the sandbox restarts. Modal cannot resize disk. If its ephemeral disk is so full that a guest command cannot start during archive, Hoplite skips the archive hook and preserves the worktree with a control-plane directory snapshot before terminating the runtime. That archive is recoverable but degraded: hook cleanup did not run, and only the worktree — not arbitrary files elsewhere in the sandbox filesystem — is preserved. ## Sitemap See the full [sitemap](/docs/sitemap.md) for all pages. Well-known sitemap: [/docs/.well-known/sitemap.md](/docs/.well-known/sitemap.md).