> ## 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: Client compatibility matrix
description: >-
  The matrix that decides what your client version can do: protocol version, tested
  features, known gaps and retirement dates. An unsupported version is stated, never
  implied.
route: /docs/compute/clients/compatibility
page_id: docs-compute-clients-compatibility
page_type: reference
content_layer: technical reference
surface_profile: technical_reference
audience: Developers pinning a client version or planning an upgrade
voice: D
reader_question: What can my exact client version do, and when does it stop being supported?
primary_action: Pin a listed client version before you build
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-clients-compatibility-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 each row states

One row describes one client version against one protocol version. It never describes a range, and it never describes a language in general.

| Column | What it tells you |
| --- | --- |
| Client | The released language client or command line, and its package |
| Client version | The exact released version this row describes |
| Protocol version | The contract release that version speaks |
| Tested features | The features exercised by that release's conformance suite |
| Known gaps | Features that version does not implement, or did not exercise |
| Support state | Supported, deprecated with a date, or unsupported |
| Retirement date | The date this row stops being supported |

The matrix is regenerated with each release. Read it rather than a version number in an example, including the examples in these pages.

## How to read a version row

Match your installed version exactly. A neighboring version's row is a different row and carries different claims.

Then match the protocol version against the contract release you intend to call. A newer client speaks an older release only where a row says so.

A feature absent from the tested list is untested for that version, not quietly available. It may work; it carries no claim, and it is yours to verify.

## What "tested" means per feature

Each tested-feature entry is a claim about what was exercised, not about what exists in the code.

| Feature area | What a pass means |
| --- | --- |
| Work submission | `quote`, `run` and `batch` were exercised end to end |
| Status polling | Every terminal state was read correctly |
| Cancellation | Cancel was requested and the terminal state observed |
| Result streaming | Part files streamed, with the manifest read last |
| Result verification | Provenance digests and the receipt were read back |
| Typed errors | Per-operation error schemas decoded, with the four refusal classes kept distinct |

## Known gaps

A gap is a stated absence, written down in the row. It is never silent, and a blank cell is not a gap.

A gap is not a defect report. It tells you which part of the flow you must handle yourself, or which client version to move to instead.

## Retirement dates

Each supported row carries a retirement date. After that date the row is unsupported, whether or not the client keeps returning responses.

Plan the upgrade against the date on your own row. Two clients in one system can carry two different dates.

## Unsupported client versions

Unsupported is stated in the matrix. It is never implied by absence, and you never have to infer it from a missing row.

An unsupported version carries no tested feature claims and no gap list you can rely on. Nor does it carry any commitment that the contract release it speaks is still accepted. It may still return responses; that is not evidence it handles refusals, cancellation or partial completion correctly.

There are two ways forward. Upgrade to a listed version, or build directly against REST at the current contract release.

## Adapter compatibility levels

These are separate from the client matrix. They describe how closely Compute matches someone else's API, and there are exactly four named levels.

- `import_compatible`
- `wire_subset_compatible`
- `official_sdk_compatible`
- `full_endpoint_compatible`

Each level is backed by its own versioned conformance matrix, stating the supported upstream version and the field, lifecycle, error and limit coverage behind the claim. A compatibility claim without that matrix is not a claim Lithi makes.

Read [what each adapter compatibility level covers](/docs/compute/integrations/compatibility-levels), and [how contract releases are versioned](/docs/compute/reference/versioning) before you pin a client.