gemini-cli - 💡(How to fix) Fix Critical routing flaw in Gemini CLI – Background utility limits block main Pro model

What happened?

[ACTION REQUIRED] 📎 PLEASE ATTACH THE EXPORTED CHAT HISTORY JSON FILE TO THIS ISSUE IF YOU FEEL COMFORTABLE SHARING IT.

What did you expect to happen?

I expected my explicitly configured Pro model to continue functioning without being blocked by the rate limits of hidden background utility models.

Client information

• CLI Version: 0.43.0
• Git Commit: c0775c38b
• Session ID: c04e96dd-098f-4a81-af34-518339650e52
• Operating System: darwin v26.0.0
• Sandbox Environment: no sandbox
• Model Version: gemini-3.1-pro-preview
• Auth Type: oauth-personal
• Memory Usage: 249.4 MB
• Terminal Name: Unknown
• Terminal Background: #212734
• Kitty Keyboard Protocol: Unsupported

Login information

Dear Gemini Team,

I am writing to express my disappointment with a frustrating design flaw in the current Gemini CLI architecture.

Even when I explicitly configure the CLI to use gemini-3.1-pro-preview as my main model, the system forces the use of flash or lite models in the background for tasks like utility_router and utility_loop_detector. Once these background utility models hit their rate limits (e.g., due to large codebase caching), the entire CLI is blocked. I receive a rate limit error for a model I didn't even actively choose, while my explicitly selected Pro model likely still has quota remaining.

This completely undermines the ability to manually select a model and breaks the workflow for heavy users. Please fix this routing logic so that background utility limits do not paralyze the explicitly configured main model.

Thank you, A disappointed developer

Anything else we need to know?

No response