Add Gemini 3.5 Flash to Google Gemini models

[KachurPro]

Summary

• add Gemini 3.5 Flash as the first Google Gemini language model option
• add localized model description keys for all supported locales
• use minimal thinking for Gemini 3.x when thinking is disabled, instead of sending reasoning_effort: "none" to Gemini paths

Why

Gemini 3.5 Flash was released in May 2026 and has been performing especially well in OpenWhispr-style workflows: very fast interactive cleanup, strong instruction following for context cleanup, and reliable team-agent control.

It is a strong recommended focus model for users who want a fast cloud model for language cleanup and agent workflows.

Validation

• npm run i18n:check
• npm run typecheck
• npm run lint (passes with existing warnings, no errors)
• npm run build:renderer
• Google Gemini API smoke test: models/gemini-3.5-flash is available via ListModels and supports generateContent; direct Gemini and OpenAI-compatible smoke requests returned OK

[KachurPro]

Heads-up: I bundled a small CI fix into this PR (one line in .github/workflows/build-and-notarize.yml).

build-windows was failing on this PR — and on every other fork PR (e.g. #836, #835, #830, #806) — at the Build and Sign Application step. electron-builder.json's win.azureSignOptions makes electron-builder always attempt Azure Trusted Signing, and fork PRs don't have the AZURE_* secrets, so the step exits 1. The build-macos job already skips signing on pull_request via CSC_IDENTITY_AUTO_DISCOVERY; the Windows job only had a dependabot[bot] carve-out.

I changed the Windows step to skip Azure signing for all pull_request events. Signing on push/release is unchanged, and the old dependabot carve-out is subsumed (dependabot PRs are pull_request events too).

Happy to split this into a separate PR if you'd prefer — just let me know. The Gemini 3.5 Flash change itself is unrelated and builds fine on macOS/Linux.

[KachurPro]

Follow-up on the Windows CI fix: the previous inline override, --config.win.azureSignOptions=null, still reached electron-builder as the string "null", so 26.8.1 failed schema validation before it could skip signing. I pushed ea38ece, which uses a small JSON config file extending electron-builder.json with a real azureSignOptions: null, and the Windows workflow selects that config only for pull_request builds. Push/release signing stays unchanged.

Local checks passed after rebase: npm run i18n:check, npm run typecheck, npm run lint (existing warnings only), npm run build:renderer, plus an electron-builder config load check confirming azureSignOptions=null. The new GitHub Actions runs are currently action_required and waiting for maintainer approval before jobs are created.

[aryadovoy]

Also waiting:

• Gemini 3.1 Flash Lite
• Gemma 4 31B

[xAlcahest]

Nice addition, the model entry plus the thinking-suppression wiring is mostly there. One thing blocks it for me.

In gemini.ts the new thinkingConfig is gated on model.startsWith("gemini-3"), so it fires for every Gemini 3.x model, gemini-3.1-pro-preview included. The catch is that the four *DisableThinking settings default to true (settingsStore.ts:970-973), and selecting a model without thinking support only hides the toggle, it doesn't clear the stored value (InferenceConfigEditor.tsx:152-156). So a user on 3.1 Pro running cleanup ends up sending thinkingLevel: "minimal" to generateContent.

Per Google's docs the Pro tier only accepts low/medium/high, and the API rejects an unsupported level with 400 INVALID_ARGUMENT "Thinking level ... is not supported for this model" (same shape as proxypal#170 on gemini-3-pro). Cleanup just fails for anyone on 3.1 Pro.

The other two paths you touched already gate on supportsThinking (the AI SDK providerOptions in ReasoningService.ts and thinkingSuppression.ts), so they only fire for gemini-3.5-flash, where minimal is valid. The REST path is the odd one out. Simplest fix is to gate it the same way:

if (config.disableThinking === true && getCloudModel(model)?.supportsThinking) {

Then only 3.5 Flash gets minimal and 3.1 Pro is left untouched. (You could also fall back to "low" for non-Flash gemini-3, but matching the other two paths is cleaner.)

Smaller one: the gemini_gemini_3_5_flash description is left as the English string in de/es/fr/it/ja/pt/zh-CN/zh-TW, only ru is translated. Worth translating the rest to match the other model descriptions before merge.

[KachurPro]

Thanks for the review — I pushed f1737a94 with both recommendations addressed.

• The REST Gemini path now gates thinkingConfig on getCloudModel(model)?.supportsThinking, so gemini-3.1-pro-preview no longer receives thinkingLevel: "minimal"; only models marked as supporting thinking suppression, currently gemini-3.5-flash, get that config.
• Translated gemini_gemini_3_5_flash in de, es, fr, it, ja, pt, zh-CN, and zh-TW.

Validation passed:

• npm run i18n:check
• npm run typecheck
• npm run lint (0 errors, existing warnings only)
• npm run build:renderer

All recommendations from the review comment are implemented.

[xAlcahest]

Both addressed, thanks for the quick turnaround. gemini.ts now gates on supportsThinking, so only 3.5 Flash gets minimal and 3.1 Pro is left alone, which also lines it up with the other two paths. The eight locale descriptions are translated too. Looks good to me.

[gabrielste1n]

awesome work thank you @KachurPro