Reserve recovery time before promising delivery

Learning objective

Plan batch submission cadence, expiry-risk buffers, and fallback paths against delivery targets without treating the 24-hour expiration window as a completion-time guarantee.

Core idea

A delivery clock begins when the work arrives, not when Anthropic accepts the next batch. A request that arrives just after a scheduled submission waits nearly a full submission interval before batch processing even begins. Your plan must also include detecting completion, reading results, recovering missing work, and publishing the usable output.

The 24-hour expiration window bounds the batch’s processing opportunity; it does not guarantee successful results for all entries. Use it to expose scheduling risk and reserve recovery capacity. Do not use it as a proof that a delivery service-level agreement (SLA) is satisfied.

See 4.5.2 for the batch contract. This lesson applies that contract to a delivery plan, while 4.5.4 owns per-entry recovery decisions.

How it works

Start with arrival-to-delivery arithmetic

Suppose merged code changes require test-gap analysis within 30 hours of arrival. A batch scheduler groups pending changes at a fixed interval. For a change that arrives immediately after a submission, the accumulation delay approaches that full interval.

Use the following planning expression to see how much room remains:

submission interval
+ batch processing allowance
+ completion detection and result handling
+ recovery and publication allowance
<= delivery target

This is application planning arithmetic, not an Anthropic completion guarantee. The processing allowance can be the full 24-hour expiration window, but some work may still need recovery when that allowance ends. A plan that budgets 24 hours and leaves no recovery time has explicitly accepted the risk of missing output at expiration.

For the 30-hour target, these intervals produce different reserves before other application work:

The four-hour cadence leaves two hours for detection, retrieval, validation, recovery, and publication. It does not establish that those tasks fit, or that expired requests can all be recovered in that time. Measure the fallback workload and decide whether that reserve is credible before making a promise.

Observe the actual batch clock

Retain the batch id, created_at, and expires_at from submission. Use the returned timestamps rather than confusing an application’s accumulation window with the service’s processing window. They answer different questions: how long the job has existed and when this batch’s unprocessed entries expire.

Call GET /v1/messages/batches/{message_batch_id} to inspect processing_status and request_counts. The batch moves from in_progress to ended when processing has ended and results are ready. Counts let the application see the processing and terminal categories, but they do not replace the individual results needed to identify missing work.

Polling cadence belongs in the delivery calculation. If an application polls every 15 minutes, it may spend almost another 15 minutes noticing completion. That is an illustrative application setting, not an API requirement. Faster polling can reduce that observation delay, but cannot accelerate processing. Choose it against the available reserve rather than expecting it to repair a late submission schedule.

Download and process results promptly after completion. The documented result-availability period is 29 days after batch creation, not an extension of the delivery target. Long retention can help operational recovery; it does not make a report delivered on time.

Set a fallback cutoff before time runs out

An application can choose a cutoff earlier than expires_at if waiting longer would consume the time needed for recovery. Name the remaining path explicitly: a synchronous POST /v1/messages request for required missing analyses, another batch when the consumer tolerates more delay, or an incomplete-delivery outcome when the target cannot be met.

Another batch gives missing work a separate deferred-processing stage. It is therefore inappropriate to assume that rebatching at hour 28 rescues a 30-hour hard deadline. Use a synchronous path only if its measured workload, available capacity, and result handling fit the remaining budget. Synchronous execution is a mode choice, not a guaranteed fallback completion time.

If you cancel a still-running batch, use POST /v1/messages/batches/{message_batch_id}/cancel. Cancellation first sets processing_status: "canceling"; it is not immediate completion. Continue observing until ended and retrieve the partial results. Some entries may have completed before cancellation, so do not treat cancellation as proof that every entry needs regeneration.

A deadline-driven fallback can overlap with processing that has not yet settled. The application must reconcile the eventual batch results before counting work as delivered. See 4.5.4 for identifying results by custom_id. The cutoff and publication decision are application policies; the batch API supplies state and outcomes rather than a delivery-target setting.

Key distinctions and trade-offs

A shorter submission interval reduces accumulation delay. It does not shorten an individual batch’s expiration window or reserve a processing completion time. A longer interval can collect more work at once while consuming more of the consumer’s deadline before submission.

A buffer also needs a purpose. Reserve time for observing the terminal state, retrieving and validating output, and recovering required missing items. Calling two hours a buffer without accounting for those activities hides the same risk as omitting the buffer entirely.

Hard and flexible delivery targets lead to different responses. A flexible report can publish later or label incomplete coverage. A hard gate needs a credible required-output path and an explicit failure outcome if that path cannot finish. Neither target is fulfilled merely because the batch has ended.

Architecture / decision scenario

A nightly review service promises analysis within 30 hours of each merge. Daily submission fails the arithmetic before recovery is considered. Every six hours uses the entire target on accumulation plus the batch window. The architect selects four-hour submissions as a starting point, leaving two hours after the full processing allowance.

The scheduler stores expires_at and polls the batch by id. Operational measurements show that the service needs time to download results, validate findings, and run synchronous recovery for a bounded set of missing analyses. It sets a fallback cutoff early enough to preserve that measured allowance, rather than waiting reflexively for expiration.

At the cutoff, it inspects state and decides whether to keep waiting or initiate the recovery path. If it cancels, it waits for cancellation to settle and reconciles partial successes. Required analyses that still cannot finish produce the service’s explicit missed-target outcome; the system does not mark the job complete because 24 hours elapsed.

The four-hour cadence is thus one component of the plan. The deadline claim depends on the complete arrival, execution, recovery, and publication design.

Common exam traps

• Starting the delivery clock at batch submission instead of work arrival.
• Using typical processing time to justify a firm target.
• Calling four-hour submissions a guarantee for a 30-hour SLA.
• Leaving no time to detect completion or recover expired entries.
• Treating another batch as an immediate fallback near a deadline.
• Assuming cancellation is immediate or discards every partial success.

Where the exam guide differs

What to remember

Budget from arrival to usable delivery. Submission interval plus the expiration window reveals how much reserve remains, not whether every analysis will succeed. Observe expires_at, define a measured fallback cutoff, and account for partial results and recovery before promising a deadline.

Knowledge check

References

• Anthropic, Batch processing
• Anthropic, Create a Message Batch
• Anthropic, Claude Certified Architect – Foundations Exam Guide