Review an OpenAI Batch migration

Map the request before preparing files

Your agent keeps the workload goal, authorized context and final decision. Your application maps the provider fields, while a compatible supported client or Kit helper prepares the new request when that workflow provides one. Lithi accepts the supported Compute request after transfer permission, quote and approval, then returns its own job and result identities for you to reconcile.

Start with the outcome and authorized data behind your OpenAI Batch workload. Review each field's meaning and map it to a supported Compute workflow before you prepare a new input. Keep each original request ID linked to the new job and result identities.

Review each field's meaning

Tools, attachments, multimodal content and provider-specific settings need an explicit supported mapping. Reject unmapped behavior rather than silently dropping it. A new task definition doesn't promise equivalent model output.

OpenAI documents its own Batch API. Its file envelope and lifecycle are provider-specific. Do not redirect an ordinary OpenAI client or submit its JSONL file unchanged to Lithi. The narrow OpenAI-style translator routes in the Compute reference don't establish Batch file import or official-client compatibility.

Join results by identity

This Python fixture checks identity only. Its synthetic records are not complete provider responses, and it makes no API call.

import json
submitted = ["sample-001", "sample-002"]
received = [{"custom_id": "sample-002"}, {"custom_id": "sample-001"}]
by_id = {}
for row in received:
    key = row["custom_id"]
    if key not in submitted or key in by_id:
        raise ValueError("Unknown or duplicate result ID")
    by_id[key] = row
missing = sorted(set(submitted) - set(by_id))
print(json.dumps({"ordered_ids": [k for k in submitted if k in by_id], "missing": missing}))

The output restores the submitted ID order and reports no missing IDs. In a real integration, keep the original ID-to-job mapping and inspect each result's success or exception separately. An ID match doesn't establish a successful result.

Prepare the native request

Freeze the reviewed input files and their digests. Keep OpenAI credentials outside the preparation record and never send them to Lithi. Use the file preparation workflow, then the native batch guide for the supported request contract. Review current availability and obtain approval before paid work.

OpenAI completion windows, file limits, retention, cancellation and pricing don't become Lithi guarantees. Validate the exact workflow, client and response contract used for the new workload.

Recover the existing work first

If submission is uncertain, reconcile the original request and key before creating another job. If result retrieval fails, retry retrieval for the same job. If the mapping changes, review it as new work rather than disguising it as a transport retry. Preserve successful outputs and unresolved exceptions separately.

What should I check in a small migration test?

Select a few permitted requests and map each required field to the chosen workflow. Check that your original IDs join to the returned outcomes and that exceptions remain visible; then review the outputs against your own acceptance rule. The first test describes that review before you expand the workload.

Next, review compatibility boundaries before selecting a client.