Hi @Pooja_Kapse , thanks for following up.
A HAR from the AI Studio web interface won’t capture this. The web app calls an internal endpoint (alkalimakersuite-pa.clients6.google.com), and requests on that path are served correctly by Pro with thinking intact. The downgrade occurs on the public API at generativelanguage.googleapis.com, so a HAR exported from the web UI would only show a healthy request.
Instead I have a deterministic reproduction using plain curl with an API key — no client library, no framework. All requests were POSTs to models/gemini-3.1-pro-preview:streamGenerateContent?alt=sse on a Tier 1 paid account, made on 17–18 September 2026 (UTC-4). The three runs below used the same endpoint and the same generationConfig, and differ only in the prompt:
| responseId |
promptTokens |
final modelVersion |
thinking |
|
|
|
| 2dGsau-eK8-v_PUPka6ssQc |
9,350 |
3.1-flash-lite-preview-03-2026 |
1,412 tokens |
|
|
|
| 6K2saq73Ks2d-8YPy87w0A8 |
21,824 |
3.1-flash-lite-preview-03-2026 |
1,476 tokens |
|
|
|
| UsusapO6INSo_PUPhuXSsAQ |
22,050 |
gemini-3.1-pro-preview |
1,678 tokens |
|
|
|
Each prompt was run repeatedly and the outcome is stable per prompt. The prompt used in rows 1 and 2 has produced the downgrade in every run, across two days and multiple variations of its content.
In the two downgraded runs, every chunk of the stream reports gemini-3.1-pro-preview, and only the very last chunk reports 3.1-flash-lite-preview-03-2026. Row 3 is public-domain classical Chinese text with a one-line summarisation instruction; rows 2 and 3 are 226 tokens apart with opposite outcomes.
I should also update my earlier finding in this thread. In early September the trigger appeared to be input token count, with a threshold near 12,600 — at the time this was reproducible under controlled conditions (disabling one section to drop below the threshold stopped the downgrade; replacing that section with unrelated content of equal token count did not), and the same threshold was independently reported earlier in this thread on a different path. That behaviour no longer reproduces. Row 3 above has the highest prompt token count of the three and was served by Pro, while row 1 at 9,350 tokens was downgraded. Whatever determines the outcome now, it is not token count — which suggests the routing logic itself changed at some point between September 4 and September 17.
I’ve since tested and ruled out maxOutputTokens, topK, topP, temperature, frequencyPenalty, presencePenalty, thinking level, message structure (fragmented, merged, and single-turn), and the client itself. What remains is that different prompts produce consistently different outcomes — rows 2 and 3 are the clearest case, nearly identical in length and sent with identical settings, yet one is always downgraded and the other never is. I can’t determine from the outside what distinguishes them, and I’d rather not speculate.
On the reported modelVersion, there are only two possible readings, and both need addressing:
- The request was served by Flash Lite while reported as Pro for the entire stream. That is a silent downgrade.
- The request was served by Pro and the final chunk misreports it as Flash Lite. That is a reporting defect affecting model identity and usage attribution.
The attached dashboard covers the test period. Input tokens are attributed to Pro only, while output tokens are split between Pro and Flash Lite on the same day. That points to the first reading. But under the second reading the metering system is recording the wrong model, which is a billing-accuracy problem rather than a cosmetic one. Preview status may explain variability in output quality, but not a response that reports one model while usage is attributed to another. Either way the current behaviour shouldn’t stand.
Beyond that, two things are worth fixing regardless of cause:
- A client reading modelVersion as the stream arrives sees gemini-3.1-pro-preview for the entire response, and finds out otherwise only from the final chunk — after the content has already been received.
- There is no explicit signal and no opt-out. As @yuuji asked earlier: if this is a capacity fallback, could it fail explicitly (503/429) rather than silently returning a degraded response?
Even if the routing is intentional and stays, callers should be able to detect that it happened. At present there is no documented way to know, and no way to request that it not happen.
The prompt used in rows 1 and 2 is derived from a third party’s work, which I’m not able to share publicly. If your team needs a payload, I can construct a minimal synthetic case instead — let me know if that would help.
