Moving to the Batch Tier Cancels Out the Gemini 3.7 Flash Price Increase Exactly

Moving to the Batch tier cancels the increase exactly

Alongside Standard, the pricing page lists Batch and Flex tiers. For 3.7 Flash, both are half of Standard.

Now compare the 2027 Batch figures with the 2026 Standard figures. $0.75 and $0.75. $3.75 and $3.75. They match exactly.

If you move work that runs on Standard today onto the Batch tier, the January increase is cancelled out. Input and output move by the same factor and Batch is consistently half, so the match does not depend on your token mix. It holds for input-heavy classification and for output-heavy generation alike.

Put differently: reducing usage is not your only lever against the increase. You can trade latency for a flat bill. Batch does not return immediately, so this trade is only available for work that can wait — and more of your work can wait than you probably think.

I have covered how to submit batch jobs in Gemini Batch Processing API: Process Thousands of Requests at 50% Off, so I will leave the mechanics there. What I want to establish here is the relationship: that fifty percent is exactly enough to hold your current bill.

Check it against your own usage

Ratios do not become real until you put your own numbers into them. A small estimator that holds the price table saves you from recalculating by hand every time you change a model or a tier.

"""Project what the 2027-01-01 price change does to your workload.
Rates as published on the Gemini Developer API pricing page, 2026-08-16 (USD per 1M tokens).
"""
from dataclasses import dataclass
 
 
@dataclass(frozen=True)
class Rate:
    inp: float
    out: float
 
 
# (model, tier) -> (rate through 2026, rate from 2027)
PRICES = {
    ("gemini-3.7-flash", "standard"): (Rate(0.75, 3.75), Rate(1.50, 7.50)),
    ("gemini-3.7-flash", "batch"): (Rate(0.375, 1.875), Rate(0.75, 3.75)),
    ("gemini-3.6-flash", "standard"): (Rate(0.75, 3.75), Rate(1.50, 7.50)),
    ("gemini-3.5-flash", "standard"): (Rate(1.50, 9.00), Rate(1.50, 9.00)),
    ("gemini-3.5-flash-lite", "standard"): (Rate(0.30, 2.50), Rate(0.30, 2.50)),
    ("gemini-3.5-flash-lite", "batch"): (Rate(0.15, 1.25), Rate(0.15, 1.25)),
}
 
 
def monthly_cost(model, tier, in_tokens, out_tokens, era):
    """era is "2026" (introductory window) or "2027" (after the change)."""
    now, later = PRICES[(model, tier)]
    rate = now if era == "2026" else later
    return (in_tokens / 1_000_000) * rate.inp + (out_tokens / 1_000_000) * rate.out
 
 
def compare(label, model, in_tokens, out_tokens):
    rows = []
    for tier in ("standard", "batch"):
        a = monthly_cost(model, tier, in_tokens, out_tokens, "2026")
        b = monthly_cost(model, tier, in_tokens, out_tokens, "2027")
        rows.append((tier, a, b, b - a))
 
    print(f"\n[{label}] {model}  in={in_tokens:,} out={out_tokens:,} tokens/month")
    print(f"  {'tier':<10}{'2026':>12}{'2027+':>12}{'delta':>12}")
    for tier, a, b, d in rows:
        print(f"  {tier:<10}{a:>11.2f}${b:>11.2f}${d:>+11.2f}$")
 
    std_now = rows[0][1]      # Standard today
    batch_later = rows[1][2]  # Batch next year
    print(f"  -> gap between standard {std_now:.2f}$ today and batch "
          f"{batch_later:.2f}$ in 2027: {batch_later - std_now:+.4f}$")
 
 
if __name__ == "__main__":
    compare("classification batch", "gemini-3.7-flash", 40_000_000, 2_000_000)
    compare("interactive drafting", "gemini-3.7-flash", 8_000_000, 6_000_000)

I deliberately included one input-heavy and one output-heavy workload. Running it gives:

[classification batch] gemini-3.7-flash  in=40,000,000 out=2,000,000 tokens/month
  tier              2026       2027+       delta
  standard        37.50$      75.00$     +37.50$
  batch           18.75$      37.50$     +18.75$
  -> gap between standard 37.50$ today and batch 37.50$ in 2027: +0.0000$
 
[interactive drafting] gemini-3.7-flash  in=8,000,000 out=6,000,000 tokens/month
  tier              2026       2027+       delta
  standard        28.50$      57.00$     +28.50$
  batch           14.25$      28.50$     +14.25$
  -> gap between standard 28.50$ today and batch 28.50$ in 2027: +0.0000$

Two workloads with completely different token mixes, and both land on 0.0000$. The cancellation in the previous section is not the product of a convenient example.

The real value of keeping this script around is less the dollar figure than having your assumptions in one place. Prices change. When the table is updated, you edit PRICES and leave the estimating logic alone. If you want a hard stop before a job overspends rather than an estimate after the fact, pair it with the approach in Stop a Batch Before It Overspends: A Budget Gate Built on countTokens.

Your escalation rate has to fall to a third

If you route easy work to Flash-Lite and hard work to 3.7 Flash, here is what January does to you. Flash-Lite holds and only 3.7 Flash doubles, so the same routing policy does not scale your bill by a constant.

"""Project the real cost shift for a router splitting between Flash-Lite and 3.7 Flash."""
BIG = {"2026": (0.75, 3.75), "2027": (1.50, 7.50)}    # gemini-3.7-flash standard
SMALL = {"2026": (0.30, 2.50), "2027": (0.30, 2.50)}  # gemini-3.5-flash-lite standard
 
IN_PER_REQ, OUT_PER_REQ = 3_000, 400  # tokens per request (classification-shaped)
REQS = 300_000                         # requests per month
 
 
def blended(p, era):
    """p = the fraction escalated to the larger model."""
    bi, bo = BIG[era]
    si, so = SMALL[era]
    big = REQS * p * (IN_PER_REQ / 1e6 * bi + OUT_PER_REQ / 1e6 * bo)
    small = REQS * (1 - p) * (IN_PER_REQ / 1e6 * si + OUT_PER_REQ / 1e6 * so)
    return big + small
 
 
print(f"{REQS:,} req/month, in={IN_PER_REQ:,} out={OUT_PER_REQ} per req")
print(f"{'escalated':>10}{'2026':>12}{'2027+':>12}{'increase':>10}")
for p in (0.05, 0.10, 0.20, 0.30, 0.50):
    a, b = blended(p, "2026"), blended(p, "2027")
    print(f"{p*100:>9.0f}%{a:>11.2f}${b:>11.2f}${(b/a-1)*100:>9.1f}%")
 
# How far must the escalation rate fall to hold the 2026 bill flat?
for p0 in (0.10, 0.20, 0.30):
    target = blended(p0, "2026")
    lo, hi = 0.0, p0
    for _ in range(80):  # binary search
        mid = (lo + hi) / 2
        if blended(mid, "2027") > target:
            hi = mid
        else:
            lo = mid
    print(f"to hold the bill at {p0*100:.0f}% escalation, January needs {lo*100:.1f}%")

The output:

300,000 req/month, in=3,000 out=400 per req
 escalated        2026       2027+  increase
        5%     597.75$     654.00$      9.4%
       10%     625.50$     738.00$     18.0%
       20%     681.00$     906.00$     33.0%
       30%     736.50$    1074.00$     45.8%
       50%     847.50$    1410.00$     66.4%
to hold the bill at 10% escalation, January needs 3.3%
to hold the bill at 20% escalation, January needs 6.6%
to hold the bill at 30% escalation, January needs 9.9%

The last three lines are the ones to sit with. Every required rate is roughly a third of the original. 10% becomes 3.3%, 20% becomes 6.6%, 30% becomes 9.9%.

Why a third rather than a half? Because what doubles is the unit price of the larger model, not your bill. The traffic going to Flash-Lite does not move. What moves is the premium you pay for escalating, and that premium grows by a factor of just over three. The large model's rate doubles, but the gap between large and small widens by more than double.

That one-third figure belongs to this particular input/output ratio; workloads with longer outputs will land somewhere else, so run it with your own numbers. What does generalize is this: "the rate doubled, so I will halve the escalation rate" does not work under any set of assumptions. Halving it still leaves you paying more.

What I moved in my own pipeline

I run wallpaper apps as an indie developer, and I have Gemini assign a category to each new image. Those categories feed the browse screens in the builds shipped to the App Store and Google Play. It is simple work — sort into a few dozen categories — and it runs over a batch of images at a time. Separately, I generate drafts for the sites I operate, and that is work I sit and wait for.

For a long time both ran on the same tier. There was no reasoning behind it. The first thing that worked was what I kept.

The price change gave me a reason to split them. The deciding question turned out not to be quality or token volume, but how many minutes I can wait for the result.

What I noticed after splitting them is that most of the work I had labelled "can't wait" had simply never been made to wait. Shifting categorization to overnight changed nothing about my process, as long as the results are there in the morning. I had been running it synchronously because that was easier to watch, not because anything required it.

Draft generation, on the other hand, could not move. Wait time there is bound to thinking speed, and trading tens of minutes for half price is not a trade worth making. Push everything to Batch on price alone and the bill goes down while your hands stop.

One more thing from actually doing this. The migration itself was not the slow part — working out which job was running on which tier took longer than moving them. The call sites had drifted into several places, and I could not tell which were synchronous without reading the code. Before you can split tiers, the model name and tier have to live in one place in your configuration. That cleanup pays off again the next time a model is replaced.

Do not let a job straddle the year boundary

If you migrate early, there is one thing to watch. Batch jobs take time between submission and completion, which means a job submitted on December 31 can finish on January 1.

Which rate applies then? The moment of submission, or the moment the tokens are processed? I could not find that stated on the pricing page.

Verifying an unknown in production is the most expensive way to learn it. I chose to avoid the question entirely by not scheduling large jobs across the new year. Late-December submissions get split into smaller pieces that finish before the date rolls over. Either interpretation gives the same result that way.

The same reasoning applies to retries. A job submitted in December that fails and gets resubmitted in January is processed at the new rate. Heading into year end, submitting in units small enough that you are not left with retries makes the number predictable. If you have not decided how partial batch failures are handled, this is a good moment to settle it.

What to decide before the year ends

The deadline is December 31, 2026, so there are more than four months left. December is rarely a calm month for design work, though, so three decisions made now will save you scrambling later.

1. Draw the line between work that can wait and work that cannot. Classification, aggregation, summarization, reformatting — anything where no human is watching a screen. Once that line exists, the actual move to Batch can happen whenever
2. Consolidate the model name and tier into one configuration point. Scattered across call sites, every comparison becomes an edit. Being able to switch is a prerequisite for deciding anything
3. Record your usage now. When the bill rises in January, you want to be able to separate the price change from growth in usage. Monthly input and output token counts are enough

The move to 3.7 Flash itself needs no deliberation on price, given that it matches 3.6 Flash. What deserves thought is whether your architecture is ready for December 31.

Start by picking one workload nobody is waiting on and running it through the Batch tier. Before you learn whether half price helps, you will learn whether you can actually wait for it.

Prices change, and the figures here are as of August 16. Please confirm the current values on the pricing page before you commit to anything. I did not expect 3.6 and 3.7 Flash to be identical until I opened the table myself — assumptions shift quietly, and that page is worth reopening now and then.