Gemini 3.7 Flash Calls Now Route to Gemini 3.8 Flash

Your team pinned Gemini 3.7 Flash, tested it, signed it off, and since October 8 it has been quietly answering as a different model. Google's changelog says API requests to gemini-3.7-flash are now routed to gemini-3.8-flash, and requests to gemini-3.5-flash go to gemini-3.6-flash. The old names keep working, so nothing errors and nothing pages anyone.

That makes this a project-management problem before it is an engineering one: behaviour, latency and cost can all move with no pull request to review.

What changed for gemini-3.7-flash on October 8

| You send | Answered by | Old model released | | --- | --- | --- | | gemini-3.7-flash | gemini-3.8-flash | August 13, 2026 | | gemini-3.5-flash | gemini-3.6-flash | May 19, 2026 |

The deprecations page lists no shutdown date for either old model and says the API routes requests to the replacement instead. Google's advice is to update your model string to gemini-3.8-flash.

Google's model docs recommend that production apps use a specific stable version. This change shows what pinning buys you: a fixed string, not fixed behaviour. I found no opt-out in the docs.

What a routed Gemini 3.8 Flash call can change

Google's Gemini 3.8 Flash guide is written for people migrating on purpose. It doesn't say how the redirect treats each setting, so use it as your test list:

• Thinking level. The default is medium, and minimal is documented as returning an error on 3.8 Flash. If any caller sets minimal, test that one first.
• Sampling parameters. temperature, top_p and top_k are listed as deprecated, and candidate_count as unsupported in Gemini 3 and later. The page doesn't say whether 3.8 ignores or rejects them.
• Token use. The guide says 3.8 Flash can use more tokens on longer, complex tasks "by design". Thinking tokens bill as output.
• Price. The pricing page lists Gemini 3.8 Flash at $0.75 per 1M input tokens and $3.75 per 1M output tokens through December 31, 2026. It has no row for 3.7 or 3.5 Flash, so use your own usage logs for the before-and-after.

Build a pinned-model inventory

First, find every place a Gemini model string lives. This search covers code, config and infrastructure files, skips -lite models, and also catches gemini-flash-latest, an alias Google's docs say moves when new releases ship.

rg -n --hidden -g '!node_modules' -g '!.git' -P 'gemini-3\\.[57]-flash(?![-\\w])|gemini-flash-latest' .

It won't see vendor products or no-code tools that call Gemini under your key, so ask each owner which string they send. Then record one row per hit: service, owner, model string, thinking level, sampling parameters sent, monthly tokens and the date of the last regression run.

Run a regression on the redirected model

Keep 20 to 50 real prompts from production in a CSV with id and prompt columns. This script replays them against whichever model string you pass in and records the answer, latency and token counts. Install the SDK with pip install google-genai and set GEMINI_API_KEY first.

import csv
import sys
import time

from google import genai

client = genai.Client()  # reads GEMINI_API_KEY from the environment
model = sys.argv[1]  # run once with gemini-3.7-flash, once with gemini-3.8-flash

with open('golden_prompts.csv', newline='', encoding='utf-8') as f:  # columns: id,prompt
    cases = list(csv.DictReader(f))

rows = []
for case in cases:
    start = time.perf_counter()
    response = client.models.generate_content(model=model, contents=case['prompt'])
    usage = response.usage_metadata
    rows.append({
        'id': case['id'],
        'requested': model,
        'served_by': response.model_version,
        'seconds': round(time.perf_counter() - start, 2),
        'prompt_tokens': usage.prompt_token_count,
        'output_tokens': usage.candidates_token_count,
        'thinking_tokens': usage.thoughts_token_count or 0,
        'text': response.text,
    })

with open(f'results_{model}.csv', 'w', newline='', encoding='utf-8') as f:
    writer = csv.DictWriter(f, fieldnames=rows[0].keys())
    writer.writeheader()
    writer.writerows(rows)

The script tests defaults. If production sets temperature or a thinking level, add them the same way your app does, then compare with your pre-October 8 eval scores and token logs.

The model_version field is documented as the version used to generate the response, but I found nothing on what it reports for a routed call, so treat it as evidence, not proof.

Name an owner and write the trigger down

A redirect like this slips through because nobody owns the vendor's changelog. Open a change request with a named person, not a team alias:

change_request:
  title: Gemini Flash redirect, 3.7 to 3.8 and 3.5 to 3.6
  trigger: Vendor changelog entry dated 2026-10-08
  owner: <named person>
  checks:
    - inventory updated, every pinned model string listed
    - golden-set regression run, results attached
    - token and latency change versus pre-redirect baseline reviewed
    - model string updated to gemini-3.8-flash after sign-off
  watch:
    - https://ai.google.dev/gemini-api/docs/changelog
    - https://ai.google.dev/gemini-api/docs/deprecations

The owner watches both pages, and any entry naming a string in your inventory opens a request like this one. That rule is my suggestion, not Google's.

What to do Monday morning

1. Run the search and build the inventory.
2. Run the golden set against both model strings and read the token and latency columns.
3. Name the owner and file the change request.
4. Once the run is clean, change the model string to gemini-3.8-flash yourself, so your config says what actually runs.

A model name is a pointer the vendor can move, so for anything you run in production, track which model actually answered, not the one you asked for.