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
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.
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.
--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:
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 a202 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:
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
runningbecause the volume is provisioned first.