> ## 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: Use the Go client
description: >-
  How the released Go client is shaped: contexts and deadlines, typed errors, and safe
  result streaming. Generated code alone is never evidence that a client is supported.
route: /docs/compute/clients/go
page_id: docs-compute-clients-go
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Go developers building Compute into a service
voice: D
reader_question: How do I call Compute from Go with correct deadlines and typed errors?
primary_action: Check your client version against the compatibility matrix
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-clients-go-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"
---

## Before you add the module

This page prints no module path. The released module, its version and the Go versions it is tested against are published on the compatibility matrix, because they move with each release.

Your base URL and current API version appear in the portal under developer settings, and in the API description you download.

Pin an exact released version. Do not track a branch, and do not vendor a generated client and call it the released one.

## Two deadlines, and they are not the same

A context deadline bounds your own call. The `deadline` inside `limits` bounds the job itself, as an ISO 8601 duration.

```go
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()

status, err := client.Work.Status(ctx, jobID)
```

A canceled context ends your read. It does not cancel the job, and the work keeps running.

Call the cancel operation when you mean to stop the work. The job then moves to `CANCELLING` and settles at `CANCELLED`.

## Decode errors by class

There is no single global error table. Every operation carries its own generated `error_schema`, so decode per operation and take the exact type names from your release.

```go
if err != nil {
    var refusal *lithi.RefusalError
    if errors.As(err, &refusal) {
        // refusal.Class is one of the four classes below.
        // refusal.NextAction is never empty.
        return handle(refusal)
    }
    return err
}
```

Keep these four apart:

- `EDGE_ABUSE_LIMITED` — the perimeter is shedding load.
- `CANONICAL_ADMISSION_LIMITED` — the key or account is not authorized for that request.
- `CANONICAL_BUDGET_EXHAUSTED` — spend or reservation authority is exhausted.
- `CELL_CAPACITY_UNAVAILABLE` — current capacity is unavailable.

One shared retry branch will retry the two that describe authority, and no retry fixes those.

## Stream a result without trusting a partial read

Read `result-manifest.json` before anything else. It is written last, and it is the only complete-bundle marker.

Close every reader you open, including on the error path. A short read on a part file is not a result; it is an interrupted download.

Then read all four directories, not just the accepted rows. `data/`, `failures/`, `abstentions/` and `disagreements/` each carry part of the answer, and `provenance.json` carries the digests you check them against.

## Generated code is not a support claim

An OpenAPI generator will emit a Go client from the description you download. That output is yours, and it proves only that a generator ran.

Support is stated on the compatibility matrix, one row per client version against one protocol version, with tested features and known gaps named. Anything outside a listed row is your own code, and its behavior is your own to verify.

Read your row on the [client compatibility matrix](/docs/compute/clients/compatibility), and see [the released work API reference](/docs/compute/reference/work-api) for per-operation schemas.