Batch API: real 50% savings, or a promise with a catch?

By LW Forge — maintainer of LLM Scout · Updated September 7, 2026

A flat 50% discount, applied to every model, with no volume threshold and no separate contract, sounds like the kind of offer that comes with a catch buried in the terms. It mostly doesn't. Both OpenAI's Batch API and Anthropic's Message Batches API cut the standard per-token rate in half, uniformly, for requests you're willing to submit as a batch rather than call one at a time. The actual catch is simpler and stated up front: results come back within a 24-hour window, not instantly. Whether that's free money or a bad trade depends entirely on whether your workload was ever real-time to begin with.

What the discount actually is

Submit a batch of requests — a JSON file with one line per call, in OpenAI's format, or an equivalent structure for Anthropic — and the provider processes them asynchronously, outside the normal request queue, at half the listed input and output rate. OpenAI's batch jobs typically complete in a few hours for most workloads and are guaranteed within 24. Anthropic's Message Batches API works the same way: 50% off standard token prices, results within 24 hours. Neither provider varies the discount by model tier — a batch call to a flagship model gets the same 50% as a batch call to the budget tier.

At August 2026 prices, that's mechanical: GPT-5.6 Sol's $5.00 / $30.00 per million tokens becomes $2.50 / $15.00 in batch. Claude Sonnet 5's $3.00 / $15.00 becomes $1.50 / $7.50. Run the same numbers for your own volume in the OpenAI or Claude calculator, then halve the total — that's your batch estimate.

The catch is real, but it's not hidden

The 24-hour SLA is stated plainly in both providers' documentation, so calling it a "catch" is generous — it's a trade you're offered explicitly, not one you discover after the fact. The actual risk is that teams underestimate how much of their workload is genuinely latency-sensitive. Three questions separate a good batch candidate from a bad one:

1. Does a human wait for this response right now? If yes — a chat reply, a live support answer, an autocomplete suggestion — batch is disqualified regardless of the savings. A 50% discount on a response nobody can wait 24 hours for isn't a discount, it's a broken product.
2. Is the output consumed by a downstream process rather than a person? Nightly re-scoring of a support ticket backlog, bulk classification of historical records, overnight summarization of the day's documents — these have no human staring at a spinner, which is exactly the shape batch rewards.
3. Can you tolerate the tail, not just the average? "A few hours" is typical, not guaranteed. If a report needs to exist by 9am and you submit the batch at 11pm, you have margin. If you submit at 7am for a 9am deadline, you're gambling against the SLA's stated ceiling.

Where the discount actually shows up

Bulk classification and tagging. Sorting 500,000 support tickets by category, sentiment, or urgency overnight is close to the canonical batch use case: high volume, no user staring at the result, naturally schedulable. On GPT-5.6 Luna, a 500,000-ticket run at 300 input and 20 output tokens each — 150M input, 10M output tokens — costs about $34 at standard rates and $17 in batch.

Dataset generation and evaluation. Running a model against thousands of eval prompts, or generating synthetic training data, is inherently non-interactive. Batch halves the cost of a task that was already going to run unattended.

Document pipelines with a schedule, not a deadline. Summarizing yesterday's intake of PDFs before the team arrives in the morning fits the SLA naturally, since "before 9am" and "within 24 hours of an 11pm submission" are the same constraint. See the full cost breakdown for summarizing a PDF for the per-document math this stacks on top of.

Re-embedding after a model or chunking change. The RAG cost breakdown covers this in detail: re-embedding a large corpus is exactly the kind of one-off, schedule-not-deadline job the 24-hour window was built for, and it's often the single largest one-time bill in a RAG system's life.

Where it doesn't apply, even though the temptation is real

The mistake we see most is applying batch to a workload that's "usually" not urgent but occasionally is — a support system that's 95% overnight backlog processing and 5% "the CEO needs this answer now." Splitting that traffic by actual urgency, rather than batching everything for the average case, protects the 5% without giving up the discount on the 95%. Batch and real-time calls to the same model can run side by side; nothing about using one disqualifies the other for a different part of the same system.

Stacking it with other discounts

Batch pricing and prompt caching solve different problems and combine cleanly: caching cuts the cost of a repeated stable prefix, batch cuts the cost of not needing the answer instantly, and neither depends on the other. A nightly batch job that re-sends the same long system prompt on every one of 100,000 calls benefits from both — cache the prefix, batch the job — and the savings multiply rather than compete. See prompt caching savings for the mechanics of the other half of that stack.

The honest verdict

The 50% figure is real, uniform, and not a marketing number that shrinks once you read the fine print — both providers apply it exactly as advertised. The decision that actually needs judgment isn't "is the discount real," it's "was this task ever real-time." Audit your workload by that question before your model choice, because a task that doesn't need an instant answer is worth exactly the same 50% whether you're running it on a flagship model or a budget one — the discount rewards the shape of your workload, not which model you picked.