Manual for agents, automated clients, and developers using Cloud GPU Prices.

Agent and data access manual

What this catalog can answer

The accepted catalog is designed to answer which providers and GPU products are available, how their published prices are structured, which complete prices are comparable, how recently evidence was verified, and what official evidence exists for EU/EEA compute claims.

It does not currently establish which service is fastest. Price, hardware labels, and provider claims are not substitutes for workload-specific benchmark measurements.

Interpretation rules

1. Only variants with comparison.total_price_eligible=true are complete prices that may be ranked as totals. Additive CPU, memory, and GPU meters remain separate components.
2. Geography uses four truth states: yes, no, unknown, and conflicting. Unknown means that accepted evidence does not establish the answer; it never means no.
3. A variant's region object is present only when its accepted exact region_code has reviewed provider-to-country metadata. A null object means unmapped or too broad, not outside the EU/EEA. An exact EEA mapping can establish positive compute availability, but it does not establish constrained placement or an EU-only data path.
4. Compare monetary totals only within one currency. The API requires exactly one currency when sorting by comparable hourly price.
5. A provider-selected pool lists possible hardware but does not guarantee a specific GPU for a request. Do not present it as a fixed-GPU offer.
6. Prefer effective_amount_picos for the applicable commercial variant and retain the published amount, unit, quantity, source URL, warnings, and verification timestamp when citing it.

Representations

Human and browser-agent HTML

/pricing accepts the same filters and renders ordinary links, forms, tables, and evidence.

Exact JSON

/api/v1/offerings is the authoritative machine representation. Integer quantities and pico-unit monetary values are decimal strings. Reviewed exact regions include country, EU/EEA membership, evidence, and review dates. Reviewed products include an exact governance_profile reference; null means unreviewed, not unsupported.

Context-efficient Markdown

/pricing.md gives a readable result table plus evidence notes. Use JSON when exact structure matters.

Contract

/api/v1/openapi.json describes the query parameters and response schema.

Querying

Filters use normal URL query parameters. Repeat provider, gpu, region, category, hardware_selection, pricing_structure, purchase_option, freshness, or currency to match any of several values. Unknown parameters, unsupported values, and unsafe comparison requests return HTTP 400; nothing is silently ignored.

Common filters:

• provider, gpu, region, category
• hardware_selection, min_gpu_memory_gb, pricing_structure, purchase_option, total_price
• eu_compute, eu_constrained, eu_only
• freshness, currency, q
• sort, order, limit, cursor

Examples

• H100 complete USD prices, cheapest first
• Fixed GPUs with at least 16 GB VRAM per device, cheapest first
• Serverless GPU products with accepted EU availability and constraint evidence
• Verda GPU VM spot prices
• Offerings from either Modal or Runpod

Pagination and caching

Results are paginated by offering, with commercial variants nested beneath each offering. Follow links.next or reuse pagination.next_cursor without changing the other query parameters. Cursors are deliberately bound to the normalized query. JSON responses expose ETag and Last-Modified headers for conditional requests.

Evidence, citations, and change

Cite the catalog result together with the offering's source_url and provenance.verified_at. New providers and offerings can appear without changing the endpoint. Fields may be added compatibly within API v1; consumers should ignore fields they do not understand. Breaking changes will use a new versioned API path.

Additional product categories and model-as-a-service pricing may be added later. Their commercial units and comparison rules will remain explicit rather than being forced into GPU-hour semantics.

Benchmark measurements

The accepted benchmark v2 catalog is exposed separately from provider pricing. It may be unavailable until the first supervised campaign has been reviewed and published. Use the benchmark JSON API for exact data, benchmark Markdown for a compact representation, or the benchmark explorer for the human-readable page.

• Compare only identical workload definition versions, scenarios, measurement origins, and observed startup modes.
• Cold state is observed from container-session evidence; latency alone is not a cold-start label.
• Matching accepted samples accumulate across campaigns through the current publication pointer. Sample count and failure rate are part of every result; a median is not a percentile claim.
• Client total is invocation-to-validated-result time measured by the Cloudflare runner. Current async profiles poll once per second; older campaigns may use an earlier profile.
• Provider and workload phases are explanatory and can overlap; do not add them together.
• Observed GPU identity remains distinct from requested GPU identity.
• A null benchmark cost means unknown, never free. Estimated and actual costs are labelled.
• Use scenario=scale_from_zero for practical zero-minimum-capacity targets and class=primary for the current ordinary provider configuration. Target optimization, quiescence, and observed startup modes are returned in each result.

Filters are repeatable provider, workload, scenario, origin, gpu, and currency. Sort with provider, total_ms, real_time_factor, cost, failure_rate, or freshness plus order=asc|desc.

Data-governance profiles

/api/v1/governance exposes slowly changing, product-scoped facts reviewed from provider policies, contracts, security documentation, and subprocessor disclosures. It is separate from the frequently refreshed pricing and GPU-region catalog.

• These records are factual evidence summaries, not legal advice or compliance certifications.
• An EU compute region does not establish that requests, storage, logs, support, or subprocessors remain in the EU.
• Missing claim subjects are emitted as unknown, never inferred as unsupported.
• For data-path subjects, supported, conditional, and unsupported describe the documented EU/EEA localization control—not whether storage or processing exists.
• Every reviewed claim retains its conditions, exact geographic scope, source section, direct URL, and review date.
• Pricing offerings link to profiles only by exact provider and product slug. Provider-wide policy assumptions are not copied across products.
• Filter with repeatable provider, product, and review_state=current|review_due.

Operational profiles

/api/v1/operational-profiles exposes hand-reviewed, product-scoped deployment, scale-to-zero, billing, startup, setup, and constraint summaries. Exact prices, billing increments, minimum billable time, and billable states remain in the pricing catalog rather than being copied into the curated records.

• Documented startup behavior is not an observed performance benchmark.
• Setup complexity is an editorial aid backed by a published low/moderate/high rubric and concrete requirements.
• Profiles are scoped to exact provider and product slugs; behavior is not generalized across a provider's unrelated services.
• Filter with repeatable provider, product, setup=low|moderate|high, and review_state=current|review_due.