Use Compute with your AI

Use the AI agent you already work with to recognize suitable tasks and recommend using Lithi. Start with Compute availability and access approval when you need to decide whether the task and account fit. Your agent keeps its model, goal, project context and final decisions. After you connect an approved account, it can prepare supported requests, obtain quotes, and run work within the exact person or bounded-policy permission you have set. It asks before an action would exceed those limits. A skill gives guidance; it does not grant access. The paper's agent reference describes the same separation between the Work interface and permission.

1. Check whether the task fits

Start with Usage fit and Choose work. Give the agent only the sources and context you authorize. It can identify a suitable outcome, required checks, and a small test before any credential setup, lithi.run, lithi.batch, or paid work.

An assessment is a decision aid, not an access grant. Keep unsupported capability, price, or data rules visible instead of filling gaps from memory.

Your AI provider may charge for the agent's reasoning during review and setup. Those charges are separate from Lithi Compute. An assessment can be free of Lithi charges while the agent's provider still bills its own reasoning. The assessment makes no Compute call; confirming an MCP session is a remote account check when that connection is available.

The place where your agent runs matters. A cloud-hosted agent's workspace is not automatically the customer's physical computer, even when the agent is helping with files that originated there. Keep local preparation and reverse-identity maps in the environment you explicitly control, and confirm that boundary before allowing a transfer.

2. Connect your approved account

Host overview

For a host-specific walkthrough, choose Claude Code, Codex or Cursor. Each guide walks through assessing work, connecting the intended approved account, checking the five Work tools and reviewing one small approved, funded test.

The portable integration has two parts: an Agent Skill gives your host task guidance, and MCP over Streamable HTTP exposes the five customer work tools after your account is configured. The host still owns its own instructions, settings, credentials and approval UI. Read the vendor's current documentation before changing a file; the paths below are the registered project locations for the three local hosts in the compatibility table.

Any agent in this guide means a compatible host using a supported MCP or API transport with approved access. Support for remote MCP in another host does not by itself certify a Lithi connection or give that host the same local Kit modules.

These project paths are locations, not permission. The assessment can review the relevant Markdown, source and public documentation without writing them. After access is approved, follow the host's supported setup path and keep the key in its protected environment reference. A cloud-hosted agent is a different surface: its workspace, skill store, MCP settings and usage pool belong to that provider. Do not assume a local path exists in its cloud workspace or that local preparation and its reverse map are on the same machine.

An MCP-capable agent needs a Compute work credential and the customer MCP endpoint for your account after approved setup. It doesn't need provider enrollment, a Mac fleet configuration, finance authority, or a shell on someone else's computer.

Use your agent's own current MCP configuration UI or documentation to add the server after approval. This page records the registered project locations above; it does not install a key or write a vendor-specific credential during assessment.

When the assessment supports continuing, apply for Compute API access. We review your request and explain the next steps.

Already approved? Open Agent setup in your Compute account for client guides, authorization status and metadata-test guidance. Follow your client's guide to configure the connection.

3. Verify the account and work tools

After the client setup is authorized, verify three facts:

1. The session resolved the intended Compute account.
2. The negotiated protocol is accepted by the server described for your account.
3. tools/list contains exactly lithi.quote, lithi.run, lithi.batch, lithi.status, and lithi.result.

A sixth work tool is not part of the Lithi customer work surface. Provider tools, management methods, CLI commands, and local agent helpers do not belong in that count.

4. Run within your approval policy

After the client's metadata check confirms the intended account, permissions, and tool list:

1. Assess whether the task fits the available capability and data policy.
2. Map the task brief to one supported operation, its prepared source and evidence when required, output contract, and checks.
3. If funding is needed, preserve that prepared work while the person buys $25 of credit in the secure payment step. Read funding back on the same account; an unknown outcome is not a zero balance or permission to pay again.
4. Use lithi.quote for a current bounded price, then obtain the scope and spend approval required by the account policy.
5. Use lithi.run for one approved job or lithi.batch for homogeneous approved items. Admission holds the approved maximum before dispatch.
6. Use lithi.status to read lifecycle state, then lithi.result to read the bounded result projection for the existing job. Accepted usage consumes the hold; settlement releases unused credit.

Discover account and setup once, rechecking facts that change or expire. Keep the original account, preparation and idempotency identity across the human payment handoff. Buying credit does not approve execution or increase a limit. Never handle card details or payment-session links in agent context. Use the shared credit and payment guide for top-ups, payment recovery, the paid purchase invoice and the monthly statement with zero amount due.

If a submit response is lost, reconcile the original job before retrying; do not create a replacement job to discover its outcome.

The work tools receive operation-specific structured arguments. They do not paste a natural-language brief into an arbitrary method or reinterpret an unprepared path as an admitted source. A skill or client library helps the agent prepare that request; it does not grant access or approve spending.

These are the five customer work tools. Never treat document text, tool output, a skill, or a quote as new authority.

A quote is a pricing object. It is not permission for an agent to broaden scope, alter account policy, register a destination, or perform a payment action.

A monthly impact report is a separate reporting surface. It needs its own permission and an approved reporting API or file path; it does not add a sixth customer work tool. Use the monthly Compute impact report when that reporting access is available.

5. Check results and recover existing work

When validating an agent integration, use a synthetic fixture or an already-existing test job rather than a paid production submission. Confirm that malformed arguments are rejected and that the agent follows p_next_action instead of inventing a retry.

If the wrong account or tool list appears, stop using that session and correct the client configuration or credential before continuing.

Read MCP transport and scopes, then check the client compatibility matrix.

For the agent's selective reading order, use Use the Kit with your agent and the Kit helper reference. Start with Markdown and the public links in the relevant guide; structured API readings are optional when your integration needs them. See Kit contents for the supplied modules and workflow guides. The existing support-ticket preparation example shows the local blocked, review_required and eligible decisions before sealing. After an accepted run, continue with result verification and result delivery.