> ## Documentation Index
> Fetch the complete documentation index at: https://docs.compute-desk.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Indexes
> Which indices exist, how to find the ones you hold, and the two row shapes they come in
Every published GPU price index is served from one place, `/v2/gpu/rental/indexes`, through the
same four endpoints as every other data type. What makes indices different from the other types
is that **a request names one index**: `id` is required on `/latest`, `/as-of` and `/history`, and
a response is always a single series.
## Finding your indices
Start with [`/metadata`](/pricing/endpoint/gpu-rental-indexes-metadata). It lists every index your
token holds — and only those — one entry per index:
```json theme={null}
{
"id": "rental-h100-1y-us-daily",
"index_type": "daily-blended",
"row_type": "daily",
"asset": "rental",
"tenor": "1y",
"publication": "daily",
"interval": "P1D",
"title": "H100 · US blended index",
"gpu_family": "hopper",
"gpu_group": "h100",
"region_group": "US",
"contract_type": "combined",
"vendor_category": "neocloud",
"source": "gx"
}
```
* **`id`** is what the data endpoints take. An id you do not hold returns `404`, the same as an
id that does not exist, so `/metadata` is the only way to discover what you can read.
* **`index_type`** says what kind of index it is: its cadence and methodology family as one label.
* **`row_type`** says which row shape its points take, and so which schema to expect — see below.
* **`asset`**, **`tenor`** and **`publication`** are three of the five fields the `id` spells
(see [Reading an id](#reading-an-id)); the other two are already here as `gpu_group` or
`gpu_family`, and `region_group`. Filter on these rather than parsing the id.
* **`interval`** is the exact publication interval as an ISO-8601 duration. Read it from here
rather than assuming it from `publication`: two indices that both print `intraday` may do so at
different intervals.
* **`source`** is who computes the index — `compute-index` for our own, `gx` where General Index
administers it and publishes the level. GX points carry no `p5`/`p95` envelope.
Access is granted index by index, so two tokens in the same organisation can hold different
lists. See [Authentication](/pricing/authentication#what-your-token-can-read).
## Two row shapes
Every row has the same six fields: `id`, `type`, `timestamp`, `value`, `p5` and `p95`. What differs
is what `timestamp` holds, and `type` on the row — the same value as `row_type` in `/metadata` —
tells you which you have.
| `row_type` | `timestamp` | one row is | schema |
| ---------- | ------------------------------------------ | -------------------------------------------- | ------------------ |
| `daily` | a calendar date, `2026-09-02` | one published day | `DailyIndexRow` |
| `intraday` | a UTC instant, `2026-09-02T10:00:00+00:00` | one completed interval, stamped at its start | `IntradayIndexRow` |
A daily point is deliberately **not** rendered as a midnight instant: a date is a date, and turning
it into `00:00:00Z` would read as the previous evening in half the world's time zones. So the two
shapes are separate schemas, and the OpenAPI document declares `type` as the discriminator between
them — an SDK generated from it gives you a tagged union you can switch on.
```json theme={null}
{"id": "rental-h100-1y-us-daily", "type": "daily", "timestamp": "2026-09-02", "value": 2.7000, "p5": null, "p95": null}
{"id": "rental-h100-1y-us-intraday", "type": "intraday", "timestamp": "2026-09-02T10:00:00+00:00", "value": 2.7581, "p5": 2.61, "p95": 2.84}
```
Because a request names one index, a response never mixes the two. When a new kind of index
arrives with a different shape, it gets a new `row_type` and a new schema, and only requests for
that index see it.
Two things follow for the time parameters:
* **`/as-of?at=…`** resolves against the shape. A daily index maps `at` to its UTC calendar date
and answers with the most recent published day on or before it; an intraday index answers with
the last completed interval at or before the instant. Either way a non-publication moment carries
back rather than returning nothing.
* **`/history`** windows are half-open on both shapes. Bound a daily index with dates and an
intraday index with instants; a bare date for `end` means the end of that day on either.
## Reading an id
Every id spells five fields, hyphen-separated, in this order:
```
{asset}-{object}-{tenor}-{region}-{publication}
rental-h100-1y-us-daily the daily blended H100 index, US
rental-h100-1y-us-intraday the same GPU at 30-minute resolution
rental-composite-1y-us-daily the reference price over the daily indices
```
| field | what it says | values today |
| ------------- | ---------------------------------------------------- | ---------------------------------------------- |
| `asset` | what is priced | `rental` |
| `object` | the instrument — a GPU, a GPU family, or `composite` | `h100`, `hopper`, `composite`, … |
| `tenor` | the contract basis the level is quoted on | `1y` — a one-year-reserved-equivalent GPU-hour |
| `region` | the trading region | `us` |
| `publication` | how the series prints | `daily`, `intraday` |
A hyphen only ever separates fields, so a value never contains one — a future sub-region would be
`us_east`. The first three fields say what is priced; the last two say where and how often it
prints, so the ids for one instrument sort together and differ only at the end.
## Available indices
The full catalogue. Your `/metadata` shows the subset your token holds.
| `id` | `index_type` | covers | cadence | new values | `source` |
| ------------------------------ | ------------------ | -------------------------------- | ----------------------- | --------------------------------- | --------------- |
| `rental-hopper-1y-us-daily` | `daily-blended` | Hopper family · US | daily, US business days | calculated 16:30 ET | `gx` |
| `rental-blackwell-1y-us-daily` | `daily-blended` | Blackwell family · US | daily, US business days | calculated 16:30 ET | `gx` |
| `rental-h100-1y-us-daily` | `daily-blended` | H100 · US | daily, US business days | calculated 16:30 ET | `gx` |
| `rental-h200-1y-us-daily` | `daily-blended` | H200 · US | daily, US business days | calculated 16:30 ET | `compute-index` |
| `rental-a100-1y-us-daily` | `daily-blended` | A100 · US | daily, US business days | calculated 16:30 ET | `compute-index` |
| `rental-b200-1y-us-daily` | `daily-blended` | B200 · US | daily, US business days | calculated 16:30 ET | `compute-index` |
| `rental-b300-1y-us-daily` | `daily-blended` | B300 · US | daily, US business days | calculated 16:30 ET | `compute-index` |
| `rental-h100-1y-us-intraday` | `intraday-blended` | H100 · US | every 30 minutes | continuous, on a UTC grid | `compute-index` |
| `rental-h200-1y-us-intraday` | `intraday-blended` | H200 · US | every 30 minutes | continuous, on a UTC grid | `compute-index` |
| `rental-a100-1y-us-intraday` | `intraday-blended` | A100 · US | every 30 minutes | continuous, on a UTC grid | `compute-index` |
| `rental-b200-1y-us-intraday` | `intraday-blended` | B200 · US | every 30 minutes | continuous, on a UTC grid | `compute-index` |
| `rental-b300-1y-us-intraday` | `intraday-blended` | B300 · US | every 30 minutes | continuous, on a UTC grid | `compute-index` |
| `rental-composite-1y-us-daily` | `daily-composite` | all NVIDIA data-center GPUs · US | daily, US business days | calculated after the daily fixing | `compute-index` |
All index values are denominated in **\$/GPU-hr**. Every index covers the combined on-demand and
reserved contract pool across neocloud vendors, as `contract_type` and `vendor_category` record on
its `/metadata` entry.
`rental-composite-1y-us-daily` is the **GPU reference price**: what the average rented GPU-hour costs across the
fleet, as the rentable-capacity-weighted mean of the daily per-GPU blended indices. It spans every
family, so its `/metadata` entry has `gpu_family` and `gpu_group` null, and it is published without
an envelope, so `p5` and `p95` are null on every row.
The daily indices publish on US business days, so a weekend or a holiday adds no new value. That
is not a gap you have to handle: `/as-of` carries back to the most recent published date rather
than returning nothing — see [Concepts](/pricing/concepts).
**The newest intraday interval is always a completed one.** The rolling forward buffer is never
served, so the latest `timestamp` is at most one interval behind now — call `/latest` a moment
after the half-hour and you get the interval that just closed, never a partial one.
## Next steps
The indices your token holds, with each one's `row_type`, `interval` and `source`.
Discover your indices, read one, page its history, overlay daily on intraday.