[Deep Issue Investigation & Findings] Gemini CLI OAuth mode became dramatically slower / hangs on "Thinking..." while API key works fine

[MightyBig]

I am posting this in case it helps narrow down a regression, because I spent a lot of time isolating this and I do not think it is just user error.

Summary

My Gemini CLI workflow using Google OAuth / Gemini Code Assist became extremely slow about 3 weeks ago. In many cases it would sit on "Thinking..." for a very long time on very simple prompts, and sometimes appeared to hang indefinitely.

A simple example was a prompt like:

what is the root folder of this project called

This used to feel snappy on Flash. Recently it became inconsistent, very slow, or looked frozen.

The key finding is this:

• OAuth mode is slow / flaky
• API key from AI Studio works
• so this looks specific to the OAuth / Code Assist path, or to how that path interacts with CLI startup / project analysis

Environment

• Windows 10
• Gemini CLI
• Signed in with Google via /auth
• Plan shown in CLI: Gemini Code Assist in Google One AI Pro
• Project is a local TypeScript/React game repo
• Running both in plain cmd.exe and in VS Code terminal

Symptoms

1. Very long "Thinking..." on simple prompts

Even for basic project-aware prompts, the CLI would often sit there far longer than expected.

2. Huge difference between OAuth and API key behavior

After testing with an API key from AI Studio, the same general environment behaved much better.

This is the biggest reason I do not think this is just my machine or my repo.

3. Debug console repeatedly shows the same suspicious lines

In debug output I repeatedly saw things like:

• Authenticated via "oauth-personal"
• Phase 'load_builtin_commands' was started but never ended
• Error flushing log events: HTTP 400: Bad Request
• Selected IDE connection file: gemini-ide-server-...json
• User policy exists for 'codebase_investigator'
• Loaded with 3 agents

The important part is that auth succeeds, but startup / tool loading / project analysis still looks unhealthy.

What I tested

I tried to isolate this properly instead of just complaining.

Baseline tests

From plain command prompt:

gemini -p "say OK"

This worked.

Also from inside my project folder:

gemini -p "what is the root folder of this project?"

This also worked, but often took around 30 to 45 seconds, which is far slower than expected for Flash.

Interactive mode

Interactive mode sometimes worked, but often felt much slower than it used to, especially for project-aware prompts or codebase analysis.

Local config isolation

I went into my .gemini folder and temporarily disabled a number of local state/config items.

I disabled or renamed:

• extensions
• projects.json
• state.json
• trustedFolders.json

After doing that, the CLI seemed to improve somewhat. It still was not as snappy as it used to be, but it became less likely to sit forever on "Thinking...".

That suggests stale local state may be contributing, but I do not think it explains the whole problem.

VS Code / IDE influence

The debug logs still showed an IDE connection file being selected, even after some cleanup:

Selected IDE connection file: gemini-ide-server-...json

So there may also be some interaction with the IDE-connected path.

Additional data point from a small investigation prompt

I also gave it a relatively small job: investigate physics/FPS improvement opportunities in my game and do not code yet, just analyze.

This is exactly the kind of task that used to feel very fast on Flash. Previously, I would expect something like this to take around 1 minute max.

Instead, the /stats screen from that single prompt showed:

• Wall Time: 15m 21s
• Agent Active: 14m 6s
• API Time: 14m 6s (99.9%)
• Tool Time: 460ms (0.1%)

Model usage for that one prompt showed:

• gemini-3-flash-preview
• 7 requests
• 211,561 input tokens
• 93,495 cache reads
• 1,249 output tokens

That is the clearest example I have that the slowness is not just local file reading or tool execution. The CLI reported almost all of the time as API time.

Current behavior

At the moment, after disabling some .gemini state files, the CLI is more usable than before. It no longer seems to get stuck on "Thinking..." as often, and some prompts do return faster than before.

But it is still noticeably slower than it used to be, and the debug logs still show the same unhealthy startup/logging messages.

Why I am posting

I am mainly trying to answer these questions:

1. Is this a known regression in the OAuth / Code Assist path?
2. Is load_builtin_commands was started but never ended a known issue?
3. Are the repeated HTTP 400 log flush errors just telemetry noise, or are they related to the latency / hanging?
4. Is stale .gemini project state known to poison performance?
5. Is the IDE connection layer contributing to this?
6. Is there a current reason Flash in Gemini CLI is taking 15+ minutes on small investigation tasks that previously felt close to real-time?

My current conclusion

From everything I tested, my best guess is:

• auth itself is succeeding
• the model itself is not completely broken
• the problem is somewhere in the OAuth-backed CLI startup / project-analysis / tool-loading path
• stale local .gemini state may worsen it
• API key mode appears healthier than OAuth mode in the same environment
• at least some of the current delay appears to be genuine API-side latency, not just local tooling overhead

If useful, I can provide

• exact debug output
• screenshots
• my .gemini folder contents before/after disabling state files
• side-by-side timing comparisons between OAuth and API key mode
• the /stats screenshot for the 15+ minute investigation prompt

If anyone from the team wants a cleaner repro format, I am happy to provide it. Right now I mainly want to know whether this is already understood as a regression, because the current behavior is a big step down from how responsive Flash used to feel.

[adesutherland]

Thank you for responding to my other post ... I personally believe the slowdown is caused by gating @ google, prioritising API key calls (PAYG) over bundled subscriptions to manage costs

[MightyBig]

it certainly feels that way. I've tried everything to resolve the issue on my end, but I'm out of ideas. Begs the question, why am I paying for a Pro account? That's why I bought it... I don't use the crappy web/chat interface - I purchased it specifically for the CLI.

[Maroo-b]

I had the same experience, using the API key, it works fine regardless of which CLI version I'm using, but for the OAuth login, only downgrading to 0.34.0, I found about it in this issue #24294

[MightyBig]

I had the same experience, using the API key, it works fine regardless of which CLI version I'm using, but for the OAuth login, only downgrading to 0.34.0, I found about it in this issue #24294

Thanks, that lines up pretty closely with what I’m seeing.

I also found that API key auth behaves much better regardless of CLI version, which makes this feel much less like a local repo issue and much more like something specific to the OAuth / Code Assist path.

I tried downgrading to 0.34.0 as well, and while it may be a bit better, it still does not feel normal on my side. Even for relatively small investigation-style prompts, /stats is showing that almost all the time is being spent in API time rather than tool time. For example, one recent run was over 5 minutes wall time with 99%+ of that attributed to API time, while tool time was only around 1 to 2 seconds.

I also keep seeing the same debug issues in OAuth mode:

load_builtin_commands started but never ended
repeated Error flushing log events: HTTP 400: Bad Request
aggressive invocation of codebase_investigator on prompts that feel like they should be much lighter

So from my side, 0.34.0 seems more like a partial mitigation than a real fix.