Figures on this page were verified 31 August 2026 against the providers' own documentation. Pricing, context windows and rate limits change without notice, so confirm any number against the provider before you rely on it. Tell us if something here is out of date.
Batch processing is 50% off on Anthropic, and it is the easiest discount in the whole pricing surface to claim: the same request, the same model, half the price. The only thing you trade is immediacy. If a workload does not need its answer inside the request cycle, running it synchronously is paying double for nothing.
What the discount costs you
You submit a set of requests as a job and collect results when it completes, rather than blocking on each call. Completion is asynchronous and not instantaneous, so the question is never whether batch is cheaper. It is whether your workload tolerates delay.
| Workload | Tolerates delay? | Verdict |
|---|---|---|
| Interactive chat | No | Synchronous |
| Autocomplete or inline suggestions | No | Synchronous |
| Moderation before a user-visible post | Usually no | Synchronous |
| Nightly classification of new records | Yes | Batch |
| Backfilling embeddings or summaries | Yes | Batch |
| Evaluation runs over a test set | Yes | Batch |
| Bulk content generation for later review | Yes | Batch |
The pattern most teams miss
A great deal of work that looks interactive is not. If a user uploads a document and expects results shortly, that is a job, not a request. Anything already sitting behind a progress indicator, an email notification or a webhook can move to batch without anyone noticing.
Evaluation runs are the clearest case. Running a 5,000-example suite synchronously is expensive, slow because of rate limits, and pointless because nobody watches it finish. It is the ideal batch workload and frequently the largest single line on a development bill.
Batch and caching stack
These combine, and that is where the real saving lives. A classification job with a long fixed instruction block gets the batch discount on everything and the cache-read rate on the repeated prefix. Order the requests so the shared prefix is byte-identical across the job and you pay full price for very little of it.
What to watch
- Partial failure is normal. Individual requests within a job can fail independently. Reconcile results against inputs by ID rather than assuming a complete set came back.
- Never batch anything with a user waiting. The discount is not worth a timeout in a request handler.
- Results still cost output tokens. Batch halves the rate, it does not change the volume, so capping
max_tokensstill matters. - Model your own numbers. The cost calculator prices a workload across models; halve the result for anything you can move to batch.
For the other levers on an LLM bill, see what actually drives your API cost.
Frequently asked questions
What do I give up for the batch discount?
Only immediacy. It is the same model and the same request at half the price, but completion is asynchronous. If nothing is blocking on the result, running synchronously is paying double for nothing.
Which workloads should move to batch?
Anything already behind a progress indicator, an email or a webhook. Nightly classification, backfilling embeddings, bulk generation for later review, and above all evaluation runs, which are usually the largest avoidable line on a development bill.
Can I combine batch with prompt caching?
Yes, and that is where the real saving is. The batch discount applies to everything while the cache-read rate applies to the repeated prefix, so order requests to keep the shared prefix byte-identical across the job.
