OpenAI Batch API: Lower Token Costs, Deferred Results

The OpenAI Batch API costs less than sending eligible requests through synchronous endpoints, but gives the application a different workflow. Requests are submitted together, processed asynchronously and retrieved later. It is a useful option when the output does not need to appear immediately.

OpenAI’s current Batch guide describes a 50% discount compared with synchronous APIs and a 24-hour completion window. The saving applies to the API processing covered by that arrangement, not automatically to every cost of running a business workflow.

Choose work that can wait

OpenAI identifies evaluations, dataset classification and content-repository embeddings as examples. Each can involve many independent requests whose results are useful later.

A live conversation has a different timing requirement. A user waiting for the next reply cannot usually treat a result arriving hours later as equivalent to an immediate response.

The useful question is how long the application can wait before the output loses its purpose. An overnight classification job may tolerate the window. An interactive form that needs the classification before proceeding may not.

Document that requirement before comparing prices. The lowest processing rate is useful only when the workflow can use the result on the offered terms.

Calculate the eligible processing cost

Webtamine’s model pricing database lists model token prices and its sample request cost. For a Batch comparison, consult the current official pricing and availability for the chosen model and endpoint.

Suppose, purely for illustration, that eligible synchronous token processing for a defined job costs $20. Applying a 50% discount would make the corresponding processing cost $10, assuming the same usage and applicable discount.

That arithmetic does not include preparing the data, storing files, checking responses or reviewing the output. It also does not assume that every request succeeds on the first attempt.

The example is not a current quote for a named model or a measured result. It separates the discount calculation from the other costs that remain in the workflow.

Prepare requests with stable identifiers

The Batch guide specifies a JSONL input file, with one JSON request per line. Each request includes a unique custom identifier, and an input file uses a single model.

Those identifiers matter after processing. OpenAI says the output order may differ from the input order, so an application should match results by the custom identifier rather than line position.

For an illustrative classification job, the identifier could refer to an internal record and job version. The application can then associate the response with the intended input even if the output file is reordered.

Avoid using a visible row number as the only connection when the underlying dataset can change. Preserve a manifest of the submitted records and the configuration used for the job.

Completion is a job status, not a quality verdict

The guide distinguishes validating, failed, in progress, finalising, completed and expired states, along with cancellation states.

A completed batch makes the result files available. It does not establish that every response answers the task correctly or meets the application’s own acceptance criteria.

Successful request responses appear in the output file, while failed requests have error information in a separate error file. Check both when reconciling the job.

A useful completion record therefore includes submitted requests, returned responses, failed requests and any review outcomes. Reporting only the batch’s top-level status can hide work that still needs attention.

Plan for expiration and selective retries

The 24-hour window is not a reason to omit failure handling. OpenAI documents an expired state for batches that are not completed in time.

Unfinished requests are cancelled, while responses for completed requests remain available. The guide says tokens consumed by completed requests are charged.

Use the identifiers to distinguish finished records from unfinished ones. A retry plan should preserve completed results and select the requests that actually need another attempt.

Re-submitting every input without reconciliation can duplicate processing work. Whether the duplicates cause further costs or downstream actions depends on the application, so the result-handling design should be reviewed alongside the API bill.

Limits need their own capacity check

The guide lists limits on requests per batch, input-file size and queued prompt tokens per model. Embedding batches also have a separate limit on the number of embedding inputs.

Batch uses a separate rate-limit pool from standard per-model limits. That can provide more capacity for deferred work, but it does not mean the queue is unlimited.

Check the account’s current queued-token allowance and the chosen model’s Batch support. Do not infer support from the existence of a synchronous endpoint alone.

Separate limits also mean an application should record which route processed a job. A single throughput figure combining synchronous and Batch work can be difficult to interpret.

Preserve the results you need

OpenAI’s guide says the output file is automatically deleted 30 days after the batch completes. A workflow that needs the results for longer must retrieve and retain them within its own data-management arrangement.

That is a concrete operational step, not an API-price comparison. The team needs to decide what it keeps, for how long, and how results are connected to the original inputs.

A record of model, prompt version and job configuration also makes a later review more useful. It allows the team to distinguish a changed prompt from a changed dataset or processing route.

For a broader cost review, see the cost of an AI task. API processing, result handling and human review contribute different parts of the total.

Batch and prompt caching answer different questions

Batch changes how eligible requests are submitted and when their outputs are retrieved. Prompt caching concerns reuse of eligible input computation and its pricing.

A workflow may have reasons to consider both, but one mechanism should not be used as evidence for the other’s savings. Check the provider’s current rules before assuming discounts combine.

Webtamine’s prompt caching cost guide explains cache reads and writes. Keep those charges separate in the cost model so that a reused prefix is not confused with an asynchronous processing discount.

Sources

OpenAI: Batch API guide, consulted October 7, 2026. The $20-to-$10 calculation is hypothetical; this article does not report a submitted Batch job or benchmark.