Feature Request: First-Class Integration for ZenMux Provider
Is your feature request related to a problem? Please describe.
Currently, to use ZenMux as an LLM provider in DeepSeek-TUI, users must piggyback on the generic openai provider by overriding the base URL:
export OPENAI_BASE_URL="https://zenmux.ai/api/v1"
deepseek --provider openai --model deepseek-v4-pro
While this workaround is fully functional (I have tested and verified it locally with deepseek-v4-pro), it would be much more seamless for users if ZenMux were treated as a first-class provider, similar to how nvidia-nim, fireworks, openrouter, and novita are currently implemented.
Describe the solution you'd like
I propose adding a native zenmux integration to the codebase. This would involve:
- Dedicated Provider Profile: Adding
zenmux to the Provider enum in the core configuration.
- Native Environment Variables: Supporting
ZENMUX_API_KEY and ZENMUX_BASE_URL (defaulting to https://zenmux.ai/api/v1).
- CLI/Auth Support: Allowing users to authenticate directly via:
deepseek auth set --provider zenmux --api-key "sk-..."
- TUI Integration: Adding ZenMux to the
/model interactive selector in the TUI so users can easily discover and switch to models hosted on ZenMux.
Describe alternatives you've considered
Continuing to use the openai provider. The downside is that this prevents users from simultaneously configuring an actual OpenAI endpoint and a ZenMux endpoint without constantly swapping environment variables or config files.
Additional context
ZenMux provides excellent access to DeepSeek models (like deepseek-v4-pro). Adding native support will improve the out-of-the-box experience for users who rely on it as their primary model host.
Feature Request: First-Class Integration for ZenMux Provider
Is your feature request related to a problem? Please describe.
Currently, to use ZenMux as an LLM provider in DeepSeek-TUI, users must piggyback on the generic
openaiprovider by overriding the base URL:While this workaround is fully functional (I have tested and verified it locally with
deepseek-v4-pro), it would be much more seamless for users if ZenMux were treated as a first-class provider, similar to hownvidia-nim,fireworks,openrouter, andnovitaare currently implemented.Describe the solution you'd like
I propose adding a native
zenmuxintegration to the codebase. This would involve:zenmuxto theProviderenum in the core configuration.ZENMUX_API_KEYandZENMUX_BASE_URL(defaulting tohttps://zenmux.ai/api/v1).deepseek auth set --provider zenmux --api-key "sk-..."/modelinteractive selector in the TUI so users can easily discover and switch to models hosted on ZenMux.Describe alternatives you've considered
Continuing to use the
openaiprovider. The downside is that this prevents users from simultaneously configuring an actual OpenAI endpoint and a ZenMux endpoint without constantly swapping environment variables or config files.Additional context
ZenMux provides excellent access to DeepSeek models (like
deepseek-v4-pro). Adding native support will improve the out-of-the-box experience for users who rely on it as their primary model host.