What the retention rule says
Anthropic documents three separate time limits for a Message Batch. They are easy to confuse, and the difference changes when you must download results.
- Result availability. You can access batch results when all messages have completed or after 24 hours, whichever comes first.
- Processing deadline. A batch expires if processing does not complete within 24 hours.
- Download window. Batch results are available for 29 days after creation. After that you can still view the batch, but its results are no longer available for download.
The 29 days count from created_at, not from the moment processing ended. Anthropic states this directly in its troubleshooting list: check that it has been less than 29 days since the batch created_at (not processing ended_at) time. A batch that sat in the queue for six hours therefore has slightly less than 29 days of download time left when it finishes.
How to fetch results before the window closes
Poll the batch with GET /v1/messages/batches/{message_batch_id}. The endpoint is idempotent, so repeated polls are safe. When processing_status reports ended, read the results_url field and download that URL.
Most batches complete within 1 hour, so the 24-hour deadline is a ceiling rather than a typical wait. The 29-day window is the part that needs a scheduled job. A weekly download of finished batches is enough, because no batch reaches 29 days in a week.
Store the downloaded results with your own metadata, not only the batch ID. The batch stays viewable after 29 days, but the JSONL file does not, and a stored copy is the only way to re-price or re-check old output.
What happens when a batch expires
A batch that cannot finish in 24 hours moves to an expired state. The request_counts object reports the count in its expired field. Requests that already succeeded keep their results, and the failure of one request does not affect the processing of other requests. The batch as a whole does not refund the discount for the requests that did finish.
This matters for very large submissions. Split a large job into several smaller batches so one slow request cannot take the whole set past 24 hours.
What you cannot do inside a batch
Anthropic does not support max_tokens: 0 cache pre-warming inside a batch. The vendor explains why: an ephemeral cache entry written during batch processing would likely expire before the follow-up request runs. If your workflow depends on pre-warming a cache, keep that call outside the batch and send only the real requests through the discount.
Why the retention window is not a billing window
The 29 days change when you can retrieve output, not when you are billed. Billing happens when the batch processes. The 50% discount still applies to the input and output lines of each request. Use the Batch API Cost Savings Calculator to price a job before you submit it, and treat the 29-day window as a retrieval deadline in your runbook.
Pair this page with the failure isolation guide when you plan retries, and with the Claude API cost calculator when you compare batch and synchronous pricing.
Sources
- Anthropic, Batch processing: platform.claude.com/docs/en/build-with-claude/batch-processing, read 2026-10-28.
