Gemini CLI 404: two causes, both in the URL
You exported a key and a base URL, restarted the terminal, ran gemini — and the first request comes back:
404 Not Found
or, depending on the client, Cannot resolve or not found. The key is fine; a 404 is not an auth failure. It is a path that does not exist, and with Gemini CLI there are two ways to produce one.
https://aicomp.ai/v1).
Create one free →
Cause 1: the API version the CLI asks for by default
Gemini CLI uses API version v1beta by default. If the endpoint you pointed it at serves v1, every request goes to a v1beta path that does not exist, and you get a 404 on a perfectly valid key.
The fix is to force the version:
export GEMINI_API_KEY="your-gateway-key"
export GOOGLE_GEMINI_BASE_URL="https://aicomp.ai/v1"
export GOOGLE_GENAI_API_VERSION="v1"
This is the one that is hardest to find by reading the error, because nothing in 404 Not Found mentions a version. It also presents as intermittent in a specific way: anything that goes through a path you did define works, while model listing and generation fail.
Confirm what the CLI is actually requesting before changing anything else:
echo "$GOOGLE_GEMINI_BASE_URL" # must be set in *this* shell
echo "$GOOGLE_GENAI_API_VERSION" # empty means v1beta
gemini --version
Cause 2: a double slash
The most commonly reported 404 on a Gemini base URL is a trailing slash meeting a leading one. The CLI appends its own path to whatever you supply, so a base URL ending in / produces:
https://example.com/v1beta/openai//chat/completions
That double slash is a different path, and it 404s. https://example.com/v1beta/openai/ with a trailing slash and https://example.com/v1beta/openai without one are not interchangeable.
The same caution applies in the other direction: do not append /v1 yourself to a base URL that already implies it, and do not paste a dashboard or landing-page address into the variable. The address you use to sign up and check usage is not the address the API is served on.
When the 404 is actually a login problem
If setting the key still drops you into a Google sign-in flow, the CLI did not recognise the key and fell back to OAuth. Two things cause it:
The variable is not set in the shell that launched gemini. Shell profile changes do not reach an already-open terminal. Verify with echo "$GEMINI_API_KEY". Non-empty, and note that an empty value behaves exactly like an unset one.
The base URL override only applies in API-key mode. GOOGLE_GEMINI_BASE_URL is honoured when the CLI is using a Gemini API key. Google OAuth and Vertex modes have their own configuration and ignore it, so in those modes your endpoint is never used and the 404 is the least of the problem.
The neighbour status codes
| Code | What it means | What to check |
|---|---|---|
404 | Path does not exist | API version (v1beta vs v1), double slash, trailing /v1 |
403 / Invalid API Key | Key not accepted by this endpoint | Which system issued the key; stray quotes or spaces from pasting |
401 | Key incomplete or revoked | Re-issue the key; check it was copied whole |
429 | Request rate, not a path | See the rate-limit guide for your tool |
A 403 is worth separating from a 404 because the fixes are unrelated: a 404 is your URL, a 403 is your credential. And a key issued by one system is not valid on another. A Google AI Studio key will not authenticate against a gateway, and vice versa, even though both are "Gemini keys".
Verify the endpoint before blaming the CLI
One request settles whether the endpoint is the problem or the config is:
curl -s -o /dev/null -w "%{http_code}\n" \
"$GOOGLE_GEMINI_BASE_URL/models" \
-H "x-goog-api-key: $GEMINI_API_KEY"
A 200 means the base URL and key are both accepted and the remaining problem is in the CLI's config. A 404 means the path is wrong. A 401 or 403 means the credential is. Do this first It separates three failures that produce the same message inside the CLI.
Then restart the terminal, or source the profile, and try a short prompt. Config changes do not reach a running process.
FAQ
FAQ
Why does Gemini CLI 404 when my key works in curl?
Because curl and the CLI may be requesting different API versions. Gemini CLI uses v1beta by default; if your endpoint serves v1, the CLI's path does not exist while your hand-written one does. Set GOOGLE_GENAI_API_VERSION="v1".
Does the base URL need a trailing slash?
No, and adding one is a common cause of 404. The CLI appends its own path, so a base URL ending in / produces a double slash, a different path that does not resolve.
I set `GEMINI_API_KEY` but Gemini still opens a Google login
The CLI did not pick up the key and fell back to OAuth. Check echo "$GEMINI_API_KEY" in the same terminal that launches gemini (profile changes do not reach already-open shells). Also note that GOOGLE_GEMINI_BASE_URL only applies in API-key mode, not OAuth or Vertex.
Should the base URL end in `/v1`?
Only if the endpoint's path requires it, and not if the value you were given already implies it. Gemini's native generation path is /v1beta/models/{model}:generateContent, which is a different shape from the OpenAI-compatible /v1/chat/completions, appending the wrong one produces a 404.
Is a 403 the same problem as a 404?
No. A 404 is the path; a 403 is the credential. A 403 usually means the key was issued by a different system than the one you are calling (an AI Studio key will not authenticate against a gateway).
How do I check the endpoint independently of the CLI?
Request the models list with curl and read the status code. 200 means URL and key are fine and the problem is in the CLI config; 404 means path; 401 or 403 means credential.
Related
- Gemini API base URL — where the base URL goes and what it replaces
- OpenAI-compatible error codes — what each status means across tools
- Base URL not working — the generic version of this diagnosis
- Model fallback chain — routing when a model is unavailable
- Cursor 429 rate limit — when the answer is 429 rather than 404
- Model price index — check which models the endpoint exposes