GPU Markets is an index of the listed GPU rental rate on public venue APIs. Each daily fix is a median of the rates venues are publicly advertising at 00:30 UTC. That is what a buyer sees when they price capacity on the open marketplace.

The fix does not measure negotiated contract rates, private enterprise agreements, auction clears, or any transacted price not visible on a public API. Those belong to the transacted surface of the market; survey‑based indices — most notably SemiAnalysis's H100 1‑year contract series — and terminal‑gated transaction indices — most notably Ornn's Compute Price Index on the Bloomberg Terminal — capture that side. The two surfaces can and do diverge.

Every claim in the research notes, the fixings table, and the news section is a claim about listed advertised rates. Readers cross‑referencing against contract‑side data should expect numerical differences and should not interpret them as error in either surface.

The full methodology document is published as part of Phase 2 and will live at this URL. In the interim, the canonical reference is the methodology/ directory of the project repository, which contains the trimmed‑mean specification, the MAD‑based outlier rule, the eligibility taxonomy, and the change log of every estimator revision since the first fix.

A short summary lives on the landing page under § 04 · Methodology.

The nominal strike time is 00:30 UTC, every day — weekends included. The GPU rental market is a 24/7 venue environment: venue APIs do not observe bank holidays, and neither does the fix. A Saturday fix and a Tuesday fix are produced by the same collector, on the same cadence, from the same venue set. Treating weekends as trading days is a deliberate break from equity‑style conventions (Fed H.15, LSE closing prices) and a match to the FX and crypto conventions that share the 24/7 property.

Venue‑side holidays — e.g. a hyperscaler's maintenance window, a regional AWS outage, or a collector‑side deploy — are handled as per‑venue events, not as per‑fix events. The estimator operates on whichever eligible venues returned observations in the 10‑minute window preceding the strike. Minimum‑coverage guards kick in when too few venues respond: the headline fix is suppressed (rather than silently published from a thin panel) when fewer than three eligible venues contribute surviving observations after outlier rejection. The suppressed day's row carries the reason in place of a price; the previous day's fix is not substituted as a fallback.

Individual series may occasionally strike off‑schedule when an API outage delays a key venue past 00:30 UTC. An off‑strike row is marked with ◦ next to its ticker, carries its actual strike time in the per‑series metadata, and is footnoted with the specific cause. Deltas on an off‑strike row compare to the previous day's on‑strike fix for the same series — not to the same‑day 00:30 UTC fix, which does not exist for that series.

Every published fix is provisional for 24 hours. During that window the estimator may re‑run if a venue backfills late observations, if a collector bug is found and patched, or if an outlier rejection is reviewed and reversed. After 24 hours the fix is locked and becomes part of the final vintage. Final‑vintage fixes are not silently edited. If a material correction is warranted — e.g. a collector was double‑counting a venue for a week — the correction is published as a named revision event, committed to the data repo with its own commit message, linked from the methodology changelog, and reflected in the site's news feed.

Provisional fixes carry a vintage: provisional field in the raw‑observation JSON and in the flat CSV. Final fixes carry vintage: final. A third value, vintage: revised, applies to any fix corrected after lock — revised rows carry both the revised price and a reference to the original provisional price under price_original, so readers can reconstruct either surface.

The distinction matters for any downstream analysis that cites a specific fix date. A research note citing "H100 SXM spot on 2026‑04‑18" should specify which vintage — provisional, final, or revised — the claim rests on, and link to the commit hash of the data repo at citation time. The suggested citation block includes the retrieval timestamp for exactly this reason.

Phase 2 will add a vintage cursor to each per‑series page — readers will be able to replay "what did the 2026‑04‑18 fix say as of 2026‑04‑19" independently of what the same fix reads today. Until that ships, the data repo's git log is the authoritative record of vintage transitions.

Alongside the headline fix, each training-tier series publishes a capacity-weighted companion — .cw — as a research series. The companion is a weighted median of the same surviving observations, with weights assigned by venue capacity tier: 3 for T1 venues (over 10,000 GPUs), 2 for T2 (1,000–10,000), 1 for T3 (under 1,000). Tier assignments are coarse by design — disagreement over whether a venue operates 8,000 or 12,000 GPUs does not change a tier, so weights do not depend on privately estimated capacities. The current assignment, with a per-venue citation, is published as data/venue-capacity.json in the project repository. Tiers are reviewed quarterly and reassignments are logged alongside MAD threshold changes in the methodology changelog.

The .cw fix is suppressed when fewer than two venues survive outlier rejection or when surviving venues span fewer than two capacity tiers. On suppressed days the row carries a reason in place of a price; the headline fix is not substituted as a fallback.

The headline fix remains the equal-weight median. The .cw series is a research publication, not a member of the fix family — its purpose is to offer an auditable supply-weighted reference without introducing weighting into the headline benchmark.