Skip to main content
Reselling lets you offer unused allocation from your pool for sale on the SF Compute orderbook. When another buyer takes that allocation, SF Compute removes it from your pool and pays you credits, minus a platform fee.

​
Why sell unused allocation

When you place a reservation on SF Compute, you can resell compute time you don’t use and recoup part of its cost. That lets you reserve for your peak without paying for idle time: nights, weekends, and gaps between training runs.

​
How reselling works

When you resell, you offer part of your pool’s allocation for sale. The sell order remains standing until another buyer purchases the allocation. This example places orders into a pool, then sells from it. First, you place an order for 5 nodes for 14 days. Each node runs 1 instance.
Then, you place a second order for 2 nodes because you expect a spike in compute usage.
Later, you need only 2 instances for 3 days over a holiday, so you sell 3 nodes.
Each panel below shows the pool’s allocation schedule after one of those orders. Every rectangle is one node for one day, so the shaded shape is what you hold and the space above it is what you don’t. Step through the panels to follow the sale. Hover any point to see the nodes you hold then.

​
How allocation is tracked

A pool records allocation as a net schedule per instance SKU, the hardware configuration you bought: buys add to the schedule and sells subtract from it. What you retain is that aggregate schedule, not a set of individually addressable purchases. You can therefore offer any sub-window of your allocation, not only a whole window or its tail. Only the slice that trades leaves the pool. Because the schedule is aggregate, how you bought the compute time doesn’t matter. Compute time bought through a spot deployment resells the same way as a firm reservation. See Pools for the full allocation-ledger model.

​
How a sell order fills

By default a sell order fills completely or not at all. If you pass --allow-partial, buyers take whatever part of the standing order overlaps their own orders. One sell can then fill as several arbitrary, non-contiguous slices over time, not in a single block. Fills are quantized to 1 minute, and there is no minimum-fill setting. A standing sell can fill in slices as small as 1 node-minute; a 17-minute slice is a valid fill. The order’s fills array and filled_allocation_schedule_delta report the exact segments that traded. Reconcile against those rather than assuming a whole-window or fixed-size fill.

​
What happens to your instances when you sell

An active allocation must back every instance running in a pool. If the allocation cannot support every instance, SF Compute terminates the excess. It starts with the lowest priority and, among instances of equal priority, terminates the newest first. Each bar below is one instance, drawn against the allocation from the two buy orders above. The sale drops the pool to 2 nodes for 3 days, so SF Compute terminates the 3 instances it can no longer back. Hover a bar for that instance’s state.
To stay in control of which instances survive, manually terminate the ones you don’t need before your allocation decreases.
Terminate an instance by name.

​
How to make a sell order fill

These practices make your sell order more likely to fill:
  • Set your min-rate below current prices.
  • Sell in small increments, such as 1 node for 1 hour, since large blocks are harder to place.
  • Sell early rather than close to expiry, so more incoming buy orders can reach your order.
  • Leave a partly expired sell order in place, because a buy order can still fill the remainder.
  • Keep several sell orders open on the same pool. There is no one-open-sell-per-pool limit.
Until a matching buy order arrives, your order sits in standing and the compute time is still yours.
You’re not guaranteed to find a buyer.

​
Pricing

Two things determine what you receive from a resale: the fill price and the platform fee.

​
How the fill price is set

When you place a sell order, you set a min-rate, the lowest price you’re willing to accept. The actual fill price depends on which order came first. If your sell order is already standing when a buy order comes in, the order fills at your sell price. If a buy order is already standing, your order fills at that buy price, at or above your min-rate. A min-rate below current prices improves your odds of a match, and a fill against a standing buy order can still pay more than that min-rate.

​
Platform fee

When a sell order fills, SF Compute deducts a platform fee from your proceeds. The fee has two parts: a flat amount per node-hour and a percentage of the fill value. On the 3-node, 3-day sale above, you pay the flat amount on 216 node-hours plus the percentage of what that fill earned. SF Compute sets both parts. They can differ by organization and change over time, so rely on the estimated fee the CLI shows before you confirm an order. The fee never exceeds the fill value, so filling a sell order never costs you credits. The fee comes out of your proceeds, and SF Compute does not add it to the buyer’s price. The prices in the order’s fills array are gross execution prices, the same figures the buyer pays. The credits you receive equal the fill price minus the fee.

​
Next steps

  • Pools: how a pool’s allocation schedule backs your instances
  • Orders: order statuses, flags, and sell fees
  • Instances: instance priority and lifecycle