Skip to main content
This feature is in public preview.
The orderbook is the public, anonymized record of buy and sell orders on the market. Each order states its side, node count, instance SKU, delivery window, and limit price. Conceptually: Orderbook with three example resting orders: a Buy for 8 H100s on Sep 1 9am to Sep 4 5pm at up to $17.42/node-hr, a Sell for 4 B200s on the same window at $17.38 minimum, and a Buy for 16 H200s on Oct 15 12am to Oct 22 12am at up to $16.95. The trading engine matches compatible buys and sells continuously. Open orders make up the live book; filled orders and their executions provide market history. Orderbook responses never expose participant, pool, capacity, or procurement identity. Endpoints live under /preview/v2/orderbook/:
  • /windows — active instance SKU and delivery-window combinations in a time range.
  • /quote — top of book (best bid + best ask) for one exact window.
  • /depth — live book aggregated at every instance SKU and price level.
  • /fills — individual executions produced when orders match.
/windows, /quote, and /depth are derived views of open orders, while /fills is an execution-level view. To create, cancel, or inspect your own workspace’s orders, see Orders. The hardware filter is ?requirements=key:value, e.g. accelerator_type:H100, zone:richmond, or accelerator_type:H100,H200;zone:richmond to combine filters. The filter matches every instance SKU satisfying those requirements. All timestamps are Unix epoch seconds. Field names use the _at suffix.

​
Windows

Enumerate every instance SKU and delivery window that currently has resting orders matching the requirements filter, within a time range. Three example delivery windows displayed as horizontal bars on a Sep 1 to Sep 29 time axis, each showing its bid and ask counts.
A window is included when it has at least one resting order matching the filter and falls entirely within the range. best_bid / best_ask are omitted when that side is empty. Results are sorted ascending by (start_at, end_at, instance_sku) and cursor-paginated. limit defaults to 50 and caps at 200; the range is capped at 365 days.

​
Quote

Top of book for one exact window: the highest bid and lowest ask. A vertical price ladder showing best ask of $17.42 with 2 nodes above best bid of $17.38 with 4 nodes, with a vertical bracket between them labeled spread $0.04.
Each side carries the total node_count available at that rate and instance SKU. If multiple SKUs tie at the best price, the lowest instance SKU at that price is returned; use /depth to inspect every SKU at the price level.

​
Depth

Depth of book aggregated by instance SKU and per-node-hour rate across the hardware matching the requirements filter. Individual orders and participants are not exposed. Level II ladder showing two ask price levels above the spread and three bid price levels below, with horizontal bars whose lengths encode the node count at each price.
Bids are sorted by descending rate (best bid first); asks are ascending. Orders at the same per-node-hour rate and instance SKU collapse into one level. depth defaults to 20 and caps at 100 per side.

​
Fills

List individual executions for one exact delivery window. A single order can produce multiple fills, and each fill records the capacity and price that actually traded.
since_at is a lower bound on when the fill was recorded. It defaults to 7 days before the request. Values more than 30 days before the request return 422. Results are sorted newest first and cursor-paginated. limit defaults to 50 and caps at 200. Participant identity is never exposed.

​
Allocation schedule deltas

allocation_schedule_delta describes how many nodes an order requests or offers during one or more time intervals. An allocation_schedule_delta JSON entry mapped to eight nodes over a time interval. start_at supplies the time for vertices A and B, end_at supplies the time for C and D, and node_count supplies the value for B and C. Each object in the array is one schedule segment. start_at and end_at set the segment’s time bounds, while node_count specifies how many nodes apply during that interval. Multiple entries can describe different node counts over adjacent intervals. Schedule entries describe half-open intervals [start_at, end_at): the node count applies at start_at, but not at end_at. Adjacent entries therefore meet without overlapping. All segments on an order refer to that order’s single instance_sku. Orders are submitted with one node count over one delivery window, so allocation_schedule_delta normally contains one segment. filled_allocation_schedule_delta describes the portion that has executed so far and may contain multiple segments when different parts of the order fill over different intervals. Subtract the filled node count from the requested or offered node count at each instant to get the capacity that remains on the book. For a buy, every filled segment adds to the destination pool’s allocation schedule; for a sell, it removes that segment. An orderbook fill reports the exact schedule segment that traded. To calculate the compute represented by a schedule, sum node_count × duration_hours across its entries.