Gemini CLI Has Been Hitting “Server Limit Exceeded” Frequently Over the Past Month — I’m Considering Switching to Claude Code / Codex

[tanjunwen0302]

I used to really like google-gemini/gemini-cli (gmmini cli), and I recommended it often. The main reason was simple: it runs on Gemini models, and it fit my development workflow really well.

However, over roughly the past month, I’ve gradually stopped using Gemini CLI. Model calls have been frequently failing with errors like “server limit exceeded,” “resource exhausted,” or “rate limited.” From what I can tell, this looks more like a server-side stability or quota/rate-limiting issue than something caused by my local setup.

More importantly, it’s not just the Pro model—Flash runs into the same problem quite often. Conversations and tasks get interrupted, retries keep failing, and it’s become hard to reliably get through everyday work.

Given the current reliability and usability issues, I’m planning to stop using Gemini CLI for now and move to alternatives such as Claude Code or Codex. If the service becomes noticeably more stable (at least consistently usable during normal hours), I’d be happy to give it another try and recommend it again.

[okurz]

[…] If the service becomes noticeably more stable (at least consistently usable during normal hours), I’d be happy to give it another try and recommend it again.

just the past two days for me gemini-cli worked again without any problems and no delays until I exhausted my quota for the used models :)

[tanjunwen0302]

I still can’t get it to work reliably. When I use the 3.1 Pro model, it’s always very slow and fails most of the time. Flash is somewhat better and is occasionally usable.

Do you run into the same issue at certain times of day?

[okurz]

I was exclusively using 3-flash-preview the past days and that worked fine but yes there can be "busy times" of a day sometimes

[aniruddhaadak80]

From my point of view, the product risk here is not just the raw limit error but the fact that the failure mode feels unpredictable during normal work. If capacity is tight, the CLI should probably make a clearer distinction between quota exhaustion, temporary server saturation, and retryable overload, then offer an automatic downgrade or queued retry path. That kind of reliability signaling would do a lot to keep people from feeling they have to switch tools entirely.