Half your LLM bill might be paying real-time prices for work that doesn't run in real time. Nightly enrichment jobs, eval suites, bulk classification backfills — most teams route these through the same synchronous endpoint as their chat interface, by default, simply because that's how the first version got built. OpenAI's Batch API exists specifically to fix that, and the discount is bigger than most teams realize.
1. Flat 50% discount on input and output tokens, across every OpenAI model — no volume tiers, no minimums.
2. 24-hour completion guarantee; many batches finish well under that in practice.
3. The set of workloads that qualify is usually bigger than teams assume once they actually audit which endpoints need to be real-time.
The Discount, Precisely
OpenAI's Batch API gives a flat 50% off both input and output tokens for requests submitted asynchronously, with results guaranteed within 24 hours. Unlike volume-based enterprise discounts, this applies uniformly across every model in the lineup — there's no minimum spend and no tier to qualify for. Submit a batch of 10 requests or 10 million, the discount is the same 50%.
| Model | Standard Rate (in/out) | Batch Rate (in/out) |
|---|---|---|
| GPT-5 Mini | $0.25 / $2.00 | $0.125 / $1.00 |
| GPT-5 Nano | $0.05 / $0.40 | $0.025 / $0.20 |
| GPT-4o | $2.50 / $10.00 | $1.25 / $5.00 |
Anthropic's Message Batches API matches the structure — the same flat 50% off input and output — and stacks with prompt caching discounts, so a batch job with a stable, cacheable system prompt can end up considerably cheaper than either discount alone.
What Actually Qualifies
Fits Batch
- Overnight enrichment (data labeling, classification, tagging)
- Eval suites and regression test runs
- Bulk classification of historical data
- Dataset labeling for fine-tuning
- Embedding backfills
- Scheduled report generation (weekly digests, monthly summaries)
Doesn't Fit Batch
- Chat interfaces — anything a user is actively waiting on
- Agent loops where output A feeds directly into input B
- Any latency-sensitive workflow with a sub-minute expectation
- Requests that depend on another batch's result in the same flow
The dividing line isn't "is this important" — it's "does a human need this response inside seconds." A lot of internal-facing, scheduled, or backend-only work clears that bar easily once you actually ask the question endpoint by endpoint, rather than assuming everything needs to be synchronous because the first version was built that way.
Not sure which of your endpoints qualify?
Preto tags requests by latency sensitivity, so you can see exactly which ones could move to batch pricing without touching your product experience.
Find Your Batch-Eligible RequestsPreto tags requests by latency sensitivity. See which qualify for batch.
A Real Public Example
Quora is publicly on record using Anthropic's Batches API for summarization and highlight-extraction features, describing the appeal directly: it's simpler to submit a batch and download results within 24 hours than to manage the complexity of running many parallel live queries at scale. That's the operational case for batch beyond the pricing — it's also less infrastructure to maintain for work that was never actually latency-sensitive in the first place.
The Implementation Pattern
Audit your top-cost endpoints and ask, for each one: does the user need this response within five seconds, or could it be queued and delivered later? The set of "could be batched" is almost always bigger than the first-pass answer suggests — internal analytics, recurring report generation, content moderation backlog processing, and anything that already runs on a cron schedule are common candidates that get missed because they were built as synchronous calls out of convenience, not necessity.
Once you've identified a batch-eligible endpoint, the migration is mechanical: collect requests into a JSONL file, submit as a batch job, poll or webhook for completion, and process results asynchronously instead of blocking on a response. The 24-hour window is a ceiling, not a target — most batches complete in a fraction of that time, so the user-facing latency cost of switching is usually smaller than it sounds.
Batch is one of five recurring patterns behind most cost-reduction results — see how it stacks with routing and caching for the full before/after picture. And if the caching side of your stack isn't set up yet, the response caching implementation guide covers the other big non-realtime win.
Frequently Asked Questions
How much does the OpenAI Batch API actually save?
How long does the OpenAI Batch API take to return results?
What kinds of LLM workloads qualify for batch processing?
What doesn't fit the Batch API?
See which of your requests could be running at half price.
Preto tags every request by latency sensitivity, so you can find your batch-eligible traffic without manually auditing every endpoint.
Find Your Batch-Eligible RequestsFree forever up to 10K requests. No credit card required.
