Compute work API reference

Start with the operation table that matches the method and path you need. Then check its request and response schema, required scope, and current account authority. The REST API has more endpoints than the five customer MCP work tools; neither a tool name nor a contract version determines a URL.

Your existing agent keeps the goal, context, edits, native builds and tests, and final acceptance. The Compute Kit prepares permitted input and connects an approved compatible MCP or API interface; people-owned participating Macs process supported work. Integrity, schema, coverage and receipt checks establish their stated boundaries, but they do not establish semantic correctness or promise a pull request. For coding work, the existing agent remains responsible for repository edits, native builds, tests and the final decision.

Quotes, jobs and batches

The success column names the HTTP status and the schema inside the REST envelope's data field.

Authentication and request rules

The API description declares https://lithi.ai as the server. Authenticate with an account-scoped bearer key from protected credential storage. The scope column below is the operation's required grant; request fields do not widen that grant.

Send Accept: application/json. JSON bodies use Content-Type: application/json and UTF-8. Every POST listed here requires an Idempotency-Key; GET requests do not. A key is 8–128 ASCII characters matching ^[A-Za-z0-9._:-]+$.

The tables identify the HTTP contracts. An approved account, applicable permissions, valid request, and current work admission remain necessary; a contract row is not execution approval.

createQuote requires QuoteRequest. Its response contains status: "signed" and a LithiQuoteV1 quote. Review the quote and obtain approval separately. A task brief can help a customer agent prepare and review the quoted instructions, context, output schema and evidence requirements; it cannot widen the quote or grant execution authority.

createJob requires LiveBoundedLithiJobV1. The payload identifies itself as LithiJobV1 / lithi-job.v1; its idempotency_key must match the header. The request contains an encrypted artifact reference, output contract, execution settings and delivery identifiers, not arbitrary inline work data.

createBatch requires BatchRequest: quote_id, completion_policy_digest and items. Each item uses the same bounded job schema. The batch handle is batch_id, not a job identifier you can substitute into a job route.

Cancellation has an optional body. When you send a body, use CancelRequest with its declared lowercase reason_code. A bodyless cancellation still needs the idempotency header; do not send the string null as a replacement body. Read the returned job projection and subsequent status rather than assuming the HTTP response means all work has stopped.

Job and batch path identifiers are UUIDs. Preserve the handle returned for the correct resource family.

Artifacts, capabilities and evidence

Artifact preparation and completion require ArtifactPrepareRequest and ArtifactCompleteRequest, respectively. They exchange upload metadata and evidence; neither endpoint's JSON body is the ciphertext transfer itself.

The receipt route takes a receipt reference, not a job UUID. Its response contains receipt_id, receipt_digest, signature_key_id and signature. Parsing a signature field does not verify its signer or prove the model's answer is correct.

Usage records identify a job, usage digest, currency and gross_micro_usd. Keep monetary units unchanged; an observed usage record is not payment confirmation.

Compatibility routes

All four accept CompatibilityRequest, with exactly capability, operation, model_ref, quote_id, data_profile, encrypted_artifact_id and output_schema_id.

These paths do not accept arbitrary upstream request objects merely because their names look familiar. The response is a Compute job projection, not a promise of token streaming, chat completion text, embedding vectors or every upstream SDK feature.

The AWS-style path parameter is a 1–64-character string matching ^[a-z][a-z0-9._-]*$. A syntactically valid operation name does not establish that every upstream operation is supported.

Pagination, responses and limits

Event, batch-result, capability and usage list operations accept optional limit and cursor parameters. limit is 1–100. Return next_cursor unchanged when present; it is an optional string, not a nullable field. An absent cursor ends that page chain. Capability lists additionally carry catalog_digest.

REST JSON success is { "ok": true, "data": ... }. Validate data against the operation's projection. It does not universally include a request ID, timestamp, evidence class, replay flag or structured next-action object.

A job projection requires job_id, state, state_version, digest and p_next_action. A result projection requires job_id, encrypted_artifact_id, result_digest, evidence_digest and delivery_state. The result response is metadata, not an inline result file.

The JSON reader caps request bodies at 65,536 bytes. Pagination, batch-array, and ciphertext bounds apply independently. Strict request and response objects reject undeclared fields; preserve nullability, case, integer units, and nested bounds.

Error and replay handling

The REST error schema requires ok: false, error.code and a nonempty p_next_action string of 1–256 characters. "none" is valid when no further action is specified; a typed refusal can name a bounded recovery action. Treat that value as data, never as a command or permission. Read the operation's response entries for exact status coverage. Common boundary errors include INVALID_REQUEST, UNAUTHENTICATED, FORBIDDEN, PAYLOAD_TOO_LARGE, UNSUPPORTED_MEDIA_TYPE, RATE_LIMITED and UNAVAILABLE.

Correct invalid inputs before retrying. Respect Retry-After when supplied for rate limiting. A connection loss is not proof of refusal or cancellation: preserve the original idempotency key, payload and returned handles, then recover the existing intent. Do not invent a replay flag or retention window absent from the response contract.

Exactly five customer MCP work tools

MCP uses JSON-RPC at /mcp, with its own tool-result projections. The status and result tools take job_id; REST puts that identifier in the path. CLI convenience commands, local helpers and provider administration do not add customer work tools.

Monthly impact reporting uses its separate reporting:read API or an approved report file. It is not a sixth Work MCP tool.

Use the canonical Compute OpenAPI document for complete request and response definitions. Generate client bindings from that authority rather than treating a copied endpoint table as a separate API specification.