> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. # Run and follow Compute jobs ## Follow one approved job from quote to result A free estimate helps you decide whether the work fits; it is not a quote, access grant or execution authority. A job is one admitted execution of defined work. The useful sequence is: ```text title="Follow one approved job from quote to result" kind="text" fixed input + approved quote → one job_id + idempotency_key → current state → accepted result ``` Submit the exact approved intent once, save its identity, then read each state and result. A successful request response does not prove admission, completion or delivery. Your agent keeps the goal, project context and final decisions. The Compute Kit prepares permitted input and connects the approved interface. The Lithi Agent Network supplies participating Macs; Lithi returns state and result records for your agent to check. Before you submit, confirm the account, input identity, capability, operation, output contract, data profile, deadline, priority, destination, signed quote and required approval. A quote is not approval. A capacity reservation is not execution. A job submission is not a completed result. The quote carries the exact request terms. Review `input_tokens_exact`, `estimated_output_tokens`, `maximum_output_tokens`, `estimated_charge_nano_usd`, `maximum_charge_nano_usd`, and the signed `verification_level`. It can also carry `eta_p50`, `protected_completion_at`, `latest_safe_start`, `deadline_state`, `capacity_state`, `forecast_expires_at`, and `forecast_basis_digest`. Those timing and capacity values are forecasts at quote time. They are not a completion guarantee, a provider-Mac selection, or permission to exceed the approved scope. `capacity_eta_seconds` remains available for clients that use that quote field. The owner-approved tariff is USD 0.05 per million input tokens and USD 0.10 per million output tokens. For example, 10 million input tokens plus 2 million output tokens is USD 0.70 before applicable adjustments. The signed quote and usage records remain the authority for a particular request. ## Approve the exact job intent The `LithiJobV1` body binds the work you approved. Its required identity includes `task_id`, `trace_id`, `workflow_run_id`, `account_id`, `quote_id`, `capability`, `operation`, and `idempotency_key`; `task_id` and `workflow_run_id` identify the same workflow while `trace_id` is distinct. The `input` names an encrypted artifact and public bounds. The `contract` names the output schema, output limit, hard gates and verification mode. `execution` names the data profile, priority, deadline and engine policy. `delivery` names the destination and result-recipient key. Keep that serialized body with the signed quote and approval. Changing any bound, input, deadline, destination, verification choice or output requirement is revised work: reconcile the original identity first, then obtain the quote and approval required for the new intent. Keep your agent's task brief with that request. The body carries the supported contract and bounds; the brief supplies the semantic context and acceptance rule your agent will use when it checks the returned result. A brief cannot add request fields or broaden the approved job. ## Submit once and keep the identity Save the request body and idempotency key before you send it. An accepted response gives you the job identity to use for status, result and recovery. If the response is lost, do not create a new job just to discover what happened. Read the existing identity first and use the original idempotency key only when a bounded exact retry is appropriate. The same customer-authorized request remains the same work when a transport attempt is duplicated; it does not become a second charge. See [Safe retries](/docs/compute/jobs/idempotency-and-retries). ## Let Lithi choose the physical execution State the outcome, constraints, deadline and priority. You do not choose provider Macs, Cells, execution-shard sizes or retry topology. Preparation in your environment may split eligible declared-splittable units and seal encrypted blocks. Lithi's network composes execution shards from those blocks and places physical attempts on eligible Macs. If one Mac cannot complete a task, another eligible Mac can try the same logical work. Several physical attempts can exist for one logical task. Only the accepted result allowed by the work contract counts as accepted customer work for that task. Physical attempts are not automatically customer billing units. The quote and its usage policy define the accepted unit used for customer billing; reconcile that unit with the usage and receipt records. Transport retries, platform hedges, default verification and delivery repair are covered by the approved request. A delivery failure retrieves the same accepted output and does not require another Compute run. For the deeper architecture, use the Lithi Cells and Execution Papers rather than trying to control placement from the job request. ## Read the actual state Use the stable job ID to read the current state. `GET /v1/jobs/{id}` is `getJob(jobId)` in the TypeScript client; `GET /v1/jobs/{id}/events` is `listJobEvents`, and `GET /v1/jobs/{id}/result` is `getJobResult`. A transport success proves only that the API call completed; it does not prove that the job finished. The state tells you what Lithi has recorded about admission and progress. It does not decide whether the returned work meets your task's acceptance rule; your agent checks the result and evidence. Keep these questions separate: - Was the job admitted? - Is it waiting, running or terminal? - Did every required logical item reach an accepted outcome? - Is a result available? - Was delivery completed? Read the returned `state`, `digest` and `p_next_action` together with the job and result identity. Do not infer a terminal outcome from elapsed time, an empty event page or a client timeout. For a small approved test, keep the returned job ID with the original request. If the job is still waiting, follow its recorded next action and check that same job again. When output is available, use its result identity to review coverage and files against your test's acceptance rule. For time-sensitive work, use [Booking and priority](/docs/compute/booking) and [Deadlines and capacity](/docs/compute/jobs/deadlines-and-capacity). ## Use batches only for independent work A batch groups independent jobs under one submission and reconciliation boundary. It does not create dependent workflow stages or choose physical runtime batching. Use [Batches](/docs/compute/jobs/batches) when each item can finish without another item's output. ## Recover the specific problem Use the matching recovery: - unknown submission → reconcile the existing job; - capacity/deadline refusal → rebook or requote the still-needed work; - cancellation → read the confirmed cancellation outcome; - partial completion → reconcile accepted and unresolved items; - delivery failure after acceptance → deliver the existing result, not a new compute run. Continue with [Results](/docs/compute/results) when the job has output to review. If the job is partial, canceled, or delivery failed, keep accepted output and unresolved work separate and use the matching recovery page before preparing a deliberate new request.