Summary

  • OpenAI's Batch API advertises a 50% discount against synchronous requests and a 24-hour completion window. An expired batch can still contain completed, billable requests.
  • Unfinished requests are cancelled at expiry. Successful responses go to the output file, expired ones to the error file; custom_id is the join key for finding what the buyer received and what remains to be run.

Half price sounds like a purchasing decision. A deadline turns it into an operations decision.

OpenAI's Batch API takes a file of individual requests, processes them asynchronously and offers a 50% discount compared with synchronous APIs. It uses a separate rate-limit pool and describes a 24-hour turnaround. For evaluation runs, repository classification or a large embedding job, that arrangement can make a backlog cheaper to process. It also moves the buyer's deadline into OpenAI's queue.

At the end of the 24-hour window, the result may be split. OpenAI says a batch that does not finish moves to expired. Requests that did finish remain available in the output file. Requests still waiting are cancelled and written to an error file with the code batch_expired. Tokens consumed by completed requests are charged. The batch has ended; the work may not have.

That is the market catch. The discount attaches to completed units of model work, while the buyer's own deliverable may require every unit. A firm classifying a repository cannot treat a missing subset as classified. A team running evaluations cannot silently average only the cases that returned before the deadline. The charge for completed work is real; completion of the buyer's whole project is a different fact.

The API supplies the means to separate those facts. Each input line carries a unique custom_id. The successful output file has a response line for each successful request, and failed requests appear in the error file. OpenAI warns that output lines may arrive in a different order from input lines. Row position is therefore a bad ledger. Match custom_id to the submitted file, distinguish completed answers from batch_expired errors, and count the remaining work from that join.

The retrieved batch object adds a second view: status, an expiration timestamp, output and error file IDs, request counts for total, completed and failed, and token usage fields for eligible batches. Those counts tell an operator where to look; the two files tell the operator which records actually returned. A dashboard total cannot decide which missing input should be retried. The custom_id can.

Resubmission has a cost boundary. A buyer who reruns every original line after an expired batch sends the already completed lines back through the meter. A buyer who submits only the unresolved IDs preserves the completed work and limits the second run to the gap.

OpenAI's public documents give the price rule and the expiry behavior. They contain no customer's expired output file or invoice. A specific loss figure would require those two records and the model's applicable rates.

The most useful question for a procurement team is therefore concrete: is the purchased thing a discounted set of model responses, or a complete result by the project's deadline? OpenAI sells the first. The buyer must build the control that makes the second visible.

Sources