A compliance team must classify 60,000 archived emails against a fixed rubric. The job runs once a week, nothing blocks a user while it runs, and the team is told to hold the lowest cost per email that still meets the rubric's accuracy bar. An engineer proposes firing 60,000 concurrent realtime Messages API requests so the job finishes sooner. Which approach best fits the stated constraint?
- AKeep the concurrent realtime requests, because completing the run sooner is what the weekly schedule requires and concurrency is the only way to reach that throughput.
- BSubmit the classifications through the Message Batches API, since the work is latency tolerant and batch processing is the cheaper path for a large offline volume. Correct
- CKeep the realtime requests but reduce max_tokens on each one, so that every classification is billed against a much smaller output allowance.
- DKeep the realtime requests and enable prompt caching on the rubric, because caching a stable prefix removes the need to choose a different request path.
Why A is wrong: Tempting because concurrency really does shorten wall-clock time, but the stated constraint is cost per email and not completion time, and a fan-out of realtime requests is the most expensive way to buy throughput.
Why B is correct: Correct: no user is waiting, the volume is large and uniform, and the Message Batches API exists precisely for asynchronous bulk work at a lower cost per request than realtime calls.
Why C is wrong: Tempting because max_tokens looks like a spend dial, but it is a truncation limit rather than a cost lever: it caps how long a response may run and risks cutting a classification short without changing the request path.
Why D is wrong: Tempting because caching the shared rubric prefix is a genuine cost control and worth doing, but it is complementary to the request path rather than a substitute for it, and it leaves the expensive realtime fan-out in place.