> ## 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 TypeScript client
description: >-
  What the released TypeScript client gives you: typed request objects, bounded
  responses, per-operation errors, result verification, and a safe way to await a
  terminal job state.
route: /docs/compute/clients/typescript
page_id: docs-compute-clients-typescript
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: TypeScript developers building Compute into their own service
voice: D
reader_question: How do I call Compute from TypeScript without widening a type or a retry?
primary_action: Check your client version against the compatibility matrix
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-clients-typescript-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 install

This page prints no package name. The released package, its version and the runtimes it is tested against move with each release, so they are published on the compatibility matrix instead.

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

Install the client release that matches the contract release you intend to call. A newer client speaks an older release only where the matrix says so.

## Call through the released namespaces

The client mirrors the API namespaces, so the call site tells you which authority it needs.

```text
lithi.work.quote / run / batch / status / result
lithi.data.sources / destinations
lithi.workflows.profiles / rubrics
lithi.identities / api_keys / approvals / spend
lithi.finance.statements / invoices / payments / reconciliation
```

Work submission lives under `lithi.work`. Everything administrative lives elsewhere, and a work key cannot reach it.

## Narrow the type before you read a field

Every response is an envelope. Branch on its typed state before you touch a payload field, and let the compiler prove you did.

```typescript
const status = await lithi.work.status({ job_id });

switch (status.state) {
  case "SUCCEEDED":
  case "PARTIAL":
    return readResult(job_id);
  case "FAILED":
  case "CANCELLED":
    return report(status.next_action);
  default:
    return pollAgain(status.valid_until);
}
```

Never widen the response to `any` to reach a field early. A field you cannot type is a field the state does not carry yet.

## Handle errors by class, not by status code

There is no single global error table. Every operation carries its own generated `error_schema`, so generate error types per operation.

Four refusal classes must stay distinct in your code.

- `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.

Collapsing all four into one retry branch will retry the two that no retry can fix. Each refusal carries a safe reason and a non-empty next action; branch on that.

## Verify the result before you use it

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

Compare the digests in `provenance.json` against the input you submitted. Namespaced columns arrive on tabular output as `lithi_status`, `lithi_result`, `lithi_error_code`, `lithi_confidence`, `lithi_evidence`, `lithi_verification` and `lithi_usage`.

## Await a terminal state safely

Terminal states are `SUCCEEDED`, `PARTIAL`, `FAILED` and `CANCELLED`. Anything else means keep waiting.

Poll on `valid_until` rather than a fixed interval you chose. A read past its `valid_until` is stale, whatever your timer says.

Confirm what your version supports on the [client compatibility matrix](/docs/compute/clients/compatibility), and read [how job status and events behave](/docs/compute/jobs/status-and-events) before you write a polling loop.