Summary
GeminiProvider unconditionally sets thinking_level="minimal" for every non-Gemma model. As of today the API rejects MINIMAL on Gemini 3.7 and 3.8, and on every Pro model I tested, with HTTP 400. The bare except Exception in get_response then flattens that into the generic "An error occurred while processing the response."
This currently breaks the default configuration: the shipped default is gemini-flash-latest, which Google now resolves to gemini-3.8-flash.
Root cause
Windows_and_Linux/aiprovider.py, in _build_config:
if not is_gemma:
kwargs["thinking_config"] = genai_types.ThinkingConfig(thinking_level="minimal")
Exact API response:
400 INVALID_ARGUMENT
Thinking level MINIMAL is not supported for this model. Please retry with other thinking level.
Gemma is unaffected only because is_gemma skips the block entirely — which is why "switch to Gemma" appears to fix it.
Evidence
Same request shape, one key, only model varying (maxOutputTokens: 1000, temperature: 1.0, thinkingConfig.thinkingLevel: "minimal"):
| model |
result |
gemini-flash-latest → gemini-3.8-flash |
FAIL — MINIMAL not supported |
gemini-3.8-flash |
FAIL |
gemini-3.7-flash |
FAIL |
gemini-3.6-flash |
OK |
gemini-3.5-flash |
OK |
gemini-3-flash-preview |
OK |
gemini-3.5-flash-lite |
OK |
gemini-3.1-flash-lite |
OK |
gemini-flash-lite-latest → gemini-3.5-flash-lite |
OK |
gemini-pro-latest |
FAIL |
gemini-3.1-pro-preview |
FAIL |
gemini-2.5-pro |
FAIL — "Thinking level is not supported for this model" |
gemini-2.5-flash |
FAIL — same |
Dropping thinkingConfig from the payload makes every one of the failing models succeed.
Reproduce
- Fresh v9 install, Gemini provider, valid free-tier key, default model (
gemini-flash-latest).
- Select text, trigger any tool.
- "An error occurred while processing the response."
Or via REST, no app needed:
curl -s -X POST "https://generativelanguage.googleapis.com/v1beta/models/gemini-flash-latest:generateContent?key=$KEY" \
-H "Content-Type: application/json" \
-d '{"contents":[{"role":"user","parts":[{"text":"say ok"}]}],
"generationConfig":{"thinkingConfig":{"thinkingLevel":"minimal"}}}'
This also explains #247
#247 was closed as a Gemini 3 Pro compatibility nicety, with the cause guessed as the client "choking on thought signatures." It is the same bug: Pro models reject MINIMAL, and the reporter's working comparison (gemini-3-flash-preview) is precisely one of the models that still accepts it. No response-parsing change is needed.
Suggested fix
The immediate unblock is to stop sending MINIMAL where it isn't supported. Options, roughly in order of robustness:
- Omit
thinking_config unless explicitly opted into. Simplest, and the pre-v9 behavior — thinking_level was introduced in the Win v9 commit, so v8 never sent it.
- Catch the 400 and retry once without
thinking_config. Keeps the latency win where it works, degrades gracefully where it doesn't.
- Make thinking level a user-facing setting rather than a hardcoded constant.
Three adjacent points worth folding in:
- Pinning to
*-latest moves under you. gemini-flash-latest silently advanced to 3.8 and took the default config with it — the code comment right above the default still reads "currently points to Gemini 3 Flash Preview", which is what it pointed at when v9 shipped. Pinning the default to a concrete model, or validating at startup, would turn this class of break into something visible before a release.
except Exception is hiding the diagnosis. The 400 message names the problem exactly, but users only ever see the generic string, and logging.basicConfig writes to stderr, which a windowed PyInstaller build discards. Surfacing the API error text in the UI — or writing a log file next to the exe — would have made this self-service. Several open issues report the same generic sentence with unrelated causes.
- The custom-model placeholder currently suggests
e.g., gemini-3.1-pro-preview, which is one of the models that cannot work.
Environment
Windows 11 26200, Writing Tools Windows v9 (prebuilt release), free-tier Gemini key.
Summary
GeminiProviderunconditionally setsthinking_level="minimal"for every non-Gemma model. As of today the API rejects MINIMAL on Gemini 3.7 and 3.8, and on every Pro model I tested, with HTTP 400. The bareexcept Exceptioninget_responsethen flattens that into the generic "An error occurred while processing the response."This currently breaks the default configuration: the shipped default is
gemini-flash-latest, which Google now resolves togemini-3.8-flash.Root cause
Windows_and_Linux/aiprovider.py, in_build_config:Exact API response:
Gemma is unaffected only because
is_gemmaskips the block entirely — which is why "switch to Gemma" appears to fix it.Evidence
Same request shape, one key, only
modelvarying (maxOutputTokens: 1000,temperature: 1.0,thinkingConfig.thinkingLevel: "minimal"):gemini-flash-latest→gemini-3.8-flashgemini-3.8-flashgemini-3.7-flashgemini-3.6-flashgemini-3.5-flashgemini-3-flash-previewgemini-3.5-flash-litegemini-3.1-flash-litegemini-flash-lite-latest→gemini-3.5-flash-litegemini-pro-latestgemini-3.1-pro-previewgemini-2.5-progemini-2.5-flashDropping
thinkingConfigfrom the payload makes every one of the failing models succeed.Reproduce
gemini-flash-latest).Or via REST, no app needed:
This also explains #247
#247 was closed as a Gemini 3 Pro compatibility nicety, with the cause guessed as the client "choking on thought signatures." It is the same bug: Pro models reject MINIMAL, and the reporter's working comparison (
gemini-3-flash-preview) is precisely one of the models that still accepts it. No response-parsing change is needed.Suggested fix
The immediate unblock is to stop sending MINIMAL where it isn't supported. Options, roughly in order of robustness:
thinking_configunless explicitly opted into. Simplest, and the pre-v9 behavior —thinking_levelwas introduced in the Win v9 commit, so v8 never sent it.thinking_config. Keeps the latency win where it works, degrades gracefully where it doesn't.Three adjacent points worth folding in:
*-latestmoves under you.gemini-flash-latestsilently advanced to 3.8 and took the default config with it — the code comment right above the default still reads "currently points to Gemini 3 Flash Preview", which is what it pointed at when v9 shipped. Pinning the default to a concrete model, or validating at startup, would turn this class of break into something visible before a release.except Exceptionis hiding the diagnosis. The 400 message names the problem exactly, but users only ever see the generic string, andlogging.basicConfigwrites to stderr, which a windowed PyInstaller build discards. Surfacing the API error text in the UI — or writing a log file next to the exe — would have made this self-service. Several open issues report the same generic sentence with unrelated causes.e.g., gemini-3.1-pro-preview, which is one of the models that cannot work.Environment
Windows 11 26200, Writing Tools Windows v9 (prebuilt release), free-tier Gemini key.