Gemini price doubling: re-forecast before 1 December and 1 January

What changes on which date

Google lists two time-limited rates that both end soon. Gemini 4 Argon is $2.00 per million input tokens and $10.00 per million output tokens through 30 November 2026, then $4.00 and $20.00 from 1 December. The output price includes thinking tokens, and Argon is not available on the free tier ¹. Gemini 3.8 Flash is $0.75 and $3.75 through 31 December 2026, and $1.50 and $7.50 from 1 January 2027 ².

The step reaches every consumption mode Google lists for Argon, not only standard:

Argon became generally available on 13 October ³, so any team on it adopted it at the first rate. This post goes past the general introductory-pricing explainer in our earlier guide and works through the recompute itself.

One scope note. The Gemini 3.6 Flash guide lists $1.50 input and $7.50 output with no end date ⁴. I did not find a dated step for 3.6 Flash on the pages I could read, so treat it as unconfirmed and check the live pricing page before you put a step in that row.

Which of your traffic is on the stepping models

Start with an inventory, because the model string in your code may not match the model that bills. Google's release notes say requests to gemini-3.7-flash are automatically routed to gemini-3.8-flash, and requests to gemini-3.5-flash are routed to gemini-3.6-flash ³. A service that "budgeted on 3.x Flash" with an old string may therefore already be on 3.8 Flash and will hit the January step.

Group last month's usage by the model that actually answered, by project and by key. Then split each group into four lines: standard, batch or flex, priority, and cached input. Each line has its own rate and each doubles. Search and Maps grounding is a separate line, billed at $14 per 1,000 requests after 5,000 free a month shared across Gemini 3 and newer models, and the page shows no dated step for it ¹.

If a model has no row in your price schedule, treat its traffic as unpriced rather than zero. A missing rate that quietly adds nothing is how a forecast ends up half the invoice.

Recompute unit economics from tokens per task

The FinOps Framework says forecast models should document the pricing models to be used and when they will be implemented ⁵. A dated price schedule is that documentation. It also says that once a forecast is agreed, the budget owner must meet it or seek variance funding ⁵, so the owner needs the step in hand before the month starts.

Unit economics for generative AI often starts at cost per token and moves toward outcome measures such as cost per assist or cost per case resolved ⁶. A rate change moves the token rate but not the tokens per task, so compute per task first:

from datetime import date

# USD per 1M tokens, standard tier. Source: ai.google.dev pricing, read 2026-10-27.
SCHEDULE = {
    "gemini-4-argon":   [(date(2026, 10, 13), 2.00, 10.00), (date(2026, 12, 1), 4.00, 20.00)],
    "gemini-3.8-flash": [(date(2026, 9, 2),   0.75,  3.75), (date(2027, 1, 1),  1.50,  7.50)],
}

def rate(model, day):
    rows = [r for r in SCHEDULE.get(model, []) if r[0] <= day]
    if not rows:
        raise LookupError(f"unpriced: {model} on {day}")  # never default to 0
    _, rin, rout = rows[-1]
    return rin, rout

def cost_per_task(model, day, in_tok, out_tok):
    rin, rout = rate(model, day)
    return (in_tok * rin + out_tok * rout) / 1_000_000  # out_tok includes thinking

Count thinking tokens as output; Google bills them at the output rate ¹. Take out_tok from the usage field of real responses, not from the visible answer length.

Compare alternatives at your own rates, not list rates

List rates are the wrong yardstick if you hold a contract. Use the rate your own provider bills you for each candidate. I have not quoted other vendors' rates here because they were not part of what I read; fill them from your contracts. The comparison has three traps:

• Token profiles differ. Google notes that 3.8 Flash can use more tokens on long, complex tasks by design, and that lowering the reasoning level reduces consumption ². A model with a lower rate and a longer reasoning habit can cost more per task.
• Quality moves the denominator. Divide cost per task by the share of tasks that pass your own evaluation. Cost per successful task is the number that compares models, and a model that fails more often costs more per useful result.
• Reasoning settings are part of the model. Argon and 3.8 Flash both take low, medium and high thinking levels ⁷². Compare at the setting you would run, not at the default.

Before deciding, rerun the evaluation at the post-step rate. A model chosen at the introductory rate was chosen on a price that is about to end.

Options before the step

Four moves are worth pricing for each Argon and 3.8 Flash line:

1. Move deferrable work to Batch or Flex. Argon's Batch and Flex rates are half of standard both before and after the step ¹, so a workload that can wait pays the post-step standard rate halved.
2. Lower the thinking level where the task allows it. Output, including thinking, is the larger price line on both models.
3. Step down to a smaller model for classification, extraction or routing-type work. Gemini 3.5 Flash-Lite is listed at $0.30 input and $2.50 output ⁴. Check that rate and any end date on the current pricing page.
4. Stay, and fund it. If the quality justification holds at the new rate, put the new rate in the budget and note the approval.

Also check priority traffic. Priority stepped from $3.60 and $18 to $7.20 and $36 for Argon ¹, so an Argon workload on Priority has the largest absolute increase.

Budget alerts timed to the step

A budget alert set at 80% of last quarter's number fires late, or fires on a change you already approved. Three settings avoid both:

• Set the monthly budget for each Google project in the period it applies: the Argon budget changes on 1 December and the Flash budget on 1 January.
• Alert on forecast-to-exceed as well as on spend thresholds. A forecast that uses the old rate will not warn you.
• On the step date, re-baseline any alert based on a usual day. A drift alert tuned to old daily spend will fire once on a planned doubling, which is noise, then stay quiet while the new level becomes normal.

INFRO can carry this on your own Google connection. Budgets set a hard cap per organization, project, member or key with alerts at thresholds you choose. Spend alerts flag a budget forecast to be exceeded, drift from a scope's usual day and unpriced traffic. Custom rates take the figures in your contract before the vendor's list rate. Estimated cost per request is queryable by project and key, and traffic-change findings name things like a new snapshot or longer answers with an estimated weekly cost change. Reconciliation against provider cost APIs covers OpenAI and Anthropic, not Google, so compare Google's invoice to the usage export yourself, for example from the FOCUS export. The estimate is an estimate; your invoice is the record.

Before 1 December: the checklist

• Inventory the model that answered, by project and key, not the model string in code.
• Build the dated schedule with a source and read date per row, and leave unconfirmed rates (3.6 Flash) flagged.
• Compute tokens per task from usage data, thinking included.
• Reprice November to January month by month, and book the variance with the budget owner ⁵.
• Rerun your evaluation at the post-step rate for Argon and for each alternative at your contracted rate.
• Move deferrable work to Batch or Flex and lower the thinking level where quality allows.
• Move alert thresholds to the new budgets and re-baseline drift alerts on 1 December and 1 January.
• Re-read the pricing page on the day of each step, since scheduled changes can be revised.

The FinOps Framework places forecasting and budgeting under the same Quantify Business Value domain ⁸, which is the right place to hold this: one forecast, one owner, updated when the vendor's page changes.