> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

# Compute services and limits

## Start with the result

Start with the outcome you need. Use the account's capability summary and matching release material to check the exact operation, accepted input, expected output and limits. A service name alone does not establish what can execute.

For example, choose “extract invoice fields with source-page evidence” or “compare a declared set
of model outputs against a rubric.” Then use the account's capability summary and matching release
material to resolve the exact `capability`, `operation`, input and output. Do not convert a marketing
label into an invented operation identifier.

For example, an `available` capability row tells you that discovery found a matching option for
the account at that moment. It still does not quote a charge, admit a job, or prove that a result
was delivered; resolve the operation and output contract before proceeding.

At the REST boundary, a job names one `capability` and one `operation`.

## Choose an information family and workflow

Lithi's public papers and AI-agent guidance use one small work model:

`Input → Service → Workflow → Execution → Verified output`

- **Input** is the permitted information you want processed. For orientation, think in five broad families: **Text & Data**, **Documents & Images**, **Audio & Video**, **Code & Tests**, and **Models & Evaluation**. These are browsing labels, not format promises.
- **Service** is the exact capability + operation that performs one bounded kind of work. Human-friendly service behavior can be described as **Extract, Analyze, Transform, Generate, Compare,** or **Verify**, but the callable identifier still comes from discovery and the matching release material.
- **Workflow** connects one or more services to reach the requested outcome. Translation, for example, is a service/workflow behavior that can apply to several kinds of input; it is not an input family.
- **Execution** is Lithi's responsibility: planning suitable parallel work, selecting eligible execution, retrying safely, and checking what counts. Customers and AI agents do not choose Macs, cells, queues, physical shard sizes, or retry workers.
- **Verified output** is returned through the selected operation's declared output contract. The result may be text, structured data, vectors, media, reports, analysis of supplied build/test evidence, or another supported artifact only when that contract declares it.

The five MCP work tools are controls over this process, not services: `lithi.quote`, `lithi.run`, `lithi.batch`, `lithi.status` and `lithi.result`. Use discovery instead of relying on a static service list.

Do not describe Lithi as accepting “any format.” The exact accepted representations, limits, output contract, verification requirements, and current availability belong to the selected service release.

The five families and workflow labels help you choose a reading path; they do not promise an operation
or availability. Confirm the exact service operation before preparing a large input.

## Discover the capability

`GET /v1/capabilities` uses account access with `jobs:read`. Its OpenAPI operation ID is `listCapabilities`; the TypeScript method is `listCapabilities(limit, cursor)`.

The response's `data` contains `items`, `catalog_digest`, and an optional `next_cursor`. Each item has:

| Field | Meaning |
| --- | --- |
| `capability` | The identifier used to match the intended work |
| `release_digest` | The release identity reported by discovery |
| `manifest_digest` | The identity of the detailed capability description |
| `availability` | `available`, `constrained`, or `unavailable` |

Use `limit` between 1 and 100 and follow returned cursors unchanged. Discovery is read-only. An `available` row is not a quote, admission or evidence of a completed run.

## Resolve the operation contract

Use the matching capability description supplied with your approved integration. Check `public_operations`, `max_files`, `max_ciphertext_bytes`, `max_input_tokens`, `max_output_tokens`, accepted data profiles, verification requirements, and billing unit.

The summary endpoint does not return a generic workflow `parameters_schema` or a complete output schema. Do not add guessed fields to compensate. If the matching description or output contract is missing, resolve it before quoting or sending data.

The operation name matters independently of the capability name. A `verify` operation checks the declared evidence; it must not be described as generating a transcript, rendered video, or new model merely because the capability label suggests that subject.

Keep request, transfer and execution limits separate:

| Boundary | What to check |
| --- | --- |
| Control JSON | At most 65,536 encoded bytes, including a batch's complete item bodies |
| Chunked artifact transport | At most 10,000 chunks, each no larger than 1,048,576 bytes; total at most 10,485,760,000 bytes |
| Capability input | The selected capability's own file, ciphertext, and token bounds |
| Output | The declared schema and maximum output bound for the priced task |

All applicable constraints must hold. The largest transport allowance is not an execution allowance. Do not truncate required evidence or choose internal shard sizes to force a fit.

## Read token prices with the metering recipe

**Lithi measures text, code, documents and media in tokens.** Each content type has a signed metering profile. One input rate and one output rate apply. Pages, images, minutes and native units are not separate customer prices. Item counts and recorded test or build counts describe workload and evidence, not
billable token quantities. Native build, test, browser-test and release execution are outside customer
Compute.

Review the signed quote's input/output tokens, maximum charge and policy before separate approval.
Admission, execution, result acceptance and delivery remain distinct steps.

## Recover a missing or changed capability

If discovery is unavailable, keep the request diagnostic and do not assume a cached list is current. If a release or manifest digest changed, resolve the new description before reusing earlier parameters.

If no listed operation can return the evidence your task needs, narrow or change the task rather than inventing a callable operation. Use [workflow discovery](/docs/compute/workflows/build) to record a complete choice before quoting.