The failure of one request does not stop the batch
Anthropic states the rule in its batch documentation: the failure of one request in a batch does not affect the processing of other requests. A single malformed or oversized request does not cancel the batch. The remaining requests keep running, and the batch reaches a final state with a mix of succeeded and errored requests.
This is the reason to prefer one batch over many parallel single calls when a job tolerates delay. A bad input costs you one result, not the whole run.
Where the failures appear
Poll the batch and read request_counts. It reports five numbers: processing, succeeded, errored, canceled and expired. A batch with succeeded: 98 and errored: 2 is a partial success, not a failure.
When the batch ends, the file at results_url holds one line per request. Each line carries the custom_id you set, so you can join each result or error back to the input that produced it. A request without a unique custom_id is hard to retry, because you cannot tell which input produced the error.
Common reasons a single request fails
- 413 request_too_large. One request in the batch exceeds the size limit. Split that input into smaller requests.
- Unsupported model. One request names a model that the batch does not accept. Check that every request uses a supported model.
- Duplicate custom_id. Two requests share one ID. Make every ID unique within the batch.
- Invalid request body. One request has a malformed field. The other requests are unaffected.
Anthropic lists these checks in the batch troubleshooting section. None of them stops the batch; each one only removes that request from the success count.
When the whole batch is lost
Partial failure is contained. Whole-batch loss has three causes:
- You cancel it. A cancelled batch stops processing and its unfinished requests report as canceled.
- It runs past 24 hours. A batch that cannot finish within 24 hours expires.
- You wait more than 29 days. Results stop being downloadable 29 days after
created_at, even though the batch remains viewable.
None of these is a per-request error. They remove the results for every request that had not already completed.
How to retry only what broke
Download the results file as soon as the batch ends. Read the lines with an error and collect their custom_id values. Build a new batch from just those inputs and submit it. Do not resubmit the succeeded requests: you already paid for them, and the 50% discount applies again to the new batch only on the requests you send.
Estimate the retry cost with the Batch API Cost Savings Calculator. For a workflow that mixes batch and synchronous calls, the Workflow Retry Cost Calculator shows what a retry loop adds to the bill.
Sources
- Anthropic, Batch processing, "Troubleshooting" and "Tracking your batch": platform.claude.com/docs/en/build-with-claude/batch-processing, read 2026-10-28.
