Lesson 4.5Lesson 23 of 30
Batch processing strategies
Design efficient batch processing strategies
Key points
- 1The Message Batches API costs 50% less than synchronous calls, but a batch may take up to 24 hours and has no latency guarantee. Most batches finish sooner; never design around "usually".
- 2Batch fits work nobody waits on: overnight reports, weekly audits, nightly test generation. A pre-merge check a developer is blocked on stays on the synchronous API.
- 3One batch request is one Messages call: no multi-turn tool calling inside it. If Claude answers with
tool_use, nobody runs the tool. Put the needed data in the prompt, or keep the tool loop synchronous. - 4Results can come back in any order: join them by
custom_id(a stable document id), never by position. Resubmit only the failedcustom_ids, fixed first (chunk documents that were too long); re-send expired ones as is. - 5Derive submission frequency from the SLA: 30 h SLA − 24 h worst-case batch − 2 h post-processing = submit every 4 h. Before a large batch, refine the prompt on a representative sample to maximise first-pass success.
What the exam guide checks here
Objective wording from the exam guide (English).
- 4.5.K1Message Batches API: 50% cheaper, up to 24 h, no latency SLA
- 4.5.K2Batch for latency-tolerant work, not blocking pre-merge checks
- 4.5.K3Batch does not support multi-turn tool calling inside one request
- 4.5.K4custom_id correlates requests and responses
- 4.5.S1Synchronous API for blocking checks, batch for overnight/weekly
- 4.5.S2Compute submission frequency from SLA (4 h windows for 30 h SLA with 24 h batch)
- 4.5.S3Resubmit only failed items by custom_id, with fixes (chunk oversized documents)
- 4.5.S4Refine prompts on a sample before large batches
Lock it in
Answer scenario questions on this topic. Every option comes with an explanation.
Practise 4.5 · 21 questions