Batch trades latency for a substantial discount. The architectural question is never "is batch cheaper" — it is "can this path tolerate the latency". Build a real batch job with proper result handling.
What to build
- Assemble a few hundred classification requests.
- Give every request a meaningful custom_id that maps back to your record key.
- Submit the batch and poll for completion rather than blocking.
- Retrieve results and join them by custom_id — do not assume input order.
- Handle per-request failures: a batch can partially succeed.
- Before running the full batch, sample twenty and check accuracy synchronously.
- Record the actual cost delta against a synchronous run.
Done when
- Results are joined by custom_id and the join is order-independent.
- Individually failed requests are identified and retried, not silently dropped.
- You validated prompt quality on a sample before spending on the full run.
- You can state the latency ceiling and the result retention window.
If you want to go further
- Combine batch with prompt caching and measure whether the cache survives across the batch.
The trap this exercise teaches
Putting a user-facing request path on batch. The discount is irrelevant if the user is waiting; batch is for work nobody is watching.
Before you start
The theory behind this build is covered in Message Batches: economics and limits. If any step below is unfamiliar, read that first — the exercise assumes it. Primary source: Claude Docs — Message Batches.
Check yourself against the exam
This exercise sits in Domain 3, which is 20% of the CCAR‑F exam. Once you have built it, run a domain drill in the study app and see whether the questions read differently.