Support for Environment-Driven Endpoint Configuration (base_url)

[vidai-n]

Summary:
ADK currently does a fantastic job of following a "Code-First, Environment-Aware" philosophy. We specify our agent logic in code, and ADK gracefully picks up environment-specific infrastructure details like API_KEY, PROJECT_ID, and LOCATION from standard environment variables.

However, as ADK moves into more complex enterprise environments—where traffic is often routed through sovereign AI gateways, observability proxies (like Vidai or Helicone or Portkey), or specialized logging servers—the Endpoint URL (base_url) has become as much a part of the "Infrastructure Environment" as the API Key itself.

The Question:
Does it align with ADK's architectural vision to extend its environment-discovery logic to include endpoint redirection? Specifically, would the team be open to a proposal that introduces a framework-wide global fallback (ADK_LLM_BASE_URL) coupled with support for industry-standard SDK variables (like LITELLM_API_BASE or ANTHROPIC_BASE_URL)?

Why we believe this makes sense:

• Environment Parity: Moving code from a local developer machine (hitting public APIs) to a production cluster (hitting a secure proxy) currently requires code changes to the model initialization. Allowing this to be handled via the environment aligns with Infrastructure-as-Code (IaC) best practices.

• Provider Harmony: Organizations often use a mix of native models (Gemini) and variety-focused adapters (LiteLLM). These often require different pathing conventions (e.g., Domain Root vs. /v1). Exposing these through the environment allows for cleaner "Mixed-Model" orchestration without bespoke path-manipulation hacks in the source code.

• Observability & Compliance: Standardizing base_url discovery enables developers to drop ADK into existing observability and compliance pipelines that rely on transparent traffic redirection.

We have been exploring a minimalist, non-opinionated pass-through implementation for this that respects the native protocols of each SDK. We'd love to hear the team's thoughts on whether this is a direction you'd like to see in a PR!

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: This is an excellent proposal that aligns with ADK's design philosophy. While there's no global environment variable for base_url today, the framework already uses them for other configurations, and your suggestion is a logical next step that could enhance enterprise adoption and simplify CI/CD workflows.

---

Thank you for this detailed and well-reasoned feature proposal. You've correctly identified that ADK follows a "Code-First, Environment-Aware" philosophy, using environment variables to separate configuration from code. [1, 2]

Your observation is accurate: currently, there is no framework-wide support for configuring a model's base_url via environment variables. As you noted, moving between environments often requires code changes, such as passing an api_base parameter when initializing models from providers like LiteLLM or vLLM. [3, 4, 5]

However, your suggestion fits perfectly with existing patterns in the framework:

• Environment-Based Backends: ADK already uses GOOGLE_GENAI_USE_VERTEXAI to switch the underlying backend to Vertex AI without code changes. [6]
• Plugin-Specific Precedent: Some integrations already use this exact pattern. For example, the GoodMem plugin can be configured with a GOODMEM_BASE_URL environment variable. [7]
• Simplified Model Selection: The DEMO_AGENT_MODEL environment variable in sample agents allows for easy switching of models, further showing the framework's reliance on environment-based configuration. [8]

Introducing a global ADK_LLM_BASE_URL and respecting provider-specific variables (e.g., LITELLM_API_BASE) would be a natural and valuable extension of this design. It would lower the barrier for use in enterprise environments with proxies and gateways, just as you described.

We believe this is a fantastic suggestion and appreciate you taking the time to outline the benefits so clearly.

[1] https://github.com/google/adk-python/blob/main/contributing/samples/adk_pr_triaging_agent/README.md
[2] https://google.github.io/adk-docs/streaming/dev-guide/part5/
[3] https://google.github.io/adk-docs/agents/models/google-gemma/
[4] https://google.github.io/adk-docs/agents/models/vllm/
[5] https://google.github.io/adk-docs/agents/models/litert-lm/
[6] https://google.github.io/adk-docs/agents/models/vertex/
[7] https://google.github.io/adk-docs/integrations/goodmem/
[8] https://google.github.io/adk-docs/streaming/dev-guide/part1/

[vidai-n]

@Jacksunwei @seanzhougoogle - could you please give your inputs.