> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: What is available right now description: >- Every availability answer is a dated record, not a promise. This page explains the fields Compute returns, how long each one stays valid, and what to do when something you need is unavailable. route: /docs/compute/availability page_id: docs-compute-availability page_type: reference content_layer: technical reference surface_profile: technical_reference audience: Integrators and AI agents deciding whether an operation can be called today voice: D reader_question: Which operations and clients can I use right now? primary_action: Re-read the availability record before you submit source_locale: en-US source_status: APPROVED source_version: docs-compute-availability-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## What an availability answer contains Every answer arrives inside one response envelope. These fields decide whether you can act on it. | Field | What it tells you | | --- | --- | | `request_id` | The reference to quote if you contact support. | | Operation | The exact operation the answer is about, and nothing else. | | Contract release | The contract version the answer was produced against. | | Typed state | The machine-readable state, not a message string. | | Evidence class | What kind of evidence stands behind the answer. | | `observed_at` | When the answer was established. | | `valid_until` | The moment it stops being current. | | `next_action` | The structured step to take next. | ## How long an answer stays current An answer is current between `observed_at` and `valid_until`. Past `valid_until` it is history. Read it again rather than trusting a cached copy. Read `observed_at` as well. Two answers carrying the same state can be minutes or days apart, and only one of them describes now. An answer covers one operation. It says nothing about a second operation, a different workflow, or a different client. ## Operation availability Availability is declared per operation. Ask about the operation you intend to call, not about the product. A registered capability is not a purchasable service. You choose a workflow, and the workflow descriptor states the operations it exposes and the maximum item count it accepts. Your quote repeats that maximum, so read it there rather than coding to a number from an example. ## Client availability Each released client has its own page. That page lists the exact package name and version. Never assume one from another language's client. Your base URL and current API version appear in the portal under developer settings, and in the OpenAPI description you download. Do not hard-code either from a sample request. A client that speaks another vendor's shape states a named [compatibility level](/docs/compute/integrations/compatibility-levels), backed by a published conformance matrix. Treat an unqualified compatibility claim as unproven. ## When something is unavailable Four typed refusals are commonly mistaken for one another. They are separate states with separate next actions, and no retry policy should collapse them into a single rate-limit wait. | Typed refusal | What it means | What to do | | --- | --- | --- | | `EDGE_ABUSE_LIMITED` | Your request was shed under load before it reached admission. | Retry the unchanged request later, with backoff. | | `CANONICAL_ADMISSION_LIMITED` | The request authority on your key or account is exhausted. | Check the key's scopes and limits, or submit under an identity that holds them. | | `CANONICAL_BUDGET_EXHAUSTED` | The spend or reservation authority for this work is exhausted. | Get spend approved or raised, then submit again. | | `CELL_CAPACITY_UNAVAILABLE` | Capacity for this work is not available at the moment. | Retry, or widen the `deadline` in `limits` and quote again. | Waiting clears the first and the last. Waiting never clears the middle two. A client that retries all four the same way will sit through a refusal that only a decision can lift. ## The statuses behind every answer Compute never returns an empty outcome. Every operation resolves to one of these, and every non-success carries a safe reason and a non-empty next action. `SUCCEEDED` · `SAFE_FAILED` · `BLOCKED` · `REPLAN_REQUIRED` · `CANCELLED` · `EXPIRED` · `SKIPPED` `REPLAN_REQUIRED` is the one to handle explicitly. It means the facts moved between your quote and admission. Quote again rather than resubmitting the same request. There is no single global error table. Each operation publishes its own error schema alongside the statuses above, so read the schema for the operation you call. [What each error means](/docs/compute/errors) covers the ones you are most likely to hit. ## Refreshing what you know Re-read availability at three moments: before you plan a workload, when a `valid_until` has passed, and after any refusal above. The record is the answer. Nothing here should be read as a commitment that an unavailable operation will open, and no page in this library announces one in advance.