What happened?

Description: The Gemini CLI currently ignores the GOOGLE_GEMINI_BASE_URL environment variable if a cached Google session or specific model flag is present. This prevents developers from using the CLI as a frontend for local-first workflows (e.g., Ollama, LiteLLM, or local mock servers), even when the GEMINI_API_KEY is set to a local development key.

Steps to Reproduce:

Set local environment variables:

Bash

export GOOGLE_GEMINI_BASE_URL="http://localhost:4000"
export GEMINI_API_KEY="local-dev-key"
Attempt to run a prompt against a local model:

Bash

gemini -m gemini-1.5-pro -p "test"
Observe the CLI bypassing the local URL to load "cached credentials" and hitting Google's production servers, resulting in 404s or "High Demand" errors.

What did you expect to happen?

Expected Behavior: The CLI should respect GOOGLE_GEMINI_BASE_URL as a top-priority override for the API endpoint, allowing the tool to function with OpenAI-compatible local proxies (LiteLLM/Ollama).

Environment Details:

OS: macOS (Apple Silicon M4)

CLI Version: [Run gemini --version and paste here]

Auth Method: Local API Key / Environment Variables

Additional Context: On high-performance local hardware like the Mac Studio, we want to leverage the Gemini CLI’s excellent TUI and agentic features with local models. Currently, the CLI appears hardcoded to generativelanguage.googleapis.com regardless of environment overrides.

Client information

> /about
# paste output here

Login information

API key

Anything else we need to know?

Congrats on the success of Gemini 3!! Your new constraints for my tier cut my output by more than 80%. It would really help stay with Gemini and Gemini CLI if I could pivot to a local LLM when I hit my cloud API limit. I can't afford to use the Vortex API, at least not yet. I now others have pointed Gemini CLI to local ollama, but I could not get it to work on my Mac.

Thank you for your great work!