--- title: "Resources and scaling" description: "Use elastic compute for cloud builds and previews, with visibility into reservations and limits." 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: Use elastic compute for cloud builds and previews, with visibility into reservations and limits. Related: /docs/sandboxes, /docs/sandboxes/previews, /docs/threads # Resources and scaling Sandboxes scale compute elastically. On Modal, the default provider, a sandbox's size is its *box*: the CPU and memory it is billed for per hour and the most it may use. It reserves only a small minimum and bursts up to the box as the workload demands, so a heavy install, build, or dev server does not require a resize. On other burstable providers the reservation is a guaranteed paid floor under a separate conditional *burst limit*. 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. ## Box sizes The boot size and ceiling are chosen from a fixed ladder of presets in **Settings → Workspace → General** (organization default) and **Settings → Project → Sandbox** (per-project override). You can also choose a box size in the new-thread composer for that thread without changing either default. Plan limits still apply; a different size cannot reuse a prewarmed workspace built for the project default. | Preset | CPU | Memory | | --- | --- | --- | | X Small | 1 vCPU | 4 GiB | | Small | 2 vCPU | 8 GiB | | Medium | 4 vCPU | 16 GiB | | Large | 8 vCPU | 32 GiB | | X Large | 16 vCPU | 64 GiB | Every preset has 4 GiB of memory per vCPU. Sandboxes without a configured size are Medium, clamped to your plan: Free tops out at Small and Plus at Large. An unsized Docker Compose VM boots at 4 vCPU / 8 GiB instead, because a VM reserves its whole size; it is still billed as Medium. See [billing](/docs/workspace/billing) for each size's hourly price. Presets above your plan's sandbox limit stay listed in the dropdown but are locked, with a padlock and a pill naming the plan that unlocks them. A value saved before presets existed that matches no row shows as *Custom* with its exact CPU and memory until a preset is picked. On Modal the box is the burst limit, and `sandbox_status` reports it under `burstLimit` (with `boxLimited: true`) so the agent can tell its headroom from a hard wall. On Modal, Hoplite sets `OMP_NUM_THREADS`, `OPENBLAS_NUM_THREADS`, `MKL_NUM_THREADS`, and `BLIS_NUM_THREADS` to the sandbox's burst CPU limit. It does this for setup and for agent commands, overriding Modal's single-thread default. GNU `nproc` honours `OMP_NUM_THREADS`, so `make -j$(nproc)`, CMake, Ninja, and NumPy or SciPy linear algebra use the burst capacity instead of a single core. Faster commands can use more billed core-seconds. If your build can't afford that much parallelism, set lower values in your setup script's environment, because those values are applied afterwards and take precedence. ## How resizing behaves - **Bursting comes first.** Because compute scales up and down on demand, most heavy work needs no resize at all. On Modal, resizing changes the box, which raises both the usable limit and the hourly price. When a command is killed for running out of memory, Hoplite moves the sandbox up one box size automatically, within your plan ceiling and runtime policy. On other burstable providers a resize that would add no usable capacity is skipped; reduce memory or parallelism, or raise the plan, project, or provider ceiling instead. - **Scaling up** (`sandbox_resize_up`) is usually automatic. Cloud runs do not pause for tool approval; plan and runtime policies still constrain the requested size. - **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 can restart the runtime. Cloud runs auto-approve the tool call; local CLI and desktop approval rules are unchanged. On Modal, a sandbox is billed at its box's fixed hourly price, per second, whatever it uses within the box. Changing the box 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 Sitemap discovery is not enabled for this deployment.