Batch vs realtime calculator

The trade in one sentence

The Message Batches API runs at a significant discount off the standard per-token price, in exchange for results that typically land within an hour and are guaranteed within a fixed maximum window rather than arriving synchronously. That's an easy trade to accept for work nobody is waiting on and a bad one to accept by accident for work somebody is — the calculator below exists because "is this batchable" and "is this worth batching" are two different questions, and teams often only ask the first one.

What actually qualifies as batchable

Not every high-volume workload is a good batch candidate just because it's high-volume. The workloads that benefit most share a specific shape: large enough in total request count that the discount adds up to real money, and genuinely asynchronous, meaning nothing downstream is blocked waiting on any individual result. Nightly summarisation, bulk classification runs, large-scale evaluation passes, and backfilling historical data against a new model all fit that shape well. A support chat reply does not, no matter how large the volume gets, because the person on the other end of it is waiting in real time.

Where the discount stops being worth it

Enter your request volume and your actual deadline — not an aspirational one, the one you'd genuinely miss if results took the maximum allowed time rather than the typical one — and this tool tells you whether batching clears that bar and roughly what it's worth over a month at your volume. At low volume, the discount is real but small in absolute terms, and the operational cost of building and monitoring a separate batch pipeline can outweigh it; this tool's output is deliberately the money saved, not a verdict on whether that amount is worth the engineering effort for your team specifically.

A deadline is not the same as "fast enough on average"

The typical completion time and the maximum completion time for a batch are not the same number, and planning against the typical one is the most common way teams get burned by batching. If a result landing at the slow end of the window would actually break something downstream — a report due at a fixed time, a pipeline stage that can't sit idle indefinitely — size your deadline against the maximum, not the average, or batch only the portion of the workload that has real slack.

What doesn't need this calculator at all

If your volume is small enough that the batch discount amounts to a trivial sum regardless of deadline, real-time is almost always the simpler and correct choice — the discount has to be worth the added complexity of a separate submission and polling flow, and at low volume it usually isn't. Where the numbers say the discount is real, see the reference page on the Batch API for the mechanics of building the actual request.