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

# Review the Compute Kit before use

**Start with a task you can judge.** Review a small, authorized sample of completed work, name the
result you need and decide whether to continue with your agent, wait for an allowance reset or
consider Lithi. This assessment is read-only. It may end with no suitable use case.

Your agent keeps context, planning, decisions, local edits and verification. The Kit helps prepare
a supported request and connect a client; Lithi handles the admitted operation only after a quote,
transfer permission and separate execution approval.

Think of the Kit as a harness around your existing agent. It supports permitted preparation, an
approved account and interface, quote review, approved submission and result handling. Your agent
keeps its own model, task context and final decision. Participating Macs on the Lithi Agent Network
process admitted work; a compatible agent still needs a supported MCP or API transport.

For example, a useful brief might ask your agent to classify 40 permitted support tickets, keep each
ticket ID, return one of three labels or an abstention, and show the evidence needed for your review.
That gives the Kit a bounded task and gives your agent a clear acceptance rule.

## Start with one representative task

Use conversation context, accessible history or project files within the scope you were given. Say
what you reviewed and what was unavailable. Do not claim hidden history or repeat private records.
Memory describes past work; it does not prove current price, quota, allowance or reset.

Record the facts that change the decision:

| Evidence | Record |
| --- | --- |
| Quantity and frequency | Items or files and the observed cadence, or a labeled assumption |
| Attempts | Retries, duplicate review or repeated processing |
| Token evidence | Measured input/output counts, or labeled assumptions |
| Checks | Required schema, coverage, verification and human review |
| Boundaries | Minimum fields, retained local data, permitted destination and sensitive-data decision |

For each candidate, state the smallest useful input, expected result, checks and local remainder. Use
up to five evidence-backed opportunities when the sample supports them; fewer or zero is correct.
For code, include the permitted diff, callers and types, relevant schema or interface, existing test
evidence and review rubric. A code finding does not run tests or edit a repository.

## Define the task and its boundary

Use [Choose work](/docs/compute/choose-work) to find the guide for your task. Write the permitted
input, expected result, and checks for each candidate. The selected service contract supplies its
accepted formats, operation, limits, and output.

The local preparation decision is `blocked`, `review_required` or `eligible`. A blocked run withholds
the original input and never sends a silent fallback. Pseudonymization can reduce identifying
information, but the protected reverse map stays in the customer environment and outside the
agent's reasoning context. The assigned Mac reads its prepared input, which a privileged
host operator may be able to inspect. If policy forbids that processing, report no fit.

For a bounded classification task, the decision path is:

```text title="Define the task and its boundary" kind="text"
Review a sample of your work
             ↓
Define the input and checks
             ↓
Compare data, cost, and timing
             ↓
Continue, wait, or keep your work
```

## Compare timing, allowance and cost

Identify the billing pool the task would consume. An included subscription allowance is a usage pool;
a metered API and purchased or prepaid credits are direct-cost pools. A hybrid account may contain
more than one pool. If the pool or billing shape is unknown, keep the current path or wait for a
usable reading.

| Decision | Compare |
| --- | --- |
| Usage fit | The measured frontier-agent allowance the task would consume, the reset window and the planning and review that remain |
| Cost fit | Current charges and the signed Lithi quote for the same task, volume, output, quality, timing, data handling and verification |
| Throughput | Required timing against admitted capacity; placement, Mac choice, shard size and retry topology remain service decisions |

Preserving allowance and saving cash are different outcomes. Work inside an included subscription
has zero marginal cash cost while its fixed fee remains due. Moving it may preserve room for later
interactive work, but that is not a cash-savings claim. Informational rates are USD 0.05 per million
input tokens and USD 0.10 per million output tokens; they are planning information, not a quote.

## Inspect the public contract after the decision path

The optional public assessment object is at
`https://lithi.ai/api/public/compute/assessment`. Use `assessment.kit_review` only when `mode` is
`documentation_only` and `review_mode` is `read_only`. It identifies the admitted overview,
contents, review, agent guide and interface reference with a human `url`, a Markdown `markdown_url`
and a `source_version` for each.

Use the JSON as structured page, rate or protocol information and as a pointer to the current public
pages. It is not a tool and does not expose a Kit release, keys or execution access. If the endpoint
is unavailable or omits `kit_review`, use [Kit contents](/docs/compute/kit/contents), [the agent
guide](/docs/compute/kit/agent-guide) and [the interface reference](/docs/compute/kit/reference)
already available to you. Do not fetch raw Kit source, release archives or signatures, install the
Kit or run examples for a public review.

## Choose the next action

Continue with [Compute access](/docs/compute/access) only when the workload is bounded, the data
policy fits, the result checks answer your quality needs and the user has reviewed the exact next
step. Otherwise keep the current workflow, wait for a reset or record no fit. A quote prices a scope;
it does not authorize transfer or paid execution. After an approved run, your agent reads status and
result, checks integrity, coverage and task quality, and continues its work. With `reporting:read`
permission, it can interpret an authorized monthly report through the reporting API or an approved
report file; reporting is separate from the five Work tools.