Bug Description
When the active provider in config.yaml is set to bare "custom", the /model picker (both in the WebUI Dashboard and gateway-based UIs like Telegram/Discord) displays a different provider as the current one instead of the actual custom provider.
For example, if the user's active provider is "custom" pointing to a local Ollama/llama-swap instance, the picker may show copilot (or another built-in provider) with the ● current marker, while the actual custom provider is shown as a non-current option.
Root Cause
The issue is in hermes_cli/model_switch.py in the list_authenticated_providers() function, specifically in the custom providers section (section 4).
When a custom provider's base_url matches the currently active endpoint, the slug is resolved correctly but the is_current check fails:
Line ~1672:
"is_current": slug == current_provider,
When current_provider == "custom" and the slug resolves to "custom:llama-swap" (or similar custom:<name> form), the comparison "custom:llama-swap" == "custom" evaluates to False, so the actual custom provider is not marked as current.
The slug resolution at lines 1594-1601 handles the transition from bare "custom" to the canonical "custom:<name>" form, but the is_current check at line 1672 only does a direct string comparison, missing this resolution path.
Expected Behavior
When current_provider is "custom" and a custom provider group matches the active current_base_url, that provider group should be marked as is_current: true regardless of the slug resolution ("custom" vs "custom:llama-swap").
Reproduction Steps
- Configure a custom provider in
config.yaml with a local endpoint (e.g., Ollama, llama-swap)
- Set the active provider to
"custom"
- Open the
/model picker (in WebUI or any gateway UI)
- Observe that the actual custom endpoint is not highlighted as the current provider
Suggested Fix
Update the is_current check in section 4 to also match when the group's api_url matches current_base_url:
results.append({
"slug": slug,
"name": grp["name"],
"is_current": slug == current_provider or (
current_base_url and
str(grp["api_url"]).strip().rstrip("/") == current_base_url.strip().rstrip("/")
),
"is_user_defined": True,
...
})
This ensures the match works regardless of whether current_provider is the bare "custom" string or the resolved "custom:<name>" slug.
Impact
- Affects all gateway UIs (WebUI Dashboard, Telegram, Discord, etc.) that use the
/model picker
- Users may accidentally switch providers thinking they are selecting the current one
- Provider picker sorting is affected (
is_current controls sort priority at line 1683)
Bug Description
When the active provider in config.yaml is set to bare
"custom", the/modelpicker (both in the WebUI Dashboard and gateway-based UIs like Telegram/Discord) displays a different provider as the current one instead of the actual custom provider.For example, if the user's active provider is
"custom"pointing to a local Ollama/llama-swap instance, the picker may showcopilot(or another built-in provider) with the● currentmarker, while the actual custom provider is shown as a non-current option.Root Cause
The issue is in
hermes_cli/model_switch.pyin thelist_authenticated_providers()function, specifically in the custom providers section (section 4).When a custom provider's
base_urlmatches the currently active endpoint, the slug is resolved correctly but theis_currentcheck fails:Line ~1672:
When
current_provider == "custom"and the slug resolves to"custom:llama-swap"(or similarcustom:<name>form), the comparison"custom:llama-swap" == "custom"evaluates toFalse, so the actual custom provider is not marked as current.The slug resolution at lines 1594-1601 handles the transition from bare
"custom"to the canonical"custom:<name>"form, but theis_currentcheck at line 1672 only does a direct string comparison, missing this resolution path.Expected Behavior
When
current_provideris"custom"and a custom provider group matches the activecurrent_base_url, that provider group should be marked asis_current: trueregardless of the slug resolution ("custom"vs"custom:llama-swap").Reproduction Steps
config.yamlwith a local endpoint (e.g., Ollama, llama-swap)"custom"/modelpicker (in WebUI or any gateway UI)Suggested Fix
Update the
is_currentcheck in section 4 to also match when the group'sapi_urlmatchescurrent_base_url:This ensures the match works regardless of whether
current_provideris the bare"custom"string or the resolved"custom:<name>"slug.Impact
/modelpickeris_currentcontrols sort priority at line 1683)