Background
Currently, both the client and agents (tau2, proxy-agent) rely on LiteLLM for model access. LiteLLM reads configuration from global environment variables (e.g., OPENAI_API_KEY, OPENAI_BASE_URL), which makes it difficult to differentiate credentials and endpoints between components.
In practice, we need the ability to configure different LLM providers, API keys, and base URLs independently for:
- Client
- tau2 agent
- proxy-agent
This is especially important in scenarios such as:
Using different providers per component (e.g., OpenAI for client, Azure/OpenAI-compatible proxy for agents)
Routing agent traffic through internal gateways / proxies
Applying different rate limits, auditing, or billing scopes
Supporting multi-tenant or environment-specific configurations
Problem
Both tau2 and proxy-agent currently inherit the same global OPENAI_* environment variables via LiteLLM, which:
- Prevents isolating credentials between components
- Forces all components to use the same base URL and API key
- Creates conflicts when different configurations are required simultaneously
Proposed Solution
Introduce explicit, per-component LLM configuration support.
Option 1: Namespaced Environment Variables
Allow defining separate environment variables for each component, for example:
# Client
SB_CLIENT_OPENAI_API_KEY=
SB_CLIENT_OPENAI_BASE_URL=
# Tau2
SB_TAU2_OPENAI_API_KEY=
SB_TAU2_OPENAI_BASE_URL=
# Proxy Agent
SB_SPA_AGENT_OPENAI_API_KEY=
SB_SPA_OPENAI_BASE_URL=
Each component should initialize LiteLLM with its own configuration instead of relying on global OPENAI_* variables.
Background
Currently, both the client and agents (tau2, proxy-agent) rely on LiteLLM for model access. LiteLLM reads configuration from global environment variables (e.g., OPENAI_API_KEY, OPENAI_BASE_URL), which makes it difficult to differentiate credentials and endpoints between components.
In practice, we need the ability to configure different LLM providers, API keys, and base URLs independently for:
This is especially important in scenarios such as:
Using different providers per component (e.g., OpenAI for client, Azure/OpenAI-compatible proxy for agents)
Routing agent traffic through internal gateways / proxies
Applying different rate limits, auditing, or billing scopes
Supporting multi-tenant or environment-specific configurations
Problem
Both tau2 and proxy-agent currently inherit the same global OPENAI_* environment variables via LiteLLM, which:
Proposed Solution
Introduce explicit, per-component LLM configuration support.
Option 1: Namespaced Environment Variables
Allow defining separate environment variables for each component, for example:
Each component should initialize LiteLLM with its own configuration instead of relying on global OPENAI_* variables.