Claude API — Message Batches API (batch processing)

Anthropic's guide to submitting many Claude requests at once and collecting the answers later. Routed here on 2026-09-04 as the third page in this spoke's provider-API-access thread, beside claude-api-rate-limits and claude-refusals-and-fallback. The reason it matters to a market wiki is the price: all batch usage bills at 50% of the standard rate, the largest lever on the llm-api-pricing card that costs the buyer nothing except patience.

The trade: latency for half price

You post a list of Messages requests, each tagged with your own custom_id; the batch is processed asynchronously and each request is handled independently. Anthropic says most batches finish in under an hour, but the only guarantee is the ceiling. Results become available when every request has finished or after 24 hours, whichever comes first, and anything still unprocessed at 24 hours expires. So the contract is not "an hour"; it is "within a day, usually much sooner." Under load, the docs say plainly that more requests may expire.

The limits

• 100,000 requests or 256 MB per batch, whichever is hit first.
• 24-hour processing window; 29 days of result retention afterwards (the batch record survives, the downloadable results do not).
• Scoped to a Workspace — batches and results are visible only to API calls in the same workspace, and Console downloads can be disabled per org or per workspace.
• Batches can overshoot a workspace spend limit, because throughput is high and concurrent. A cost control that is normally hard becomes approximate.
• A submitted batch cannot be edited — cancel and resubmit, and cancellation is not immediate.

What can and cannot be batched

Nearly the whole Messages API: vision, system prompts, multi-turn conversations, extended thinking, tool use including the server tools (web search, web fetch, code execution, MCP connectors, advisor, tool search), and most beta features. Requests of different shapes can be mixed in one batch, since each is processed on its own.

Three parameters are rejected, and each refusal explains something about the mechanism. stream: true fails because results arrive as one file rather than a stream. speed, the fast mode parameter, fails on the grounds that tuning synchronous latency means nothing for asynchronous work. And max_tokens: 0 cache pre-warming fails because an ephemeral cache entry written inside a batch would likely expire before the follow-up request ran.

All active models support the API.

Batch pricing (2026-09-04 snapshot — half of list)

The discount covers input, output and special tokens alike. Note what the retired rows do to the ladder: Opus 4.1 batched still costs more than Fable 5.1 batched, so an old model left running on Bedrock is not the cheap option it looks like.

How the results come back

A batch carries a processing_status of in_progress until every request finishes, then ended. There is no push — you poll, from the Console or the retrieval endpoint. request_counts tallies four outcomes, and you are billed only for the first:

Finished results sit at a results_url as JSONL, one line per request keyed by custom_id. Anthropic recommends streaming them rather than downloading the file whole, which is what a 256 MB submission looks like in practice.

Two seams with the rest of the cost stack

1. Batch limits and Messages-API limits are separate. The Batches API has its own HTTP rate limit plus a cap on requests awaiting processing, and using it does not consume the Messages API's RPM/ITPM/OTPM budget claude-api-rate-limits. So batching is a throughput lever as well as a discount, the same double role prompt caching plays under cache-aware ITPM, and for the same reason: the constrained resource is real-time capacity.
2. Caching stacks with batching, but weakly. Prompt caching works inside a batch, yet because requests run concurrently and in any order, cache hits are best-effort only. Anthropic's own advice is to buy the 1-hour cache duration when batching shared context, which is a paid workaround for a discount — the two levers on the llm-api-pricing list do not simply add.

Reading it

A T1 operational doc from the vendor, and unusually candid about its own edges: it states the expiry risk, the spend-limit overshoot and the best-effort caching instead of selling the 50%. What it does not state is a publication or revision date. Like anthropic-model-docs and claude-api-rate-limits it is a living page, so every number above is a snapshot taken on the ingest date and nothing more.

Related

llm-api-pricing · claude-api-rate-limits · claude-refusals-and-fallback · anthropic-model-docs · anthropic · claude-opus-5 · claude-sonnet-5 · claude-fable-5-1 · llm-provider