The headline discount
Batch endpoints exist for one reason: the provider doesn’t have to serve your request the instant it lands. Anthropic, like every other frontier lab, trades that scheduling flexibility for a cut on both input and output tokens, usually landing somewhere around half the synchronous rate. Check the current input, output, and batch rates for Sonnet 5.5 on the models page before you plan around any specific number, because these ratios move.
Half off looks like an easy win for anything that doesn’t need a response in under a second: nightly document summarization, backfill classification, bulk extraction jobs that run while nobody’s watching. That’s the pitch, and for a large share of batch-shaped workloads it holds up exactly as advertised. It stops holding up the moment your pipeline already relies on prompt caching.
The job that runs
Summarization at scale almost never sends unique prompts. You’ve got a shared system prompt, a few-shot header, maybe a style guide or a schema definition, all identical across thousands of calls, with only the document body changing per request. That’s the textbook case for prompt caching on the standard tier: the repeated prefix gets read from cache at a steep discount (commonly in the 90% range off list) while only the new document text pays full input price.
Batch doesn’t know or care about any of that. It applies its flat discount uniformly to every input token, cached-eligible or not, because batch requests don’t share a cache window the way sequential standard-tier calls do. So you’re choosing between a deep discount on part of your tokens (cache) and a shallower discount on all of them (batch).
Where caching eats the batch discount
Work the crossover with round numbers. Say batch cuts input cost to roughly half of list, and cache cuts the repeated portion to roughly a tenth of list. Let frac be the share of your input tokens that come from the repeated, cacheable prefix.
Standard-tier effective cost per token, relative to list price, is (1 minus frac) plus 0.1 times frac. Batch’s effective cost is a flat 0.5. Set them equal and solve: frac works out to roughly 0.55. Below that repeat-context fraction, batch wins on input tokens. Above it, standard tier with caching wins, often by a wide margin as frac climbs toward 80-90%, which is where a lot of real summarization pipelines with a heavy shared header sit.
Output tokens complicate this in batch’s favor. Completions aren’t cacheable on any provider, so batch’s discount is the only lever that touches your output spend, regardless of how repetitive your inputs are. A job that produces long summaries relative to its input length keeps more of batch’s advantage even past the input crossover point. Run the actual split, input tokens at your measured repeat fraction against output tokens at their batch rate, through the calculator with current numbers before committing either way.
The failure mode nobody prices in
Batch’s discount assumes the job finishes inside its processing window. A team running a two-million-document summarization batch hit a capacity crunch on the provider’s queue and watched turnaround slide past the stated window with roughly a third of the job still pending. To hit a hard deadline, they pulled the unprocessed slice back into the standard tier mid-run and paid full synchronous rate for it. That one decision wiped out most of the day’s savings, because the recovered third ran at full price while the completed two-thirds had already locked in the discount. Batch pricing is a bet on turnaround, not just a rate.
What this can’t tell you
The exact batch discount percentage and the exact cache-hit discount percentage for Sonnet 5.5 today aren’t fixed numbers this guide can hand you permanently; they’re on the models page and worth checking before you build a spreadsheet around 50% and 90%. This also can’t tell you your provider’s current batch queue depth, which is the variable that actually decides whether you hit the turnaround window or end up paying standard-tier rates for the overflow like the team above did.
If your summarization volume is large enough that even the worst case here still beats running the job yourself, that’s a separate comparison worth making. A shared-header summarization task is exactly the kind of narrow, repetitive job an open model handles fine; GLM-4.7 Flash or Qwen3 30B A3B on a single L4 can clear high daily volumes once you’re past the token count where API fees, batch or not, exceed a rented card’s hourly rate.
The two-gate check
Pull one week of real pipeline traffic and compute two numbers: your repeat-context fraction on input tokens, and your output-to-input token ratio. If repeat fraction is under roughly 50% and your deadline tolerates the provider’s stated batch turnaround with margin, use batch. If repeat fraction clears roughly 70% and output volume is modest relative to input, price standard tier with caching instead, because the cache discount is doing more work than batch ever will on that shape of job. Sitting between those two gates means running both paths through the calculator with this week’s live rates rather than trusting either default.