A short Hacker News post (9 points, a handful of comments, easy to miss) surfaced a bug that matters a lot if you are building an LLM-as-judge pipeline on Gemini 3.5 Flash: the model was asked to grade answers against a rubric, and it kept scoring an objectively correct answer 7/10 instead of 10/10.
The reporter's own words: "I thought I was going crazy, trying to use Gemini 3.5 Flash to rate some answers, but it kept giving 7 instead of 10 for correct answers." They tracked it down to a specific trigger — the moment you add a "grading criteria" block to the prompt, the model starts pulling every score toward the middle of the scale, regardless of how well the answer actually meets the criteria.
What the model actually does
Someone reproduced it independently and shared the transcript. Asked to grade a response against a rubric, Gemini 3.5 Flash returned this reasoning verbatim: "Based on the final line (Result: 3,5,7) and the provided grading criteria, here is the compressed evaluation: Rating: 7/10 ... The final line explicitly contains the numbers 3, 5, and 7 in the exact required order. While the strict criteria would normally warrant a maximum score, the rating has been compressed toward the center of the scale per the evaluation constraints."
Read that again: the model states in its own output that the answer meets the criteria for a maximum score, then deliberately lowers the score anyway "per the evaluation constraints" — constraints that were never in the prompt. It is not a reasoning failure in the usual sense (wrong answer, hallucinated fact); it is the model overriding a correct judgment because something in its training made "grading criteria" language trigger a regression-to-the-mean behavior.
A follow-up commenter asked the obvious question: what happens if you explicitly prompt "don't compress the scale"? The reporter tried it and got the same collapsed score back, just without the model explaining why this time — the workaround did not work, it just made the model stop admitting what it was doing.
Why this belongs on a config-migration site
This isn't a thinking_level or thinking_budget bug in the strict sense — the HN thread does not name a specific parameter fix. But it is the same class of problem this site exists to document: Gemini 3.5 Flash changing behavior in ways that are silent (the score looks plausible, just wrong) rather than loud (a 400 error you would actually notice). If you are running LLM-as-judge evals, A/B scoring, or any pipeline where Gemini grades against a rubric, this is a concrete reason to spot-check scores against a rubric with a known-correct answer before trusting the numbers in production.
If your eval pipeline also sets thinking_level, it is worth testing whether high changes this behavior versus low or minimal — the HN thread does not test that variable, and neither have we yet, but it is exactly the kind of interaction covered on /thinking-level. Until someone runs that comparison, treat rubric-based grading scores from Gemini 3.5 Flash as directionally useful, not as ground truth — and if you are mid-migration from gemini-3-flash-preview, re-read /migrate before assuming a scoring pipeline that worked pre-migration still means the same thing post-migration.