Skip to main content
Sandbox creation can request compute resources. A deployment either serves the request exactly or refuses it at admission.

​
Resources

Requests are burstable: a sandbox is guaranteed its requested shape and may use idle node capacity beyond it. A sizing field you leave unset resolves to the deployment default. A value you set explicitly is honored as requested, or the create fails. A create is never accepted and then silently provisioned at a different shape. There is no disk-size or architecture field. /workspace sizing follows the storage class you select, not a per-create budget. The CLI exposes sizing directly on create:
--cpus accepts exact decimal cores with up to three fractional digits, such as 0.05, 0.125, or 1.5. The API and JSON responses use integer cpu_millis so clients never depend on floating-point rounding. Omit either flag to take the deployment default. Accelerator model preferences are expressed through the API’s gpus.models field rather than a CLI flag.

​
Placement classes

--placement-class standard is the default. It adds no node constraint: the deployment remains spot-first and may fall back to on-demand capacity when spot is unavailable. --placement-class non-preemptible requires capacity the infrastructure provider does not reclaim for capacity reasons. A deployment that has not bound that class to matching nodes refuses the create with unsupported_capability; it never silently runs the request on spot. The class does not promise dedicated tenancy or immunity from host failure, provider health events, node drains, or operator action. It currently uses the same create authorization and has no separate billing gate. It may take about a minute to create when a matching node must cold-provision. Placement is immutable for a sandbox. A stop/start keeps its original class and node binding. A new sandbox created from a snapshot chooses independently and defaults to standard unless the create names --placement-class non-preemptible again.

​
Accelerators

GPU requests are refused on the current runtime. --gpus and the API’s resources.gpus field are part of the contract, but no deployment advertises schedulable accelerator capacity, so a nonzero count is rejected at admission with unsupported_capability and the message gpu resources have no schedulable capacity in this deployment. No sandbox is created and the name is not consumed.
There is no runtime profile or accelerator-model flag on hiloop sandbox create. A sandbox’s environment comes from an image or a snapshot; see sandboxes.

​
How a deployment refuses

Capabilities are not discovered through an endpoint. A deployment states what it cannot serve by refusing the request that needs it, at admission, with a named error: Requests refused this way on the current runtime are accelerator counts, volume mounts, and secret bindings, plus --storage-class durable on a cluster that names no backing storage class, and --placement-class non-preemptible on a deployment with no binding for it. What’s live today is the current list. Admission never weakens a request to make it fit. If a deployment cannot enforce exactly what you asked for, you get an error instead of a sandbox that quietly differs from it. For the fixed network floor and fail-closed secret admission, see egress and secrets.