Resources and scaling

CPU, memory, and disk limits — and how the agent resizes the sandbox

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:

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 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 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.