Explicit Model Selection Ignored After Flash Quota Exhaustion

[mishka-zz]

What happened?

The Gemini CLI (version 0.41.2) fails to respect explicit model selection (e.g., gemini-3.1-pro-preview) once the quota for gemini-3-flash-preview (or the default Flash model) is exhausted. Despite having Pro model quota available and explicitly configuring the CLI to use it, all subsequent requests are blocked by attempts to call the exhausted Flash model.

This behavior suggests a flaw in the ModelAvailabilityService or the model routing logic, where a "silent fallback" or a hardcoded preference for Flash persists even when the user has overridden the model selection.

The CLI attempts to request gemini-3-flash-preview. Since the Flash quota is exhausted, the request fails with a quota error, rendering the CLI unusable for any task requiring the model, even though the Pro model is available and requested.

What did you expect to happen?

The CLI should honor the explicit model selection (gemini-3.1-pro-preview) and successfully execute the request using the Pro model's quota.

Steps to Reproduce

1. Exhaust the quota for gemini-3-flash-preview (the default/Flash category model).
2. Explicitly set the CLI model to gemini-3.1-pro-preview.
3. Execute any command that requires an LLM call (e.g., a simple prompt or a research task).

Client information

• CLI Version: 0.41.2
• Git Commit: b0c7a17
• Operating System: darwin v25
• Sandbox Environment: no sandbox
• Model Version: auto-gemini-3
• Auth Type: oauth-personal

Login information

No response

Anything else we need to know?

No response

[gemini-cli]

This is a bug in the model routing logic that ignores explicit user configurations and instead falls back to an exhausted model. It breaks core functionality when quota is hit, making the CLI unusable, requiring high priority (P1).

Effort Analysis:
The bug represents a logic error within the core model availability routing. Using grep_search and read_file, I investigated packages/core/src/availability/policyHelpers.ts and packages/core/src/availability/modelAvailabilityService.ts. I found that selectModelForAvailability relies on an isLastResort property that forces a fallback to the Flash model when selectFirstAvailable fails. Additionally, config._activeModel retains the fallback model incorrectly after explicit configurations and overrides it during applyModelSelection. This is a highly localized state and logic flaw within a single file or a pair of tightly coupled files. Based on the effort guidelines, 'Localized Bug Fixes: Single-file logic errors' accurately maps to effort/small.