Import an OpenAI Batch JSONL file

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:

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

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.