> ## 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 xAI batch request set
description: >-
  The create-and-add lifecycle is supported only where a published conformance
  matrix says it was tested. Lithi never silently approximates it as another
  provider's batch lifecycle.
route: /docs/compute/integrations/xai-batch
page_id: docs-compute-integrations-xai-batch
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Engineers moving an existing xAI batch request set into Compute
voice: D
reader_question: Can I bring my xAI batch requests into Compute, and what actually behaves the same?
primary_action: Import the request set and request a quote
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-xai-batch-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

An xAI 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`. Anything beyond import exists only where a published conformance matrix names it, and that matrix is release-specific. Read it rather than assuming a level.

## Bind an exact input

This provider's shape differs from others in a way that matters at the very first step. Where one provider takes a whole file at creation, this one creates a batch and then adds requests to it.

That means your request set may exist in several pieces. Assemble the complete set first, freeze it, and bind the assembled bytes:

```json
"snapshot": {
  "version_id": "<the assembled request set identity>",
  "content_sha256": "<the digest of those exact bytes>"
}
```

Per-request identity is preserved through the run, so results join back by your own identifier. Duplicate identifiers are refused by value rather than merged.

## Credentials

No provider key is involved and none is accepted. Lithi does not call xAI on your behalf, so a work request has nowhere to put a provider secret.

Where the file is staged, `input.credential_ref` names a registered storage credential as a reference. Register it, test it, read it back, and revoke it when the work ends.

## Formats and limits

Only the fields and lifecycle steps the published conformance matrix names as tested are supported. The matrix states the supported upstream version, the fields, the lifecycle, the errors and the limits.

An unsupported field is refused by name, not defaulted. That refusal is the point: a parameter that was quietly ignored would change the work you paid for while the run still reported success.

Do not reuse a batch item ceiling from another provider. 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 and abstentions sit beside them, and `result-manifest.json` is written last as the only complete-bundle marker.

The lifecycle is Lithi's, and it is stated rather than implied:

- A quote comes first, carries an expiry, and never authorizes work. Approval is a separate act.
- A job moves through `ADMITTED` and `RUNNING` to `SUCCEEDED`, `PARTIAL`, `FAILED` or `CANCELLED`.
- Adding requests to a running job is not supported. Submit the assembled set once.
- A partly completed run is `PARTIAL` with a cursor, and every non-success carries a safe reason and a next action.

Where this provider's behavior differs from another's, the difference is documented rather than smoothed over. See [what each compatibility level means](/docs/compute/integrations/compatibility-levels).

## What is not supported

Lithi never treats one provider's batch lifecycle as a stand-in for another's, and makes no wire, SDK or endpoint compatibility claim here.

Outside the adapter:

- Any assumption carried over from a different provider's batch API, including its states, its errors and its limits.
- Incremental request addition after submission.
- Provider model names, sampling parameters or provider-shaped output files.
- Behavior the published conformance matrix does not list as tested.

If a field is refused, the response names it. Remove or map that field, rebuild the request set, take a new digest, then quote and approve again.