> ## 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 OpenAI Batch JSONL file
description: >-
  Importing a JSONL batch file is not wire or SDK compatibility. Keep your
  per-request custom identifiers, and read the lifecycle differences before you
  switch a pipeline over.
route: /docs/compute/integrations/openai-batch
page_id: docs-compute-integrations-openai-batch
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Engineers moving an existing batch request file into a Compute workflow
voice: D
reader_question: Can I send my existing OpenAI Batch JSONL file to Compute?
primary_action: Import the JSONL file and request a quote
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-openai-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

A batch request file you already have, as an input. Lithi reads the JSONL you wrote for OpenAI's Batch API and maps each line onto a Compute workflow request.

The level for that file is `import_compatible`. Reading a vendor's file format never makes Lithi that vendor's API, and any higher level is a separate claim that only a published conformance matrix can support. Check the matrix for your release before you assume more than import.

## Bind an exact input

Freeze the JSONL before you submit it, exactly as you would any other file:

```json
"snapshot": {
  "version_id": "<the file identity you recorded>",
  "content_sha256": "<the digest of those exact bytes>"
}
```

Per-request identity is preserved. The custom identifier on each line stays attached to that unit through the run and appears on the corresponding output row, so you can join results back to your own records without relying on order.

Duplicate identifiers are refused rather than merged. Make them unique before you submit. See [how item identity works](/docs/compute/inputs/item-identity).

## Credentials

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

Your Lithi work key carries the six work scopes only. Where the file is staged, `input.credential_ref` names a registered storage credential as a reference.

## Formats and limits

Only the request shapes named in the published conformance matrix are read. The matrix states the supported upstream version, the fields, the lifecycle, the errors and the limits, and it is the authority when this page and your file disagree.

Everything else is refused by name. An unsupported endpoint, an unknown parameter or a model reference that does not resolve to a Lithi workflow is rejected with the field named, never dropped or approximated.

Do not carry a batch item ceiling over 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

The output is a Lithi result bundle, not a provider output file. Accepted rows land in `data/part-*`, typed failures and abstentions in their own directories, and `result-manifest.json` is written last as the only complete-bundle marker.

Expect the lifecycle to differ, and plan for it rather than mapping states one to one:

- A quote comes first and never authorizes work. Approval is a separate act.
- A job moves through `ADMITTED`, `RUNNING`, then a terminal state such as `SUCCEEDED`, `PARTIAL`, `FAILED` or `CANCELLED`.
- A partial run is a first-class outcome with a cursor, not an error to retry wholesale.
- Every non-success carries a safe reason and a concrete next action.

## What is not supported

Lithi is not an OpenAI-compatible endpoint, and this page makes no such claim. Do not point a client library at Lithi expecting provider behavior.

Outside the adapter:

- Provider model names, sampling parameters or response formats that have no workflow equivalent.
- Endpoints absent from the published conformance matrix.
- The provider's own error codes. Lithi returns its own typed states with next actions.
- Any output file shaped like the provider's. You get a result bundle.

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, quote again, then approve.