[Bug] Hardcoded thinking_level="minimal" breaks the default gemini-flash-latest and all Pro models (400 INVALID_ARGUMENT) #282

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"):

Dropping thinkingConfig from the payload makes every one of the failing models succeed.

Reproduce

1. Fresh v9 install, Gemini provider, valid free-tier key, default model (gemini-flash-latest).
2. Select text, trigger any tool.
3. "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:

1. 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.
2. Catch the 400 and retry once without thinking_config. Keeps the latency win where it works, degrades gracefully where it doesn't.
3. 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.