The nightly job that pays for itself
Picture a ticket-classification pipeline: 40 million input tokens and 2 million output tokens a night, run once, and nobody looks at the output until the 7am dashboard refresh. Nothing in that job needs a response in under a second. It needs a response before breakfast.
Price that job on gemini-3-6-flash and you get the standard-tier number. Price the identical token count on gemini-3-6-flash-batch and you get a smaller one. As of this writing the gap sits in the range most providers settle on for batch tiers, roughly half off, though that’s an illustrative estimate and the live page is the only place that number won’t be stale by the time you check it. For this job the discount is close to free money: the batch queue’s completion window is measured in hours, your natural cadence already has hours to spare, and no product-facing clock is racing against you.
That’s the easy case. Most workloads aren’t this clean.
Where the same discount buys less
Run the equivalent comparison on gemini-3-5-flash-lite-batch against its standard sibling and the percentage discount looks similar. The absolute dollars it recovers don’t. Flash-Lite’s standard rate is already a fraction of Flash’s, so the same percentage cut off a smaller base returns fewer dollars per million tokens processed, not fewer percentage points.
This matters because building the batch path isn’t free. You need a submission queue, a poller or webhook handler, retry logic for the fraction of requests that error out mid-batch, and a dead-letter path for the ones that never come back. That’s fixed engineering cost regardless of which SKU sits behind it. On Flash, a modest volume recovers that cost in weeks. On Flash-Lite, the same volume might take a quarter, because the per-million-token savings is smaller even though the percentage is the same. Teams that assume “batch discount = batch discount” and roll it out identically across both tiers end up maintaining a second pipeline for Flash-Lite traffic that never pays back before the next model swap makes the whole thing moot.
The trap: batch doesn’t know your SLA
The common advice is “route anything non-interactive to batch.” That’s right for the nightly job and wrong for a lot of traffic that looks non-interactive but isn’t. Support-ticket triage that routes to a live agent queue in under a few seconds can’t use batch at any volume, because batch mode gives you no per-request latency guarantee. It gives you a completion target, commonly a window measured in hours, and you’re billed the discounted rate whether your particular request lands in five minutes or five hours.
The window is a target, not a contract, and that’s what bites teams who build the pipeline anyway and assume it’s a hard ceiling. I’ve watched a batch job queued at 11pm with a same-day target straggle past 30 hours during a provider-side congestion spike, because someone else’s much larger job jumped the queue. If your downstream cron job assumes results by 6am, that straggle turns into a page, a stale dashboard, and an on-call engineer debugging a provider queue they have no visibility into. This guide can’t tell you how often that happens on any given provider this week; queue congestion isn’t published anywhere, and it moves with whoever else is running large jobs on the same capacity. Build slack into your downstream deadline, not just into your job schedule.
The rule
Split your traffic into two buckets before you build anything: tokens that can wait hours, and tokens that can’t. If the deferrable bucket is under roughly a fifth of your monthly spend on a given model, don’t build the second pipeline. The ops overhead of a queue, poller, and dead-letter handler costs more engineer-hours than the discount returns before you swap models again anyway. If the deferrable bucket clears roughly half your spend, build it, and build it against gemini-3-6-flash before gemini-3-5-flash-lite-batch, because Flash’s larger base rate means the same percentage discount recovers your integration cost faster in absolute terms.
Run your actual token counts, both SKUs, both tiers, through the calculator using today’s live rates before you commit engineering time either way. The percentage discount is stable enough to plan around. The absolute dollars it returns depend entirely on which model sits underneath it, and that’s the number the calculator gets right and a spreadsheet from last quarter doesn’t.