What you will be able to do
- State what the Message Batches API trades away for its 50% discount, and why its 24-hour window is not a latency SLA
- Decide whether a workload belongs on the synchronous Messages API or the batch API based on whether something is blocked waiting for it
- Explain why a batch request cannot run a multi-turn client tool loop
- Size batches against the per-batch limits and calculate a submission cadence that guarantees an end-to-end SLA
Key concept
Batch window is an expiry, not an SLA — The Message Batches API halves the price of every token, and in return you give up any promise about when a result arrives. Batches usually finish fast. The only hard number is the 24-hour point where unprocessed requests expire, so you design around that worst case.
1.What the batch contract buys and what it costs
The synchronous Messages API gives you a response while you wait. The Message Batches API works differently. You submit a set of Messages requests, the system processes each one independently and asynchronously, and you collect the results later. In exchange for waiting, all usage is billed at half the standard price. The discount covers input and output tokens alike, and it doesn't depend on which model you use.
| Model | Batch input | Batch output |
|---|---|---|
| Claude Opus 5.5 | $2 / MTok | $10 / MTok |
| Claude Sonnet 5.5 | $1 / MTok | $5 / MTok |
| Claude Haiku 4.5 | $0.50 / MTok | $2.50 / MTok |
Anthropic's cost-optimization cookbook ran ten identical claim-triage requests both ways. Token counts were essentially the same, but the synchronous run cost $0.7379 and the batched run cost $0.3653, which is half. Nothing about the request changed. Only the delivery contract did.
The timing rules are easy to misread. The docs describe typical speed: most batches finish within an hour. Results become available when every request has completed or when 24 hours have passed, whichever comes first. Any request that hasn't been processed by then expires. The docs also say processing can slow down depending on current demand and your request volume, and when that happens more requests may expire at the 24-hour mark. So the typical hour is an observation, not a promise, and 24 hours is a cutoff, not a guarantee of delivery. There is no latency SLA.
Checkpoint 1 of 8· Check yourself
A team lead says: "The Batches API has a 24-hour SLA, so anything we submit is guaranteed to come back processed within a day." What is wrong with this?
The 24-hour figure is an expiry boundary. Requests not processed by then come back as expired and are not billed, but they also produce no output.
“Batch reached its 24-hour expiration before this request could be sent to the model. You will not be billed for these requests.”Source: platform.claude.com
The contract has one more cost: the batch API does not support multi-turn tool calling within a single request. With a client tool, Claude returns a tool_use block, your code runs the tool, and a second request carries the tool_result back so Claude can finish. A batched request cannot execute a tool mid-request and return the result to the model, because each request is processed independently and returns one result, with no point where your code can step in. The cookbook puts it plainly: batch requests are single-shot, with no mid-batch tool loop. A batched request that ends in a client tool_use is final, and continuing it means building a new request yourself. Work that needs this loop belongs on the synchronous API.
2.Matching the API to the workflow's latency needs
Because the batch contract has no latency guarantee, choosing between APIs comes down to one question: is anything blocked until this result comes back? The docs recommend batching for work where immediate responses aren't needed, such as large-scale evaluations, content moderation, data analysis over big datasets, and bulk content generation. The cost cookbook gives the same advice and points to nightly evals and data exploration as natural fits.
| Workflow | Is someone or something waiting? | API |
|---|---|---|
| Pre-merge check that gates a pull request | Yes, the merge is blocked | Synchronous Messages API |
| User-facing feature | Yes, the user is waiting | Synchronous Messages API |
| Overnight report or weekly audit | No, it is read the next day or later | Message Batches API |
| Nightly test or eval generation | No, it is reviewed the next morning | Message Batches API |
A pre-merge check is the standard counterexample. A developer can't merge until the check reports, so a job that might take hours, or expire, would stall the pipeline, and the 50% saving doesn't make up for that. A weekly audit is the opposite case. Nobody reads it the moment it's produced, so it can absorb the batch API's unpredictable timing and still collect the discount. Volume is not the test. A small nightly job still belongs on batch, and a large blocking job still belongs on the synchronous API.
Checkpoint 2 of 8· Exam question
A platform team runs an automated code-review gate that blocks a pull request from merging until Claude returns a verdict on the diff, typically within a few seconds. Which approach should they use for this workflow?
Correct answer: A — The synchronous Messages API, since the merge gate blocks on an immediate response and the Message Batches API offers no guaranteed latency SLA
- A. Correct. Pre-merge checks block on a fast response, and the Batches API has no guaranteed turnaround time (it can take up to 24 hours), so the synchronous API is required.
- B. Incorrect. The Batches API has no SLA guaranteeing a few-second turnaround; individual requests can sit for hours during periods of high demand.
- C. Incorrect. A blocking merge gate cannot tolerate an unbounded wait; the cost savings do not offset stalling every pull request pipeline.
- D. Incorrect. Batch requests carry no latency guarantee at all, so treating typical fast completion as reliable for a blocking gate is unsafe.
Checkpoint 3 of 8· Check yourself
A team runs Claude-based security review on every pull request, and merges are blocked until the review posts. They also produce a weekly codebase-wide audit report. What API split fits best?
The pre-merge review blocks developers, so it needs synchronous responses. The weekly audit is latency-tolerant and gets the batch discount.
“Reach for the Batch API for anything that's not time-sensitive, like nightly evals or data exploration.”Source: platform.claude.com
3.Each batch request is single-shot: no client tool loop
Almost any Messages request can go into a batch. That includes vision, system prompts, multi-turn conversation history, extended thinking, and tool definitions. Server tools such as web search and code execution run on Anthropic's side, so they are supported as well. The limitation is in how a client tool works. When Claude calls a tool you host, the response contains a tool_use block. Your code then runs the tool and sends a second request with a tool_result block.
In synchronous code, your program sits between those two requests. In a batch it can't. Each request is processed by itself and returns one result, and nothing in the request can call back to your code to run a tool and continue. If a batched request ends in a client tool_use, that result is final. Continuing would mean building a new request yourself. The cost cookbook describes batch requests as single-shot, which is why it uses the batch only for a one-pass classification step and keeps the multi-turn agent on the synchronous path.
Checkpoint 4 of 8· Check yourself
An engineer wants to batch 5,000 tasks where Claude must call an internal get_customer_record tool, read the result, and then write a summary, all inside each request. Why won't this work as planned?
Tool definitions are accepted, but the client tool round trip needs your code to run between two requests. A batch request is single-shot, so the loop can't finish inside it.
“Batch requests are single-shot (no mid-batch tool loop)”Source: platform.claude.com
4.Per-batch limits and splitting large jobs
A single batch is capped by request count and by payload size, and whichever limit you hit first applies. A nightly job with more requests than the cap has to go out as several batches. That is also the docs' general advice for very large datasets, since smaller batches are easier to manage. Payload size matters when requests carry documents or images. Base64-encoded PDFs fill up the size limit long before you reach the request-count limit, and an oversized submission can be rejected with a 413 request_too_large error.
Checkpoint 5 of 8· Check yourself
A pipeline must submit 230,000 short classification requests (about 40 MB total) each night. What is the minimum number of batches?
The payload is well under 256 MB, so the 100,000-request cap is the binding limit. 230,000 requests need at least 3 batches.
“A Message Batch is limited to either 100,000 Message requests or 256 MB in size, whichever is reached first.”Source: platform.claude.com
Checkpoint 6 of 8· Exam question
A compliance group reviews 15,000 vendor contracts once a week and publishes a findings report two business days later. Cost per document matters because the review runs across the entire vendor catalog every cycle. How should this recurring job be built?
Correct answer: A — Submit the contracts as a single Message Batch each week, since the two-day turnaround comfortably absorbs the batch processing window and the discount lowers per-cycle spend
- A. Correct. A weekly, non-blocking audit with a multi-day turnaround tolerates the batch processing window comfortably while capturing the 50% cost reduction across the full catalog.
- B. Incorrect. Parallel synchronous calls bypass the batch discount entirely and add operational complexity without a latency requirement that demands it.
- C. Incorrect. A single batch can hold up to 100,000 requests, so fragmenting 15,000 contracts into many small submissions adds overhead for no benefit.
- D. Incorrect. Result ordering is not guaranteed by either API in a way that requires sequential calls; documents are correlated by custom_id, not by submission order.
Sources1
5.Calculating submission cadence from an SLA
Suppose items arrive all the time but you only submit a batch every few hours. A business SLA like "every document gets a result within N hours of arrival" then depends on two waits added together. First, an item waits until the next submission. Second, the batch it joins can take up to 24 hours. The worst case is an item that arrives just after a submission. It waits a full interval, and then its batch runs to the 24-hour limit.
So worst-case latency = submission interval + 24 hours, and the longest interval you could use is SLA − 24 hours. In the exam guide's example of a 30-hour SLA, that ceiling is 6 hours. But a 6-hour cycle leaves no time to download results, find failures, or resubmit requests that errored or expired. A 4-hour cycle puts the worst case at 28 hours and keeps a 2-hour buffer for that work. Plan your cadence below the ceiling, not at it.
Checkpoint 7 of 8· Check yourself
A pipeline must guarantee results within 36 hours of a document arriving, using the Message Batches API. Before allowing any margin for retrieval or retries, what is the longest submission interval that still meets the SLA in the worst case?
Worst case is one full interval of waiting plus 24 hours of processing, so the interval can be at most 36 − 24 = 12 hours. In practice you would choose something shorter to leave room for resubmission.
“Once a Message Batch is created, it begins processing immediately. Batches can take up to 24 hours to complete.”Source: platform.claude.com
Checkpoint 8 of 8· Exam question
A support team is building a live chat assistant that must answer customers while they are actively typing in a conversation. An engineer proposes routing every chat turn through the Message Batches API to cut token costs. What is the most accurate assessment of this proposal?
Correct answer: A — It is unsuitable, because live chat needs an immediate response and the Batches API offers no guaranteed turnaround, so answers could arrive far too late
- A. Correct. Live chat is a blocking, latency-sensitive workflow; the Batches API can take up to 24 hours with no SLA, making it incompatible with real-time conversation.
- B. Incorrect. While individual batch requests can finish quickly under light load, there is no guarantee of this, and demand spikes can push completion out for hours.
- C. Incorrect. Chat users tolerate seconds of delay, not the unbounded, unpredictable wait the Batches API allows for.
- D. Incorrect. The Batches API is priced at a 50% discount versus standard rates, not a premium; the mismatch here is about latency, not cost.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The batch API guarantees processing within 24 hours, and usually within 1 hour, so it can back deadline-bound work.Why is that wrong?
Most batches do finish quickly, but 24 hours is an expiry. Unprocessed requests come back as expired, so deadline-bound or user-facing work belongs on the synchronous API.
2.Because tool use is supported in batches, an agent that calls your own tools and reacts to their results can run entirely inside one batched request.Why is that wrong?
Tool definitions are accepted, but a client tool needs your code to run it and send the result back in a second request. Batch requests are single-shot, so that loop can't happen inside them.
Covered in Each batch request is single-shot: no client tool loop
3.With a 30-hour SLA and a 24-hour window, submitting every 6 hours is the right cadence.Why is that wrong?
6 hours is the zero-margin ceiling. The worst case is a full interval plus 24 hours, and you still need time to resubmit failures, so the cadence should be shorter, as in the 4-hour example.
Covered in Calculating submission cadence from an SLA
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“All usage is charged at 50% of the standard API prices.”
↩︎ What the batch contract buys and what it costs“You can access batch results when all messages have completed or after 24 hours, whichever comes first.”
↩︎ What the batch contract buys and what it costs“processing may be slowed down based on current demand and your request volume. In that case, you may see more requests expiring after 24 hours.”
↩︎ What the batch contract buys and what it costs“This approach is well-suited to tasks that do not require immediate responses”
↩︎ Matching the API to the workflow's latency needs“Tool use, including all server tools (web search, web fetch, code execution, MCP connectors, advisor, and tool search)”
↩︎ Each batch request is single-shot: no client tool loop“A Message Batch is limited to either 100,000 Message requests or 256 MB in size, whichever is reached first.”
↩︎ Per-batch limits and splitting large jobs“Consider breaking very large datasets into multiple batches for better manageability.”
↩︎ Per-batch limits and splitting large jobs“If the request size is too large, you may get a 413 request_too_large error.”
↩︎ Per-batch limits and splitting large jobs“Batches expire if processing does not complete within 24 hours.”
↩︎ Calculating submission cadence from an SLA“Batches expire if processing does not complete within 24 hours.”
↩︎ Exam trap 3“Batches expire if processing does not complete within 24 hours.”
↩︎ Prediction“Batch reached its 24-hour expiration before this request could be sent to the model. You will not be billed for these requests.”
↩︎ Checkpoint - 2.
“Once the batched responses are returned, notice how the token columns match but the cost per task is 50% less.”
↩︎ What the batch contract buys and what it costs“Batch requests are single-shot (no mid-batch tool loop)”
↩︎ What the batch contract buys and what it costs“Reach for the Batch API for anything that's not time-sensitive, like nightly evals or data exploration.”
↩︎ Matching the API to the workflow's latency needs“Batch requests are single-shot (no mid-batch tool loop)”
↩︎ Each batch request is single-shot: no client tool loop“that window is an expiry, not an SLA, so keep anything user-facing or deadline-bound on the synchronous path.”
↩︎ Key concept“that window is an expiry, not an SLA, so keep anything user-facing or deadline-bound on the synchronous path.”
↩︎ Exam trap 1 - 3.
“your code runs the lookup, and a second request sends the result back in a tool_result block so Claude can reply with the answer.”
↩︎ What the batch contract buys and what it costs“your code runs the lookup, and a second request sends the result back in a tool_result block so Claude can reply with the answer.”
↩︎ Each batch request is single-shot: no client tool loop“your code runs the lookup, and a second request sends the result back in a tool_result block so Claude can reply with the answer.”
↩︎ Exam trap 2 - 4.
“Once a Message Batch is created, it begins processing immediately. Batches can take up to 24 hours to complete.”
↩︎ Calculating submission cadence from an SLA