What you'd like to see
providers.*.base_url should support ${env.VAR} interpolation, consistent with how it already works in api_config.endpoint, headers, and other templated fields.
providers:
my_llm:
api_type: openai_chatcompletions
base_url: ${env.LLM_BASE_URL}
token_key: LLM_API_KEYWhy you'd like to see it
Any real deployment has at minimum two environments (local dev and production) where the LLM endpoint differs. The token_key pattern already solves this cleanly for credentials — but the URL that token authenticates against is hardcoded.
Current workarounds are all clunky:
- Bake environment-specific YAMLs into containers
- Use
envsubst in an init container or entrypoint script
- Mount different ConfigMaps per environment in Kubernetes
These defeat the simplicity of a single declarative YAML that can run anywhere.
Context
The env expansion matrix in docs/configuration/overview/index.md already documents that ${env.X} works in api_config.endpoint (toolset-level HTTP calls) but not in providers.*.base_url. The JS template literal expander is already wired up for most HTTP-adjacent fields — extending it to base_url would close the gap.
Related: #2615 (documents the dual-syntax inconsistency), #1123 (requested the same for MCP remote.url, now resolved).
What you'd like to see
providers.*.base_urlshould support${env.VAR}interpolation, consistent with how it already works inapi_config.endpoint,headers, and other templated fields.Why you'd like to see it
Any real deployment has at minimum two environments (local dev and production) where the LLM endpoint differs. The
token_keypattern already solves this cleanly for credentials — but the URL that token authenticates against is hardcoded.Current workarounds are all clunky:
envsubstin an init container or entrypoint scriptThese defeat the simplicity of a single declarative YAML that can run anywhere.
Context
The env expansion matrix in
docs/configuration/overview/index.mdalready documents that${env.X}works inapi_config.endpoint(toolset-level HTTP calls) but not inproviders.*.base_url. The JS template literal expander is already wired up for most HTTP-adjacent fields — extending it tobase_urlwould close the gap.Related: #2615 (documents the dual-syntax inconsistency), #1123 (requested the same for MCP
remote.url, now resolved).