Know what the batch discount cannot buy

Learning objective

Explain the 50% batch discount, 24-hour expiration window, lack of a completion-time SLA, and absence of mid-request tool execution in a batch.

Core idea

Message Batches trades immediate response delivery for lower-priced asynchronous processing. Anthropic documents batch usage at 50% of standard API prices. That discount does not buy a promised completion time: a batch can reach its 24-hour expiration with requests still unprocessed.

The execution boundary also matters. Your application cannot answer a client-tool call in the middle of an outstanding batch entry. Anthropic-executed server tools can run inside that entry. Treating all tool use as unsupported would exclude documented batch capabilities; treating all tool use as a self-contained agent would hide work your application still has to perform.

See 4.5.1 for selecting workloads and 4.5.3 for turning these constraints into a delivery plan. Here, the decision is whether the proposed savings assume a capability or guarantee the batch contract does not provide.

How it works

Interpret the discount at the request level

The batch-processing documentation states that usage is charged at half the standard API price, including input and output tokens. If eligible standard token usage would cost 100 cost units, the corresponding batch usage costs 50. This is a pricing comparison, not a claim that a complete business workflow always costs half as much. Prompt-caching discounts can stack with the batch discount, but cache hits in batches are best-effort; shared prefixes marked with cache_control do not guarantee a hit.

A successful but unusable answer can require another generation. That additional request consumes additional usage even if the first request had result.type: "succeeded". The batch result describes execution success; it does not certify that the response satisfies your review or extraction criteria. Prompt refinement and sample evaluation reduce that avoidable work; see 4.5.5.

The documentation separately states that errored, canceled, and expired entries are not billed. Keep that distinction when estimating recovery. Resubmitting an unprocessed expired entry differs from regenerating an answer that already succeeded. Replaying an entire batch after a few failures repeats successful work unnecessarily; see 4.5.4.

Read 24 hours as expiration

A batch exposes created_at and expires_at. Processing may end before expiration, but remaining work can expire if the batch does not finish within 24 hours. An entry with result.type: "expired" did not reach the model before the expiration boundary.

That is different from a completion-time service-level agreement (SLA). Anthropic reports that most batches complete within one hour, but that is a typical observation, not a completion promise: a batch can still expire at 24 hours with work unprocessed. Do not turn typical processing time into a promise that every entry produces a message within a day.

The batch’s processing_status: "ended" says the batch has reached its terminal processing state. It does not mean every entry succeeded. Inspect request_counts and the individual results to distinguish successful, errored, canceled, and expired entries. A report can therefore have a finished batch and still lack required findings.

Polling only observes these states. It cannot reserve an earlier processing slot or convert expired work into successful output. A deadline-sensitive workflow needs a delivery policy that handles missing results, not merely a faster status-check loop.

Distinguish client tools from server tools

Client tools run in your application. Claude returns tool_use content and stop_reason: "tool_use"; your code executes the requested operation and supplies a tool_result in a subsequent request. A batch entry does not keep an interactive connection open for that application-controlled round trip.

You can retrieve the entry’s message, execute the client tool, and submit a follow-up message request containing its result. That follow-up is a separate request, either synchronous or batched. It is not execution injected into the original batch entry. The orchestration must account for another processing stage before it has a final answer.

Server tools run on Anthropic’s infrastructure. The batch documentation explicitly supports all server tools and describes a server-side agentic loop. Their execution does not require your application to send client tool_result blocks during the entry. This is why “batch requests cannot use tools” is too broad.

A server-tool turn can still return stop_reason: "pause_turn". The documented continuation is to append the paused assistant content to messages and submit a follow-up request. Even server-side execution does not justify assuming that every returned message finishes the business task. Inspect the message’s stop reason as well as the batch result type.

A client tool’s result travels in a separate request, while a server tool’s loop runs inside the batch entry.

Key distinctions and trade-offs

The contract separates four questions:

Supplying existing multi-turn conversation history in params.messages is also different from executing an interactive client-tool exchange inside one batch request. Batches support conversation inputs. That support means the history is accepted as input, not that the batch invites your application into the middle of execution.

The economic advantage is strongest when each entry can produce useful output from its supplied context and supported server-side work. Every necessary follow-up adds another stage whose timing and cost belong in the workflow estimate.

Architecture / decision scenario

A weekly research service proposes batching document analyses. Its estimate assumes half-price token usage, publication exactly 24 hours after submission, and a private client tool that retrieves missing source documents during analysis.

Accept the pricing basis for equivalent usage, but revise the delivery assumption. Record expires_at, inspect terminal results, and allocate recovery as described in 4.5.3. A batch that ends with expired entries has not delivered every analysis.

For the private retrieval tool, fetch the required documents before submission or orchestrate a separate follow-up after receiving tool_use. Do not expect the original entry to pause for your application’s response. If the design instead uses an Anthropic server tool, the batch can execute its supported server-side loop. The consumer must still recognize pause_turn and continue when necessary.

Finally, include quality reruns in the estimate. Half-price generation remains useful, but neither the discount nor a succeeded entry proves that the report is complete and fit to publish.

Common exam traps

• Treating 24 hours as guaranteed successful completion.
• Treating ended as evidence that every request succeeded.
• Pricing a workflow as exactly half-cost while ignoring repeated successful generations.
• Assuming that providing tools makes application code execute inside a batch entry.
• Rejecting server tools because client-tool round trips need separate requests.
• Confusing supplied conversation history with live interaction during processing.

Where the exam guide differs

What to remember

Batch usage receives a 50% discount, while the 24-hour window ends in expiration for unprocessed entries rather than guaranteed answers. Separate the batch state, each entry’s result, and the message’s stop reason. Client tools require application-controlled follow-up requests; server tools can execute within the batch’s server-side loop.

Knowledge check

References

• Anthropic, Batch processing
• Anthropic, Tool use overview
• Anthropic, Server tools
• Anthropic, Claude Certified Architect – Foundations Exam Guide