Gemini 3.8 Flash drops the numeric thinking_budget parameter for a three step string enum, thinking_level, and the model errors out if you ask it for the minimal setting that older Gemini versions supported.
If your pipeline still calls Gemini with thinking_budget, that call needs an update the moment you point it at Gemini 3.8 Flash. Google's own migration guidance is explicit: replace thinking_budget with the string enum thinking_level. The old approach let you tune reasoning effort with an arbitrary token count. The new one asks you to pick a named tier instead.
Gemini 3.8 Flash supports three thinking_level values: low, medium, and high. Low is built for latency critical work, incident response, real time chat, anything where a fast answer beats a thorough one. Medium is the default, and Google's documentation describes it as the best quality for most tasks and the recommended setting for complex code and agentic use cases. High is for maximizing reasoning on difficult, multi step problems where you can afford to wait.
The detail worth flagging before it breaks a deployment: minimal is not supported for Gemini 3.8 Flash and will return an error. Earlier Gemini versions, including 3.7 Flash, accepted a minimal thinking level for the cheapest, fastest possible responses. If your code sets thinking_level to minimal because that is what an older integration used, upgrading the model string alone will not work. You will get an error back instead of a response, and it will look like a model problem rather than the parameter mismatch it actually is.
There is also a behavioral shift worth planning around even if you never touch the thinking_level parameter directly. Google's documentation states that Gemini 3.8 Flash can use more tokens on longer running and complex tasks, by design, taking smaller reasoning steps, calling tools iteratively, and verifying its work along the way. That means a like for like migration from 3.7 Flash to 3.8 Flash, even at the same thinking level, can quietly raise your token spend on the harder end of your workload, simply because the model is doing more internal verification before it answers.
For anyone maintaining a production integration, the fix is a five minute audit, not a rewrite: search your codebase for thinking_budget and any hardcoded minimal thinking level, replace both with an explicit thinking_level choice of low, medium, or high, and check your cost dashboards against the higher end of your task distribution after the switch. Skipping that audit is how a routine model upgrade turns into a same day incident.
Try it today
- Search your codebase for every call that sets thinking_budget on a Gemini request.
- Replace thinking_budget with the string enum thinking_level, choosing low, medium, or high per use case.
- Search separately for any call that sets thinking_level to minimal and replace it with low; minimal is not supported on Gemini 3.8 Flash and will return an error.
- Leave medium as the default unless a specific workload calls for low latency or high effort, since Google recommends medium for most tasks including complex code and agentic use.
- Re baseline your token cost dashboards after switching, since Gemini 3.8 Flash can use more tokens on longer running, complex tasks by design.