Why is Gemini CLI So Slow? Investigation into 35 Second Startup Times

I’ve been using the gemini CLI for quick repository queries. Or at least, I’ve been trying to use it. The problem? It takes anywhere from 4 to 35 seconds just to start.

This is a story about investigating why a supposedly developer-focused CLI tool is fundamentally broken for interactive use. This is where the fun starts!

The Symptom

I fired up gemini with time to ask a quick question about my repository:

time gemini -p "what is this repo about?"

# ... output ...

gemini -p "what is this repo about?"  6.72s user 2.00s system 25% cpu 34.910 total

35 seconds. For a CLI startup. That’s not a performance issue, that’s a design failure.

The Investigation

First hypothesis: gemini was doing a recursive directory scan to build context. A quick git status showed a clean working tree, but the .git directory itself is large.

I created a .geminiignore file and added .git to it.

The startup time dropped from 35 seconds to 11 seconds. Better, but 11 seconds is still absurd for a CLI tool.

The Real Culprit

The smoking gun: gemini --help takes anywhere from 3 to 13 seconds, averaging around 8 seconds.

Let’s quantify this with hyperfine:

hyperfine --runs 15 'gemini --help' 'claude --help'

Benchmark 1: gemini --help
  Time (mean ± σ):      7.789 s ±  2.734 s    [User: 3.725 s, System: 1.030 s]
  Range (min … max):    3.065 s … 13.587 s    15 runs

Benchmark 2: claude --help
  Time (mean ± σ):      1.381 s ±  0.755 s    [User: 0.814 s, System: 0.220 s]
  Range (min … max):    0.722 s …  3.185 s    15 runs

Summary
  claude --help ran 5.64 ± 3.66 times faster than gemini --help

Nearly 8 seconds on average to print help text. The variance is notable too - ranging from 3 to 13.5 seconds. Even Claude’s CLI, which isn’t exactly fast, is 5.6x faster.

And for an actual query? Even worse:

hyperfine --runs 5 'gemini -p "what is 2+2?"' 'claude -p "what is 2+2?"'

Benchmark 1: gemini -p "what is 2+2?"
  Time (mean ± σ):     11.187 s ±  1.213 s    [User: 6.464 s, System: 1.602 s]
  Range (min … max):    9.405 s … 12.815 s    5 runs

Benchmark 2: claude -p "what is 2+2?"
  Time (mean ± σ):      7.895 s ±  0.716 s    [User: 8.777 s, System: 5.556 s]
  Range (min … max):    7.329 s …  8.839 s    5 runs

11 seconds to ask “what is 2+2?”. Most of that is startup overhead, not the LLM response time. Claude’s CLI is faster, but still not what you’d call snappy for a simple query.

A help command doesn’t need to scan repositories. It doesn’t need to do anything except print text. This pointed to something broken in the core initialization.

Here’s what’s actually happening: the gemini CLI performs synchronous initialization of “Model Context Protocol” (MCP) servers on every single invocation. It makes blocking network requests to Google’s servers before it even parses your command-line arguments.

You pay the startup tax whether you’re asking it to analyze your codebase or just printing help text.

What’s actually happening under the hood?

To understand where all this time is going, I traced the syscalls using strace:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ------------------
  2.89    0.140270          24      5675           read
  1.10    0.053385          20      2648           close
  0.52    0.025310        2531        10           wait4
  0.39    0.019084          55       341           mmap
  0.28    0.013678         683        20           clone
  ...
------ ----------- ----------- --------- --------- ------------------
100.00    4.846565          37    129681     13312 total

129,681 syscalls to print help text.

For comparison, here’s git --help:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 25.69    0.001488         297         5           openat
 18.30    0.001060          66        16           mmap
  7.94    0.000460         460         1           execve
  ...
------ ----------- ----------- --------- --------- ----------------
100.00    0.005792          90        64         4 total

64 syscalls in 5.8 milliseconds. That’s what a properly designed CLI looks like.

Gemini is making 2,026x more syscalls than git for the same operation. The tool is spawning multiple processes (clone), doing thousands of file reads, and waiting on I/O before it even looks at your command-line flags. This is initialization that should happen after argument parsing, if at all.

The Design Flaw

A CLI tool that makes blocking network calls on startup is fundamentally broken for interactive use. This isn’t a bug to fix, it’s an architectural problem.

Command-line tools should be instant. The entire Unix philosophy is built around composable, fast tools that you can chain together and use interactively. A tool that takes 3-35 seconds to start isn’t a CLI tool, it’s a batch processor with delusions of grandeur.

Yes, I managed to cut the startup time by aggressively ignoring files. But that just masks the real issue: the tool’s initialization is in the wrong place. Network initialization should be lazy, not blocking the entire startup path.

For developer tools, speed isn’t just nice to have. It’s the foundation. Every multi-second pause shatters flow state. At 35 seconds, you might as well not have a CLI at all.

I’m Not Alone

Turns out I’m not the only one frustrated by this. The community has been vocal about these performance issues:

Issue #4544: Performance - Resolve slow startup time (8-12 seconds) - A user on Windows 11 reported 8-12 second delays every time they launched the CLI. The maintainers identified the root cause: synchronous MCP (Model Context Protocol) server initialization blocking startup. The proposed solution breaks down the problem: stop MCP initialization from blocking the UI, but still block the first prompt until servers are ready. This issue spawned three sub-tasks and was eventually closed with PR #8021, but the comments reveal ongoing frustration. One user noted that even without MCP servers configured, the CLI remains painfully slow—suggesting deeper issues beyond just MCP initialization.

Reddit: “Why is the gemini-cli so slow? Am I using it wrong?” - The title says it all. When users start questioning whether they’re using a tool incorrectly because of performance, that’s a UX failure.

Issue #10726: Critical Slowdown - up to 60 seconds - A user reported startup times ballooning to 60 seconds over the course of a month, despite complete reinstallation. Even gemini --help took 6 seconds. Another commenter noted that local commands like gemini MCP list also suffer from awful latency. The maintainers tagged this as priority P1 (important and should be addressed in the near term), but it remains open. One developer succinctly captured the absurdity: “Starting VS Code finishes faster than starting gemini-cli.”

The fact that multiple users independently discovered and reported this—with startup times ranging from 8 to 60 seconds—suggests it’s not a configuration issue or edge case. It’s a fundamental problem with how the tool is architected. When a CLI tool’s performance issues generate multiple bug reports and threads asking “am I doing this wrong?”, that’s a signal. Users expect their tools to be fast. When they’re not, the first instinct is to assume user error—but sometimes the tool really is just slow.