I'll be the first to admit I won't be much help in fixing this stuff. I was troubleshooting with Claude's assistance here and had it write this summary. I'll try to provide follow up information as I can. I ran across this because last night, everything was working fine, and this morning when I fired up the webui, all of my local models (llama.cpp) disappeared.
Summary
When custom_providers entries in config.yaml include a models dict listing multiple models, only the singular model field is added to the WebUI model dropdown. The models dict is parsed by YAML but never iterated for dropdown population.
Reproduction
custom_providers:
- name: Llama-swap:8880
base_url: http://llama-swap:8880/v1
model: unsloth-qwen3.6-35b-a3b
models:
unsloth-qwen3.6-35b-a3b:
context_length: 262144
gemma4-26b: {}
qwen3.5-27b: {}
qwen3-coder-30b: {}
Expected: all four models appear in the dropdown under the custom provider group.
Actual: only unsloth-qwen3.6-35b-a3b (from the model field) appears.
Root cause
api/config.py, in the _build_available_models_uncached() function (~line 1570):
for _cp in _custom_providers_cfg:
if not isinstance(_cp, dict):
continue
_cp_model = _cp.get("model", "") # <-- only reads singular 'model'
_cp_name = (_cp.get("name") or "").strip()
if _cp_model and _cp_model not in _seen_custom_ids:
# ... adds only this one model
The code never reads _cp.get("models") to iterate additional model entries. This is the fallback path used when the base_url auto-detect fails (e.g. due to the SSRF check in #[SSRF issue number]), so it's the only path that could populate models from config alone.
Expected behavior
The loop should also iterate _cp.get("models", {}) keys and add each as a selectable model in the dropdown, falling back to the model ID as the label.
Relationship to other issues
This compounds with the SSRF false-positive issue (#[SSRF issue number]): when auto-detect is blocked, custom_providers is the only fallback, but it only picks up one model. Users who carefully list all their models in config still get an incomplete dropdown.
Environment
- hermes-webui: latest (ghcr.io/nesquena/hermes-webui:latest, pulled 2026-04-26)
- custom_providers configured with llama-swap serving 7+ models
I'll be the first to admit I won't be much help in fixing this stuff. I was troubleshooting with Claude's assistance here and had it write this summary. I'll try to provide follow up information as I can. I ran across this because last night, everything was working fine, and this morning when I fired up the webui, all of my local models (llama.cpp) disappeared.
Summary
When
custom_providersentries inconfig.yamlinclude amodelsdict listing multiple models, only the singularmodelfield is added to the WebUI model dropdown. Themodelsdict is parsed by YAML but never iterated for dropdown population.Reproduction
Expected: all four models appear in the dropdown under the custom provider group.
Actual: only
unsloth-qwen3.6-35b-a3b(from themodelfield) appears.Root cause
api/config.py, in the_build_available_models_uncached()function (~line 1570):The code never reads
_cp.get("models")to iterate additional model entries. This is the fallback path used when the base_url auto-detect fails (e.g. due to the SSRF check in #[SSRF issue number]), so it's the only path that could populate models from config alone.Expected behavior
The loop should also iterate
_cp.get("models", {})keys and add each as a selectable model in the dropdown, falling back to the model ID as the label.Relationship to other issues
This compounds with the SSRF false-positive issue (#[SSRF issue number]): when auto-detect is blocked,
custom_providersis the only fallback, but it only picks up one model. Users who carefully list all their models in config still get an incomplete dropdown.Environment