LLM Batch API Pricing: When 50% Off Is Worth It

The batch API is the least complicated discount in LLM pricing. Submit your requests as a file instead of a stream, accept that results arrive within 24 hours instead of two seconds, and pay half. No prompt engineering, no model migration, no quality tradeoff. Every major provider offers it and the number is almost always the same.

So the question isn’t whether it works. It’s whether 50% off is the lever you should be reaching for first — and for most teams, it isn’t. Here is the arithmetic, computed from our catalog as verified 2026-08-31.

50% is a ceiling, not a rate

14 of the 18 models in our catalog offer a batch tier, and every one of them prices it at exactly half of real-time, on both input and output. That consistency makes the headline easy to remember and easy to misapply, because the discount only touches the traffic you can actually defer:

effective saving = 50% × (share of calls that can wait)

100% batch-eligible  →  50% off
 60% batch-eligible  →  30% off
 20% batch-eligible  →  10% off

Most products are not 100% deferrable. A chatbot is 0% — a user is waiting. A RAG pipeline is 0% at query time, though the embedding and summarisation passes behind it may not be. The workloads that genuinely clear the bar are the boring ones: nightly document processing, bulk classification, backfills, evals, synthetic data generation. That is why our Document processor archetype is the only preset that turns batch on by default.

What it looks like on a real workload

5,000 documents/day at 8,000 input and 800 output tokens each, engine defaults otherwise (8% retries, 40% cache hit rate, 15% infra overhead, per-model tokenizer calibration):

Note that the saving lands just under 50% rather than exactly on it. Retries are the difference: a failed call still costs tokens, and we model that overhead at real-time rates. It’s a small, deliberately conservative gap.

Batch and caching don’t add up

This is the part that trips people up, and it cost us a bug. If caching saves ~90% on input and batch saves 50% on everything, it is tempting to add them and expect something near 140% — or, more sensibly, to expect batch to take another 50% off your already-discounted bill. Neither is what happens.

Providers stack the two multiplicatively, and the batch discount applies to what you are actually billed. A cached read inside a batch job costs cached_rate × 0.5. So the batch discount is taken on your post-cache spend, not on the list price:

in_spend      = in_cost - cache_savings        # what you're actually billed
batch_savings = (in_spend × 0.5 + out_cost × 0.5) × batch_pct

The consequence is unintuitive: at 100% batch eligibility your bill is exactly half, and your cache hit rate does not change that. Caching and batch are not additive levers stacking toward some deeper discount. Caching decides how much you spend; batch halves whatever that turns out to be.

There is a second-order effect worth knowing, though. Caching shrinks the input side of the bill, which shifts where batch does its work. On this workload Claude Sonnet 4.6’s input is 67% of the raw per-call cost — but once a 40% cache hit rate has fired, the input you still pay for is only 56% of it. The better your caching, the more of the batch discount is really coming off your output tokens. Output-heavy work benefits more from batch than the rate card suggests; input-heavy work with good caching benefits less.

Dropping a tier still beats batching

Batch is capped at 50%. The gap between capability tiers is not. On the same workload, Claude Sonnet 4.6 with every single call batched costs $3,101/mo — while Claude Haiku 4.5 at full real-time pricing, answering instantly, costs $2,013/mo.

The cheaper tier wins by 35% and gives you the latency back. That is the ordering to internalise: pick the tier your task actually needs, get caching working, and only then decide what can wait 24 hours. Reaching for batch first means accepting a hard latency constraint to chase the smallest of the three levers.

Where batch isn’t on the menu at all

4 of the 18 models here have no batch tier: Llama 3.3 70B, Llama 3 8B Lite, GPT-OSS 120B (Groq), GPT-OSS 20B (Groq). They are all open-weights models on inference platforms, and the omission is a product decision rather than an oversight — those platforms sell latency. Asking them for a slow, cheap queue is asking them to compete on the axis they deliberately didn’t pick.

If batch economics are load-bearing for your architecture, that eliminates those rows regardless of where they land on price. Capability filters cut more options than price does.

DeepSeek’s discount is a clock, not an endpoint

One genuine exception worth knowing. DeepSeek has no batch API; what it has is off-peak pricing — every token is 50% off outside 01:00–04:00 and 06:00–10:00 UTC. We model it in the batch fields because the arithmetic is identical, but the mechanism is better in one specific way: you get the discounted rate at real-time latency, just only during certain hours. No batch tier gives you that. If your bulk work already runs overnight in a European or US timezone, you may be paying the discounted rate without doing anything.

When 50% off is actually worth it

• When the work is genuinely asynchronous. Not “users would tolerate slowness” — nobody is waiting at all. Nightly jobs, backfills, evals, bulk classification.
• After you’ve chosen the tier. A tier drop usually beats the entire batch discount and costs you no latency. Do that first.
• When the eligible share is most of your volume. At 20% eligibility you are chasing 10% off while adding a queue, a polling loop, and a failure mode. That complexity has to be paid for somewhere.
• When you can tolerate the tail. The SLA is “within 24 hours”, not “about an hour”. Anything with a daily deadline needs a real-time fallback path, which is a second code path to maintain.
• Not as a substitute for caching. Caching cuts what you spend; batch halves it. Get the first one working before you take on a latency constraint for the second.