> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ornn.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How bid-based pricing works on Ornn
> Learn how Ornn's bid-based pricing model works, the lifecycle a bid moves through from down-payment to reservation, and how to withdraw a bid before it's accepted.
Ornn uses a bid-based pricing model rather than fixed spot pricing. When you want to reserve GPU capacity, you submit a bid that states how much you're willing to pay per GPU-hour. You complete a down-payment up front; the bid then enters review and, once accepted, is promoted to a confirmed reservation.
## How bidding works
You submit a bid from the reservation form for a specific deployment. The bid records the GPU count you want, the date range, and the price per GPU-hour you're offering. Before the bid can be reviewed, you complete checkout and pay the down-payment. Once the down-payment clears, the bid is **Active**. The Ornn team reviews active bids and either accepts or rejects them. Accepted bids are later promoted to confirmed reservations.
## Bid lifecycle
A bid moves through the following states. The web app shows each label by rendering the underlying status (it replaces underscores with spaces and capitalizes the first letter). The raw status values shown in the CLI and detail pages are listed for reference.
Deposit pending
Under review
Bid accepted
Reservation created
Withdrawn
Expired
Rejected
Exits
| Label | Meaning | Underlying status |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------ | --------------------- |
| **Pending deposit** | Checkout creates the bid. The bid is not reviewable until you pay the down-payment invoice. | `pending_deposit` |
| **Active** | The down-payment is settled. The bid is live and visible to the Ornn team for review. | `active` |
| **Accepted** | The Ornn team approved your bid. The accepted GPU count and bid price are locked in. | `accepted` |
| **Reservation created** | The accepted bid has been promoted to a confirmed reservation. From here, you manage the reservation, not the bid. | `reservation_created` |
A bid can also end in a terminal state without becoming a reservation:
| Label | Meaning | Underlying status |
| ------------- | ---------------------------------------------------------- | ----------------- |
| **Rejected** | The Ornn team did not accept the bid. | `rejected` |
| **Withdrawn** | You withdrew the bid before it reached a terminal outcome. | `withdrawn` |
| **Expired** | The bid timed out before being accepted or rejected. | `expired` |
Checkout and the down-payment happen **before** a bid is reviewable, not after acceptance. Accepted bids are then promoted to reservations without a second checkout step.
## What you submit in a bid
When you submit the reservation form, the bid captures:
* **GPU count**: how many GPUs you want to reserve.
* **Minimum GPU count**: the smallest count you would accept if the full quantity is not available. Set it equal to the requested GPU count to require the full count.
* **Start date and end date**: the term you want.
* **Bid price per GPU-hour**: your offered price, in USD.
When the bid is accepted, the accepted GPU count and an `accepted_at` timestamp are recorded. The accepted count can match your requested count or fall to your minimum.
### Field reference
For scripted use, the bid record exposes these raw fields:
| Field | Type | Description |
| ------------------------ | -------- | -------------------------------------------------------------- |
| `deployment_id` | UUID | The deployment the bid targets. |
| `gpu_count` | integer | Requested GPU count. |
| `min_gpu_count` | integer | Minimum acceptable GPU count. May be `null`. |
| `start_date` | date | Requested start. |
| `end_date` | date | Requested end. |
| `bid_price_per_gpu_hour` | number | Offered price per GPU-hour, USD. |
| `status` | string | One of the lifecycle values above. |
| `accepted_at` | datetime | When the bid was accepted. `null` if not yet accepted. |
| `accepted_gpu_count` | integer | GPU count locked in at acceptance. `null` if not yet accepted. |
## Pricing your bid
The reservation form's summary rail shows a **Rate (Buy-now price)** figure: the deployment's buy-now price per GPU-hour. This price is the ceiling on your bid. You can bid up to it, but not above it.
Bidding at or near the buy-now price improves your chances of acceptance, while a lower bid trades acceptance odds for a lower rate.
## Updating or withdrawing a bid
You can update or withdraw a bid while it is **Pending deposit** or **Active** (that is, before it's accepted, rejected, withdrawn, or expired).
* **Update**: from the bid detail page, change the GPU count, minimum GPU count, dates, or price, then save. All bid fields are submitted together.
* **Withdraw**: from the bid detail page, click **Withdraw bid** to close the bid. The CLI command for the same action is `ornn bid withdraw `.
Once a bid is **Accepted**, **Reservation created**, **Rejected**, **Withdrawn**, or **Expired**, it can no longer be updated or withdrawn.
## Managing bids from the CLI
All bid actions are available through the Ornn Compute CLI:
```bash theme={null}
ornn bid create --gpu-count 8 --min-gpu-count 4 \
--start-date 2026-06-01 --end-date 2026-07-01 --price 2.75
ornn bid list
ornn bid show
ornn bid update --gpu-count 8 --min-gpu-count 4 \
--start-date 2026-06-01 --end-date 2026-07-01 --price 3.10
ornn bid withdraw
```
`ornn bid withdraw` is the CLI equivalent of **Withdraw bid** in the web app. See the [Ornn Compute CLI](/cli) for full syntax.
## What's next
Complete the down-payment so your bid moves into review.
Track active bids, withdraw pending offers, and see what happens after acceptance.