Skip to main content
Every infrastructure mutation returns 202 Accepted with an operation ID and resource ID. The mutation has been durably accepted; the resource is not necessarily ready yet. Acceptance is a promise, not a receipt. A create has exactly three outcomes: Before accepting, AI Reserve checks what it can know up front: your wallet, your Compute limits, placement, and its own standing with the infrastructure provider. A request the provider is certain to refuse for a reason that is AI Reserve’s — not yours — is answered 503 provider_unavailable with details.actor: "platform" and a details.reference to quote to support, instead of a 202 that could only fail. Nothing of yours needs to change; retry later with the same Idempotency-Key.

Wait for completion

Terminal statuses are succeeded, failed, and cancelled. Save the operation ID when your process may restart. Intermediate reconciliation details are not a stable API contract; key automation off operation status and the final resource. A terminal failed or cancelled operation carries failure, a structured reading of errorMessage so you never parse provider_rejected:<code> by hand:
Nothing is billed for a failed create in any of the three cases.

Retry safely with idempotency

The CLI derives an idempotency key for instance launch and creates keys for other mutations. For direct REST calls, send your own unique key:
  • Reusing a key with the same accepted request returns the original receipt.
  • Reusing it with a different request fails with operation_conflict.
  • Two intentional launches require two different keys.
  • Inline persistent storage and the instance are recorded under one key, so a transport retry cannot create an extra volume.
Keep the same key across network retries. Do not derive a new key after an ambiguous timeout.

Quote semantics

POST /v1/gpu/instances/quote creates and charges nothing. It records the configuration and price selected at that moment and expires after 120 seconds. A quote is not a capacity reservation. At launch, AI Reserve rechecks the price and current resource state:
  • price_changed: request a fresh quote;
  • quote_expired: request a fresh quote;
  • volume_in_use: wait for the current attachment to terminate;
  • provider capacity may still disappear before provisioning completes.
Launching from a refreshed quote is a new CLI intent unless you explicitly reuse the original --idempotency-key for the same ambiguous launch attempt.

Common errors

no_capacity reasons

A 409 no_capacity response does not name a provider or data center. It carries customer-actionable details:
The CLI prints the reason, the cheapest eligible rate when known, and a suggested next command. The current standalone SDKs expose generic API errors and do not retain structured capacity details; inspect the REST error envelope when you need the full refusal payload.

Clusters: refusals after acceptance

A cluster quote reports stock for one node of the requested shape. Whether every node can be placed together on one interconnect is known only when the provider creates the cluster, so a 202 Accepted launch can still end with the operation failed and errorMessage provider_rejected:no_capacity. Nothing is billed; request a fresh quote. Cluster operations are cluster_create and cluster_terminate; there is no stop.

Understand the price ceiling

For a direct launch, maxHourlyPrice bounds the new running commitment:
An existing volume is already billing independently. Its rate appears in the quote but does not count against the new-compute ceiling.

Billing timeline

  • Compute accrues from confirmed readiness through confirmed stop or termination; final partial intervals are prorated.
  • A stopped instance does not accrue GPU compute.
  • A persistent volume accrues from volume creation until successful deletion.
  • Inline storage can begin billing before its instance reaches running because the volume is provisioned first.
Review charge history with: