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

---
title: Import an Anthropic Message Batches request set
description: >-
  Only the measured request, outcome, retention and cancellation subset is
  documented here. Per-request identity is preserved, and an unsupported
  parameter is refused rather than ignored.
route: /docs/compute/integrations/anthropic-batches
page_id: docs-compute-integrations-anthropic-batches
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Engineers moving an existing message batch request set into Compute
voice: D
reader_question: Can I bring my Anthropic Message Batches requests into a Compute workflow?
primary_action: Import the request set and request a quote
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-anthropic-batches-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## 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:

```json
"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](/docs/compute/results/bundle-layout).

## 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.