Create a pool
A new pool starts with no allocation.List pools
List the pools in your workspace.View a pool
Get a pool by name or ID.Allocation schedule
The allocation schedule shows how many nodes you have over time on this pool. The schedule gains time when a buy order fills and loses time when a sell order fills. You can create instances on a pool before it has allocation. They start running when allocation becomes available and stop when it runs out. The schedule is a net node count over time, not a ledger of the orders that built it. Filled buy and sell orders each add or remove a schedule segment (see Orders), but the pool keeps only the running total at each instant. There’s no stable identifier for an individual segment: 2 fills of the same SKU and time range are indistinguishable once merged into the total. To track which order added or removed a given block of time, keep the order’s own ID.Mixed hardware
A single pool can hold allocation across several SKUs. Each order fills against whatever SKU matches its requirements, and the schedule tracks each SKU’s allocation independently. Within a SKU, nodes are interchangeable, so the schedule tracks a node count, not which physical machine is running it. For example, a pool might hold 100 H100 nodes insea-3 from 9am to 5pm today. It could hold 50
more H100 nodes in iad-12 from 5pm today to 9am tomorrow. The SKUs do not need to overlap in time;
the schedule records what was bought and when.
Run sf pools get dev --verbose to see a separate schedule block per SKU in addition to the
aggregate TOTAL SCHEDULE.
Buy more on an existing SKU
To add allocation to a SKU you already have, pass its ID via--sku on the buy order. Each
SKU has a stable ID (sku_...) that pins the order to exactly that SKU.
sf pools get dev --verbose or sf skus list to find the ID.
Transfers
Transfers move nodes between 2 pools for a specified window of time.Create a transfer
Specify the source pool, destination pool, time window, node count, and SKU.--from or --to pool is located in a
different workspace.
List transfers
List the transfers in your organization.--verbose for the schedule details of each
transfer.
Get a transfer
Get a transfer by ID.Protect instances from termination
A pool’s allocation can drop below the number of running instances when a sell order fills, a spot deployment scales down, or a transfer leaves. When that happens, SF Compute terminates instances until the running count matches the schedule, lowest priority first, newest first within a priority. To keep specific instances running when allocation shrinks, raise their priority. The system keepscritical instances over everything else.
Extend a pool
Extending places a buy order that continues the schedule’s final node count to a new end time.--duration or --stop, plus
--max-rate or --max-price.
Fetch the pool again; the schedule now ends 2 hours later.