Storage & residency
Two of the seven axes, in depth: how much scratch disk a run gets, and whether its VM survives between runs.
Scratch storage — storage_mib
An ephemeral drive, sized in MiB, sealed at VM boot and wiped at teardown — it never survives past the VM that made it. The default depends on the run's preset: 64 MiB on std.micro, 128 MiB on std.small, 256 MiB on std.medium and mem.large, 512 MiB on std.large and mem.xlarge and 1024 MiB on std.xlarge and cpu.large.
The disk is reserved in full when the VM boots, and the same size is what your plan is charged for scratch. A webhook-triggered run does not reconfigure the task: it always gets the preset's default. See Presets & limits for each plan's limit.
The storage-clamped notice
When a declared size is raised to the preset default, the reply to task:run (and to a scheduled run, task:run --at) lists what changed in notices. The CLI prints one line:
Note: storage_mib 1 is below the std.xlarge default (1024 MiB). The run uses 1024 MiB.
With --json the same notice is {"code":"storage-clamped","preset":"std.xlarge","requested":1,"effective":1024}. A scheduled run is checked twice: at --at time (you get the notice) and again when it fires, against your plan as it is then. A webhook run declares no size, so it never gets a notice.
VM residency — residency
Pinning must be requested explicitly — it is never a side effect. It also requires cardinality: many or continuous: a one-shot VM tears down after its single unit, so there is nothing to pin (rejected at deploy). Not every tier may pin at all — see Presets & limits.