Chapter 07
Message Batches API
Half price, a 24-hour ceiling that is not an SLA, and no tool loops. Plus surgical recovery via custom_id.
7.1
Four facts, and they decide every question
Asynchronous processing of many independent requests, at half price, with no latency promise.
50% cheaperversus the same requests sent synchronously
up to 24 hoursa processing window, not an SLA — no latency guarantee inside it
no multi-turn toolsone request → one response. A tool-use loop cannot run here
custom_idyour own key on each request, echoed on each result
7.2
Batch or synchronous
One question decides it: is somebody waiting for this right now?
| task | api | why |
|---|---|---|
| pre-merge PR check | synchronous | the developer is blocked; 24 hours is absurd |
| interactive code review | synchronous | immediate response required |
| overnight tech-debt report | batch | needed by morning, and half the cost |
| weekly security audit | batch | not urgent, runs on a schedule |
| 10,000 documents | batch | bulk work — the saving is the point |
7.3–7.4
custom_id earns its keep on failure
Partial failure is the normal case at volume. The id is what makes recovery surgical.
7.5
Work backwards from the deadline
The 24-hour window is a ceiling you must subtract, not an estimate you can hope beats itself.
Recall in 60 seconds
- Batch = 50% cheaper, up to 24h window, no latency SLA.
- One request → one response. Multi-turn tool calling is not supported in batches.
- Anything a human is waiting on stays synchronous — pre-merge checks, interactive review.
- Overnight reports, scheduled audits and bulk document runs are what batch is for.
custom_idlinks each result to its source document.- On partial failure, identify by
custom_idand resubmit only the failures. - Fix the cause before resubmitting — e.g. chunk documents that blew the context limit.
- Submission cut-off = deadline − 24h. Never plan on finishing early.