Skip to main content
This feature is in public preview.
A pool is a named container that holds a compute allocation schedule. You buy compute time into a pool with orders, and instances on the pool run during the scheduled time slots. Buy orders add time to the schedule, sell orders remove it. You can also move compute between pools with transfers.

Create a pool

List pools

View a pool

Allocation schedule

The allocation schedule shows how many nodes you have over time on this pool. Each time a buy order fills, the schedule gains time. Each time a sell order fills, it loses time. Instances on the pool can be created before there is allocation. They start running when allocation becomes available and are terminated when it runs out.

Mixed hardware

A single pool can hold allocation across several instance SKUs. Each order is filled against whatever SKU matches its requirements, and the allocation for each SKU is tracked independently. For example, a pool might hold 100 H100 nodes in sea-3 from 9am to 5pm today, plus 50 H100 nodes in ams-1 from 5pm today to 9am tomorrow. The SKUs do not need to overlap in time; the schedule simply records what was bought and when. Run sf pools get <name> --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 --instance-sku on the buy order or procurement. Each SKU has a stable id (isku_...) that targets exactly that pool.
Run sf pools get <name> --verbose or sf instance-skus list to find the id.

Transfers

Transfers move nodes between two pools for a specified window of time.

Create a transfer

Start and end times must be aligned to a minute boundary. Relative times are rounded up to align with the next minute. Omitting a required flag opens an interactive picker to help you fill in the remaining values. Specify the full resource path if the --from or --to pool is located in a different workspace.

List transfers

Filter by pool (repeatable) or status, or pass --verbose for the full schedule of each transfer.

Get a transfer

Protect nodes from termination

When a pool’s allocation drops below the number of running nodes (a sell order fills, a procurement scales down, or a transfer leaves), the newest nodes are terminated until the schedule and the running count match. To protect specific nodes against sale down, transfer their allocation onto a separate pool with no procurement and no standing sell orders. Allocation on that pool can only shrink through explicit action, so the nodes there stay up.

Rename a pool

Delete a pool

Extend a pool

This will automatically place an order that extends the node count at the end of the pool schedule out to a desired end time. For instance, consider the following pool.
We can extend it for two hours. Notice that the end time has extended by two hours.
Extension requires availability during the requested window.

API reference

See the Pools API for programmatic access.