Claude's Batch API: When It Actually Cuts Your Bill in Half

Straight answer: the Message Batches API charges you half price on both input and output tokens. That's the part people miss — prompt caching only discounts repeated input, but the batch discount also covers output, which for generation-heavy jobs is most of the bill. On Sonnet 4.6 you go from $3/$15 per million tokens down to $1.50/$7.50. On Haiku 4.5, $1/$5 becomes $0.50/$2.50. On Opus 4.8, $5/$25 becomes $2.50/$12.50. No volume threshold, no negotiation — you submit the work as a batch instead of one call at a time, and it's half off.

The thing you give up is immediacy. A batch is asynchronous: you hand Anthropic a pile of requests, it works through them independently, and you come back for the results. Most batches finish in under an hour, but the only guarantee is that they complete within 24 hours. So this is a tool for work nobody is staring at a spinner waiting for.

Here's the batch discount laid against standard pricing so you can see the delta at a glance. Every number is 50% of the real-time rate:

Prices are per million tokens. Notice the discount is flat across the lineup — it doesn't matter which model you pick, batching halves it. So the model choice is still about the task (Haiku for simple classification, Sonnet for most production work, Opus for the hard reasoning), and batching is a lever you pull on top, not instead. If you're still working out which model earns its keep, I went through that trade-off in Sonnet 5 vs Opus 4.8.

Half off is nice. Stacking is where it gets stupid-cheap. The batch discount and prompt caching combine, and most real bulk jobs are exactly the shape that benefits: thousands of requests that all share a big, identical prefix — the same system prompt, the same classification rubric, the same reference document — with only a small piece changing per row.

Cached reads bill at 10% of base input. Layer that under the 50% batch discount and the repeated part of your prompt lands somewhere around 5% of the full real-time input price. I ran a moderation-style backlog this way — one fat rubric prefix, one short user comment per request — and the input side of the bill basically disappeared. The one gotcha: max_tokens: 0cache pre-warming isn't supported inside a batch, because an ephemeral cache entry written mid-batch would expire before the follow-up request runs. Structure the batch so the shared prefix is present on every request and let the normal cache mechanics do the work.

This is the same “stack every discount you can” discipline behind how I cut my Claude API bill by 73% — caching, model routing, and now batch mode all pulling in the same direction.

The line is simple: is anything blocked while this runs? If not, batch it. Jobs that fit almost perfectly:

• Evals and test suites. Running thousands of test cases against a prompt or model — nobody's waiting, and it's often the single biggest reason a token bill spikes.
• Bulk classification and moderation. Tagging, routing, or moderating a backlog of user-generated content, one row per item.
• Content generation at scale. Product descriptions, meta descriptions, summaries, first-draft emails — anything you generate in bulk and review later.
• Document processing. Extracting, structuring, or summarizing a pile of PDFs, transcripts, or support tickets overnight.
• Historical backfills. Re-scoring or re-labeling an existing dataset after a prompt change.

And the things that should never go in a batch, no matter how tempting the discount:

• Anything a user is waiting on. Live chat, support copilots, an interactive agent step — a 50% saving is worthless if the customer stares at a loading spinner for 40 minutes.
• Latency-sensitive automations. A webhook that has to respond in seconds can't wait on an async job with a 24-hour ceiling.
• Tightly-coupled agent loops. If step two depends on step one's answer right now, that's a real-time conversation, not a batch.

A lot of agent cost, though, hides in the boring repeated calls — the tool schemas and system prompts that ride every step. Some of that you fix with caching and routing; some of it you can lift out of the hot path entirely and run as a nightly batch. It pairs naturally with the token-tax thinking in what subagents really cost in tokens and the token overhead MCP servers add to every call.

A few hard edges that will bite you if you don't plan for them:

• Size cap: one batch holds up to 100,000 requests or 256 MB, whichever comes first. More than that, split into multiple batches.
• The 24-hour ceiling is real. Most batches finish in under an hour, but under heavy demand some requests can expire at 24 hours. You're not billed for expired requests, but you do have to resubmit them — so build retry logic, don't assume 100% completion.
• Results live for 29 days. You can download results for 29 days after creation; after that the batch is still visible but the results are gone. Pull and store what you need.
• Every request needs max_tokens of at least 1. And stream results back by custom_id rather than downloading everything at once — large batches produce large result files.
• Fast mode doesn't apply. Batch is the opposite trade from fast mode; you can't have both on the same request.

The one that trips people is treating the sub-hour typical case as a promise. Design around the 24-hour guarantee: fire the batch, poll for status, handle the succeeded, errored, and expired results separately, and resubmit anything that expired. The official mechanics and the full status model live in Anthropic's batch processing docs.

• The Batch API bills input and output at 50% off — output too, which caching never discounts.
• It's unconditional: no minimum volume, same half-price rate across Haiku, Sonnet, and Opus.
• Stack it with prompt caching and a repeated-prefix bulk job lands near 5% of the real-time input cost.
• One batch holds up to 100,000 requests or 256 MB; results are retrievable for 29 days.
• Most batches finish in under an hour, but design for the 24-hour guarantee and handle expired requests.
• Use it for evals, bulk classification, content generation, and document processing — never for anything a user is waiting on.