Methodology
This document describes current practice for every published CCIR rental rate series (series identifiers begin CRI): what the numbers measure, where they come from, and how they are computed. Changes to anything on this page follow How We Publish.
Methodology v2.4.0 · effective 2026-09-17 · document revised 2026-09-16 · All versions
01 What the Series Are
CCIR publishes daily series for GPU rental prices, in U.S. dollars per GPU per hour, on the grain chip × operator segment × form factor × interruptibility × commitment term × region. Every price is a posted, publicly observable list ask collected from a provider-operated pricing surface — not an executed transaction, not a solicited quote, not a broker-mediated or sponsored feed. If a price is only available through sales contact, it is not in the data.
01a Design Rationale
The series measure publicly posted list asks. They do not sample executed transactions, and they do not estimate traded volume. Posted asks are observable without solicitation and reproducible by any third party on the day of observation. They carry no submission channel, so there is nothing to misreport: no transaction sample to select from, no broker mark, no expert judgment.
The series are market data: a documented, reproducible measure of posted rental prices for monitoring, research and analysis. Section 04a explains how to read each row's status. They are not designed to replicate a volume-weighted average of executed trades. Products that measure executed levels sit outside this methodology.
02 Operator Segments
Series are segmented by the class of operator posting the price, not by hardware grade:
- Hyperscaler — integrated cloud majors (list rate cards).
- Neocloud — GPU-specialist clouds selling dedicated capacity.
- Marketplace — multi-seller venues and aggregated marketplaces. Every marketplace enters on the same terms; capacity a venue resells from another panel member is excluded.
In series identifiers these carry the tokens T1 / T2 / T3 respectively.
03 Collection
Prices are collected automatically from each provider's public pricing pages or application programming interfaces (APIs). Each observation records the provider, chip, posted price, and its axes (form factor, interruptibility, commitment term, region). Raw observations are archived; published series are aggregates.
Capture runs on a per-source schedule, from once a day to hourly, set by how often a surface can be read without burdening it. Every series is a daily series: each cell publishes one value per day from every reading collected on that day, midnight to midnight Central time, and a source's readings within the day reduce to a single per-source value before the headline is computed. Capture frequency is an operational parameter rather than part of a series definition, so a change to it is not a series break.
What counts as one listing. Distinct products a provider posts on one chip and term are distinct listings: a different fabric, machine family, or deployment model is a different product. The sizes of one product are one listing, priced per GPU at the eight-GPU node where the provider posts one, else at its largest posted node. Marketplace offers are recorded one per offer.
04 Aggregation and the Headline Statistic
Aggregation is operator-equal: one source, one vote. A provider's multiple qualifying listings in a cell are reduced to a per-source value first, the median across the locations it posts within that cell, so neither a provider's listing count nor the number of locations it serves moves a series.
The headline statistic per cell is the operator-equal median at every panel depth. The statistic is stamped on every row (headline_stat), the listing mean publishes beside it for readers who want it, and every cell publishes its source count n, observation count, and interquartile range alongside the headline value.
Publication threshold. A cell publishes when at least three independent sources contribute to it and it holds at least five observations. Cells below that threshold are computed and retained, and they do not publish. Two breakout classes publish at two sources rather than being withheld: regional cuts and committed-term cuts, where a thin panel is the true state of an emerging market. Those cells carry promotion_status of Provisional; cells clearing the full threshold carry Published.
Panel depth n is the trust signal. It publishes beside every headline value with the observation count and the interquartile range, and thin cells should be read as indicative. Because the threshold is a floor on depth rather than a view on price, it never selects among cells that clear it.
Under rapid dislocation (the sudden exit of major sources, widespread collection failure, or extreme dispersion) CCIR may widen the observation window or publish a notice of reduced coverage. Both steps are pre-specified contingencies: each is logged, applies forward only, and changes neither the series identifier nor the definition of the rate.
04a How to Read a Row's Status
Every row carries two status fields. promotion_status reports whether a cell cleared the full threshold in section 04. product_class reports which panel the cell rests on.
citable marks the on-demand series on the full panel. The field name predates the current framing and is kept so existing files stay stable. market_intelligence marks the committed-term series, together with the on-demand companion published beside them for like-for-like comparison. Those cells rest on a different and generally thinner panel, so read them as context. The strongest on-demand rows read product_class = citable and promotion_status = Published. Many published rows do not meet both conditions, so check the two fields rather than the series identifier.
The published file carries the operator-segment series set out in section 06. An earlier factory-class taxonomy is still computed and surfaces in the /explorer long tail. Those series are not part of the main set and are not included in the download.
05 Windows and Composition Stability
Each cell is computed on the shortest observation window that meets the publication threshold in section 04: one day, else three days, else seven. A cell whose single day of data falls short of the threshold widens its window rather than publish thin. The window actually used is stamped on every row (headline_window_days), with the source and observation counts at each horizon. Panel membership is versioned; when a hyperscaler or neocloud panel member transiently fails collection, its last-good price carries forward for at most three days so one missed scrape does not change a series' composition; marketplace absences take effect the same day. Members absent beyond that exit the cell.
06 Series Grammar
Every Compute Rental Index (CRI) series identifier is fully self-describing:
CRI-{SEGMENT}-{CHIP}-{FORM}-{INT}-{TERM}-{REGION}
SEGMENT T1 Hyperscaler · T2 Neocloud · T3 Marketplace
FORM SXM · PCIe · NVL · OAM · ALL (pooled)
INT GTD guaranteed · INT interruptible · ALL (pooled)
TERM OD on-demand · 1mo 3mo 6mo 1yr 2yr 3yr committed
REGION US · EU · APAC · Other · ALL (pooled)
Example: CRI-T2-H100-ALL-GTD-OD-US
Neocloud · H100 · guaranteed on-demand · United States
ALL on any axis means that axis is pooled for that series. A listing prices the region of its posted location, whichever provider posts it; a hyperscaler's European capacity prices Europe. Other on the region axis collects posted locations outside the three named regions; it is a residual, and it is never a substitute for a named region. A listing with no posted location falls back to its provider's home region. OAM is the Open Accelerator Module form factor. The rate ladder on /rates shows the guaranteed on-demand US cut per chip and segment, with each cell's series identifier printed beneath the rate.
07 Publication, History, Restatement
Series publish daily by 07:30 Eastern Time (ET) at ccir.io. Each print reports the prior complete day in Central time and is dated that day. History is append-only with a methodology version stamped on every row. A value is final when it publishes. After that, no value changes silently. When a defect or a material methodology change requires it, history is restated and republished in full under the current version, per the How We Publish. The record from 2026-04-24 was republished in full under v2.4.0; see the change log.