Import an Anthropic Message Batches request set

What this connects

A message batch request set you already have, as an input. Lithi reads the request file and maps each entry onto a Compute workflow request.

The level for that file is import_compatible. Reading a request format does not make Lithi the provider's API, and any higher level exists only where a published conformance matrix says so. That matrix is the authority for your release.

Bind an exact input

Freeze the request file, then bind it by version and digest:

"snapshot": {
  "version_id": "<the request set identity you recorded>",
  "content_sha256": "<the digest of those exact bytes>"
}

Per-request identity is preserved through the run. Each entry's custom identifier stays attached to its unit and appears on the matching output row, so you join results back by identifier rather than by position.

Identifiers must be unique. A duplicate is refused with the value named, never silently merged into one unit.

Credentials

No provider key is involved and none is accepted. Lithi does not call the provider on your behalf, so a work request has no field for a provider secret.

Where the request file is staged, input.credential_ref names a registered storage credential as a reference. A secret never appears in a request, a log, a prompt or a result file.

Formats and limits

Only the measured subset is supported, and the published conformance matrix states exactly what that is: the request fields read, the outcome shapes produced, the retention behavior and the cancellation behavior.

An unsupported parameter is refused by name. It is never ignored, defaulted or approximated, because a quietly dropped parameter changes the work you are paying for while still looking successful.

Do not carry a batch item ceiling across from your previous pipeline. The maximum item count for a Lithi workflow is stated on its descriptor and repeated on your quote.

Commit the output

Outcomes arrive as a Lithi result bundle. Accepted rows land in data/part-*, typed failures in failures/part-*, abstained units in abstentions/part-*, and result-manifest.json is written last as the only complete-bundle marker.

Four lifecycle differences are worth reading before you switch anything over:

1. A quote precedes the run, carries an expiry, and never authorizes work. Approval is a separate act.
2. Cancellation is a job state. A job moves to CANCELLING, then CANCELLED, and any units already completed still appear in the bundle.
3. Retention is governed by the result bundle's own retention terms, not by the provider's. Download or deliver within your retention window.
4. A partly completed run is PARTIAL, a first-class outcome with a cursor, rather than a failure.

Every non-success carries a safe reason and a concrete next action. See what a result bundle contains.

What is not supported

Lithi is not a drop-in endpoint for any provider batch API, and this page makes no such claim.

Outside the adapter:

• Provider model names, sampling parameters or tool definitions with no workflow equivalent.
• Provider-shaped output files, streaming results or provider error codes.
• Polling a provider batch identifier. Use lithi status against your own job.
• Any behavior not named in the published conformance matrix, including limits you remember from elsewhere.

If admission answers REPLAN_REQUIRED, the file or the workflow version moved after you quoted. Re-read the descriptor at the version your quote names, rebuild the request, quote again, then approve again.