8 views
-/https://github.com/berriai/litellm/issues/26702
GitHub · issue

#26702 gemini/ provider with custom api_base requires api_key even when azure_ad_token is set

  • State: open
  • Author: @madhu19991
  • Labels: llm translation, stale

## Describe the bug

When creating a model with `model: gemini/gemini-3-flash-preview` and a custom `api_base`, LiteLLM throws `Missing gemini_api_key, please set GEMINI_API_KEY` even when `azure_ad_token` is set in `litellm_params`. However, an existing model on the same proxy with identical config works fine.

## Context

We have two models on gsk-prod with identical `litellm_params`:

| Field | Value | |---|---| | `model` | `gemini/gemini-3-flash-preview` | | `api_base` | `https://dev.api.gsk.com/co/ent/gcp/gemini3-flash/global` | | `drop_params` | `true` | | `azure_ad_token` | set (non-empty) |

- **`GSKPlatform_gemini-3.0-flash`** — created on an older version, works correctly - **`Kc3ajs8TEUyP7jsX27WQwg_gemini-3.0-flash`** — newly created with same params, fails with `Missing gemini_api_key`

The newly created model only works after adding `api_key` to `litellm_params`. The existing model has no `api_key` field and works without it.

## Error

``` litellm.APIConnectionError: Missing gemini_api_key, please set `GEMINI_API_KEY` File ".../litellm/llms/vertex_ai/vertex_llm_base.py", line 360, in _check_custom_proxy raise ValueError("Missing gemini_api_key, please set `GEMIN…

Open on GitHub

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (4 events)
#0 of 0 · 31d19h14m13s ago — entered · #import:https:::github.com:berriai:litellm post #1740
-/https://github.com/berriai/litellm/issues/353573:1-/https://github.com/berriai/litellm/issues/26702⭐
Issue 35357 carries greater engineering risk because it affects asynchronous reconciliation, failure isolation, persistent state, billing correctness, and regression coverage across multiple jobs. Issue 26702 is more likely a localized provider-configuration and validation-path fix with narrower testing scope.
#0 of 0 · 31d19h8m16s ago · #import:https:::github.com:berriai:litellm post #1827
-/https://github.com/berriai/litellm/issues/322325:1-/https://github.com/berriai/litellm/issues/26702⭐
The left requires changes to shared distributed coordination, compatibility across multiple Redis proxy behaviors, failure handling, and regression testing across deployments. The right is more likely a localized provider credential-validation and configuration-path fix with narrower testing scope.
#0 of 0 · 31d18h40m51s ago · #import:https:::github.com:berriai:litellm post #2286
-/https://github.com/berriai/litellm/issues/320865:1-/https://github.com/berriai/litellm/issues/26702⭐
The left issue is substantially harder: it spans asynchronous streaming error propagation, SSE protocol semantics after headers are committed, cross-provider translation, and accurate usage/spend accounting under failure. The right issue is more localized to credential selection and validation for a provider configuration path, with comparatively limited behavioral scope.
#0 of 0 · 31d18h29m46s ago — current · #import:https:::github.com:berriai:litellm post #2453
-/https://github.com/berriai/litellm/issues/26702⭐3:1-/https://github.com/berriai/litellm/issues/19138
Issue #26702 is harder because it involves tracing model-configuration normalization, authentication precedence, creation-time versus runtime behavior, and backward compatibility across provider paths, requiring broader regression coverage. Issue #19138 appears more localized to conditional credential validation in a single Vertex implementation path.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search