Message Batches API: limits, results and custom_id

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. You submit a batch job, and your worker process must wait until every request in it has finished before downloading results. Your worker breaks out of that wait when processing_status reads succeeded. Every request has finished, but the download step after the wait has not run. What is the most likely root cause?

   Right. In the game that’s Renown for your Context Management and Reliability building.

   Not that one: D is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.

   Your answerA.Rate limiting on the retrieve call leaves the status your loop reads stale, so the condition it breaks on is never true while the polling continues.Rate limits surface as HTTP 429 responses, not as stale data: a throttled poll fails outright and the next successful one reads the live status. Slowing the loop down would not help, because the value being compared against is not one the batch ever reports.Your answerB.The batch expired before the last of its requests could be sent, so results cover only part of the work and succeeded is reported for none of it.expired covers a batch that reached its 24-hour expiration before its requests could be sent, and the stem has the batch finishing inside the hour with every result present. Expiry would also change which results exist, not which status string the batch reports.Your answerC.Results are written to the file a little before the batch's processing status is updated, so your worker reads the previous value and misses succeeded as it passes.There is no window in which the batch object shows a stale terminal state: processing_status moves to ended and stays there, and a poll after that point reads ended every time. No ordering of writes makes succeeded appear at the batch level.The answerD.succeeded is a per-request result value, so the condition it breaks on is never true; the processing status that indicates a complete batch job is ended.A batch is finished when retrieve(id).processing_status reads ended. That value says only that processing has stopped, whatever the individual outcomes were; each result then carries its own result.type of succeeded, errored, canceled or expired.

   Show the full explanation and doc quotes

   A worker comparing processing_status against a per-result value is comparing against a string the batch object never emits, so the loop's exit condition cannot become true however long it waits.

   Written from platform.claude.com/docs/en/build-with-claude/batch-processing

2. You submit a Message Batch of 50,000 requests, and POST /v1/messages/batches returns 200 with processing_status: "in_progress". Every entry carries the fields your builder wrote into it, so a single malformed field in that builder's template would repeat across every entry. Your team wants such a mistake surfaced as early as it can be, and nobody is sure at what point an entry's shape is checked. Which approach should you take?

   Right. In the game that’s Renown for your Context Management and Reliability building.

   Not that one: A is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.

   The answerA.Send one sample request to the Messages API and verify it first, since each entry's params is validated asynchronously and an invalid_request_error reaches you only in the results file hours later.Validation of the `params` object for each message request is performed asynchronously, and validation errors are returned when processing of the entire batch has ended. A batch therefore accepts malformed entries at creation and reports each one later with `result.type: "errored"Your answerB.Send one sample request to the Messages API batch-creation endpoint on its own, and verify it first, since a malformed entry would be reported in the create response it hands straight back to your builder.A single-entry batch is validated on exactly the same schedule as a fifty-thousand-entry one. The create response comes back with every request counted under processing and nothing about the shape of params checked, so the round trip tells you nothing until the batch has ended.Your answerC.Read the request counts carried on the create response, since a malformed entry is reported there as each entry of the file is accepted into the batch for processing.request_counts is a real field on the batch object, but the create response does not populate it with failures — every request sits under processing, and no entry's params has been inspected at that point.Your answerD.Watch the console view while the batch is created, since a malformed entry is reported there rather than in the results file written at the end.The results file is precisely where per-request errors are delivered, alongside each entry's custom_id, so this sends the team away from the one artefact that carries the diagnosis.

   Show the full explanation and doc quotes

   `. The documented way to see a bad request shape immediately is to send it to the Messages API on its own, where validation is synchronous, before committing copies of it to a batch.

   Written from platform.claude.com/docs/en/build-with-claude/batch-processing

3. Your nightly classification job submits 40,000 requests through the Message Batches API and writes each result to the database row at the same index as the request it submitted. Spot checks show classifications attached to the wrong records, and a subset of rows carry no result at all even though the batch reached processing_status of "ended". What change would most effectively resolve this issue?

   Right. In the game that’s Renown for your Context Management and Reliability building.

   Not that one: C is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.

   Your answerA.Poll processing_status until it reports "succeeded" rather than "ended", so partial result sets are never read.ended is the terminal processing_status for a batch; there is no succeeded status at the batch level. Success and failure are reported per request through result.type, which takes the values succeeded, errored, canceled and expired.Your answerB.Split the work into batches below the 100,000-request maximum so result ordering is preserved within each batch.The maximum of 100,000 requests per batch is a size limit, not an ordering guarantee. Results arrive in any order regardless of how small the batch is, so splitting the work leaves the positional join just as fragile.The answerC.Set a unique custom_id on every request and join results back to records by custom_id, branching on each result's result.type.Batch results are returned in arbitrary order, so positional joins are unsafe by construction. Each request carries a custom_id and each result echoes it, which is the only correct join key.Your answerD.Re-submit the batch with results streamed in a single pass, since re-reading the results endpoint reorders them each time.The results endpoint is not shuffling anything between reads — order is simply not part of the contract. Re-submitting the same job with the same positional assumption reproduces the same misalignment.

   Show the full explanation and doc quotes

   Rows with no result correspond to entries whose result.type is errored, canceled or expired, which the loop must branch on rather than assume success.

   Written from platform.claude.com/docs/en/build-with-claude/batch-processing