> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sfcompute.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Reselling
> Recover credits by selling unused reserved compute
Reselling is the mechanism that lets a pool owner offer unused allocation back into the SF Compute
market. When another buyer takes that allocation, it is removed from the seller's pool schedule and
the seller receives credits with the platform fee deducted.
Most AI companies are stuck between three competing priorities:
1. **Securing compute in advance** (so capacity is available when they need it).
2. **Achieving the lowest possible GPU/hr price** (typically requires a long term contract).
3. **Not paying for unused compute.**
On most clouds, long-term reservations offer the best per-GPU pricing compared to on-demand
instances, but they require commitments on the order of months to years. Most companies can't
predict their needs that far out, and very few groups need continuous access to GPUs.
Until now, these priorities have been mutually exclusive. You either lock in a great rate and accept
idle time, or you pay a premium for flexibility. Reselling changes this dynamic.
## Why resell?
When you place a reservation on SF Compute, you can resell unused compute capacity to recoup a
portion of your cost.
This means you can:
* **Reserve more aggressively** — lock in the capacity and pricing you want without worrying about
over-committing.
* **Recover cost on idle time** — nights, weekends, gaps between training runs, or any period where
your instances would otherwise sit unused.
* **Treat your reservation like a flexible asset** rather than a sunk cost.
## How reselling works
### The basics
When you resell, you are offering an allocation of your reserved compute on the SF Compute platform.
Once a sell order is placed it remains `standing` until another customer purchases the
allocation.
Let's walk through a simple case study of placing orders into a [pool](/preview/pools) and then
selling from it.
First, you place an order for 5 instances for 14 days.
```bash theme={null}
sf orders create --side buy --pool production-inference --nodes 5 --start now --duration 14d \
--max-rate 20.00 --instance-sku isku_4UpxzQw7A8N
```
Then, you place a second order for 2 instances because you expect a spike in compute usage.
```bash theme={null}
sf orders create --side buy --pool production-inference --nodes 2 --start "in 3d" --duration 5d \
--max-rate 20.00 --instance-sku isku_4UpxzQw7A8N
```
Some time later, you decide that for 3 days over a holiday only a couple instances are needed, so
you sell 6 instances.
```bash theme={null}
sf orders create --side sell --pool production-inference --nodes 6 --start "in 7d" --duration 3d \
--min-rate 10.00 --instance-sku isku_4UpxzQw7A8N
```
Once the sell order fills, the sold allocation is removed from your pool and you receive credits
with the platform fee deducted. Your remaining allocation (in green) stays intact aside from the
block that was sold.
### What happens to your instances when you sell
Instances running in a pool must be supported by an active allocation. If an allocation is
insufficient to support all instances then some instances will be terminated.
Here is a visualization of how instance allocations are maintained within a pool.
To stay in control of which instances survive, manually terminate the ones you don't need before
your allocation decreases.
```bash theme={null}
sf instances terminate
```
## Selling dynamics
Here are some things to keep in mind when reselling to make sure your compute finds a buyer on our
platform.
* **Choose a price that's likely to find a buyer** — setting `min-rate` below current prices makes
your order more likely to match.
* **Large compute blocks are harder to sell, consider breaking them up** — larger sell orders are
harder to find a buyer for. Consider selling in increments of 1 hr x 1 instance.
* **The compute is yours until the standing sell order fills** — a sell order will exist in
`standing` until a matching buy order is found. Only once a buy order is found will the sold
allocation be removed from your pool.
* **Partially expired sell orders can still find a buyer** — even if part of a sell order has
expired, a buy order can still fill the remainder.
* **Sell in advance** — selling well ahead of expiration increases the odds that your sell order
finds a buyer.
Finally, it's important to remember that you're not guaranteed to find a buyer.
## Pricing
### How orders are filled
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 was placed first:
* **If your sell order is already standing and a buy order comes in**, the order fills at your sell
price (the lower price). The buyer benefits from your competitive pricing.
* **If a buy order is already standing and your sell order comes in**, the order fills at the buy
order's price (the higher price). You benefit from the buyer's willingness to pay more.
This means you can earn more than your `min-rate`. Setting a competitive `min-rate` increases your
chances of finding a buyer, while still allowing you to receive a higher price if a standing buy
order is already waiting.
### Platform fee
SF Compute takes a variable platform fee to facilitate the transaction. This fee is deducted from the
credit you receive from the resell.