What an hour of an H100 costs.

If you arrived because of the futures listing

On 5 October 2026 CME Group and Silicon Data list two contracts on NYMEX — Silicon Data H100 Rental Index Futures and Silicon Data B200 Rental Index Futures, each representing a month of GPU rental, pending regulatory review.

This page is not that index. It does not track Silicon Data's methodology, it settles nothing, and nobody should price a trade off it. It is an independent median of listed prices, published because the question "what does an H100 rent for" deserves an answer somebody outside our building can check. Two honest numbers about the same chip can differ; ours is the one whose inputs you can download.

what the contracts are, in plain terms · the basis: our number minus their settlement, daily from listing day

Daily, per chip

Each day is the median of that day's half-hour bins, UTC midnight to midnight — the same day boundary the sealed tape uses. feeds is the most providers seen in any bin that day: a price from two feeds and a price from eight are not the same claim.

The method, in full

Per 30-minute bin, per chip: take each provider's median listed price, then the median across providers — one provider listing four hundred cards cannot outvote a provider listing one. The day's price is the median of that day's bins.

Form factors are never blended. H100 SXM, PCIe and NVL are different products at different prices, so they are different series. Where a provider states only “H100” with no form factor, it lands in its own series and is kept out of the headline rather than guessed into one of the others.

On-demand is the headline — firm listed prices. Interruptible is published beside it in the CSV and never merged into it.

The rules the code applies, stated so a second implementation cannot diverge (clarified 2026-08-28 and 2026-10-01 at an outside implementer's request):

• Bin. A row belongs to bin floor(snapshot_ts_utc_epoch / 1800) × 1800. A row landing exactly on an 1800-second boundary belongs to the later bin. A bin belongs to the UTC day of its start.
• Per-provider value in a bin. A provider may have several snapshots inside one bin; its value is its latest row in that bin (tape order is ascending by timestamp; the last one wins). Rows with a median price of zero or less are ignored.
• Median. Two medians are used, and they differ on even counts. A provider's own price in a row is, from 2026-09-17 07:50:57Z, the true median of its offer list, published per row in the day's companion file gpu-price-tape-median-true-YYYY-MM-DD.csv.gz (listed with its sha256 in median-true.json); before that it is the tape's median_price_per_gpu_hr_usd, the upper-middle value of the offer list (on an even-length list the higher of the two central values, so it reads high). Every median computed after that (a bin's median across providers, a day's median across bins) is the standard one: the middle value, and for an even count the arithmetic mean of the two central values. No lower-median, no interpolation. The difference and its size are stated in recompute.txt. (corrected 2026-09-24: this line said every median was the standard one, which contradicted the spec; raised by an outside implementer)
• Bin median and low. The bin's median is the median across providers of those per-provider values; the bin's low is the minimum of the providers' listed minimums, ignoring values of zero or less.
• Rounding. Every published price is rounded once per bin and once per day, to four decimal places, by round-half-to-even applied to the binary double (Python's round(x, 4)), not decimal half-up. Example: 2.66665 is stored as 2.6666499999999997 and rounds to 2.6666.
• Day. The day's median is the median of its bins' medians, every bin weighted equally regardless of how many providers it holds — a one-provider bin counts the same as an eight-provider bin. This is deliberate and it is why feeds (providers_max) and bins are printed beside every number: read them before citing a thin day. The day's low is the minimum of its bins' lows.
• Series. Form factors are never blended (H100 SXM, PCIe and NVL are separate; a bare "H100" is its own series and excluded from the headline). Headline class is on_demand; interruptible is published beside it and never merged.
• What the seal does not attest (added 2026-08-28, raised by an outside implementer). The mapping from a provider's raw model string to the tape's gpu_model happens in each feed adapter, upstream of the seal. A recompute from the sealed tape therefore proves the arithmetic on the rows as identified — it cannot show that every row was identified as the right chip. That boundary is the honest limit of what reproduction proves. The adapters are public code (AGPL); a misidentified row is a finding about us and goes on the correction record like any other.

Methodology v1, frozen. Any change is an announced version bump. Recompute any day yourself: curl -sO https://compute.pangle.online/chips/recompute.py && python3 recompute.py YYYY-MM-DD.

Check it yourself

Every number here comes from the same rows that are sealed daily, hashed, and chained. Pull the day file, verify the tape against its sha256, and recompute the median — you never have to take our word for a figure you can rebuild.

The CSV opens with three # comment lines (licence, version, caveat): pandas.read_csv(url, comment="#"), or take chip-index.plain.csv, the same rows with no comments.

raw JSON · CSV, CC BY 4.0 · sealed days · verifier · the chained index answers a different question: is compute getting cheaper.