Bug Description
When using /model to switch to a model served via a custom provider (e.g. custom:xuanji), and the model name also exists in a native provider's static catalog (e.g. deepseek-v4-pro exists in the native deepseek provider catalog), running /new fails with:
error: agent init failed: Provider 'deepseek' is set in config.yaml but no API key was found.
Set the DEEPSEEK_API_KEY environment variable, or switch to a different provider with `hermes model`.
Steps to Reproduce
- Configure a custom provider (e.g.
custom:xuanji) with models like deepseek-v4-pro
- In TUI, run
/model deepseek-v4-pro — switches successfully to custom:xuanji
- Run
/new — fails with the error above
Root Cause
In tui_gateway/server.py, _resolve_startup_runtime() (line ~628):
/model correctly sets HERMES_MODEL=deepseek-v4-pro and HERMES_INFERENCE_PROVIDER=custom:xuanji in env vars
- On
/new, _resolve_startup_runtime() detects HERMES_MODEL is set (line 634-637)
- It reads
config.model.provider (custom:xuanji) as current_provider (line 644-652)
- It calls
detect_static_provider_for_model("deepseek-v4-pro", "custom:xuanji") (line 654)
- Since
custom:xuanji has no static catalog, _model_in_provider_catalog() returns False
- The function iterates all native provider catalogs and matches
deepseek-v4-pro to the native deepseek provider
- Returns
("deepseek", "deepseek-v4-pro"), overriding the correct custom:xuanji provider
resolve_runtime_provider then fails because DEEPSEEK_API_KEY is not set
Note: This bug is masked for models like claude-opus-4-7 if ANTHROPIC_API_KEY happens to be set — the wrong provider is used but authentication succeeds by coincidence.
Expected Behavior
/new should respect the HERMES_INFERENCE_PROVIDER env var set by /model, since it represents the user's explicit provider choice.
Suggested Fix
In _resolve_startup_runtime(), check HERMES_INFERENCE_PROVIDER before falling through to detect_static_provider_for_model():
# If /model set HERMES_INFERENCE_PROVIDER, honour it directly
inference_provider = os.environ.get("HERMES_INFERENCE_PROVIDER", "").strip()
if inference_provider:
return model, inference_provider
This should be inserted after the HERMES_TUI_PROVIDER check (line 630-632) and before the static detection logic.
Environment
- Hermes Agent TUI mode
- Custom provider with models that share names with native provider catalogs
Bug Description
When using
/modelto switch to a model served via a custom provider (e.g.custom:xuanji), and the model name also exists in a native provider's static catalog (e.g.deepseek-v4-proexists in the nativedeepseekprovider catalog), running/newfails with:Steps to Reproduce
custom:xuanji) with models likedeepseek-v4-pro/model deepseek-v4-pro— switches successfully tocustom:xuanji/new— fails with the error aboveRoot Cause
In
tui_gateway/server.py,_resolve_startup_runtime()(line ~628):/modelcorrectly setsHERMES_MODEL=deepseek-v4-proandHERMES_INFERENCE_PROVIDER=custom:xuanjiin env vars/new,_resolve_startup_runtime()detectsHERMES_MODELis set (line 634-637)config.model.provider(custom:xuanji) ascurrent_provider(line 644-652)detect_static_provider_for_model("deepseek-v4-pro", "custom:xuanji")(line 654)custom:xuanjihas no static catalog,_model_in_provider_catalog()returns Falsedeepseek-v4-proto the nativedeepseekprovider("deepseek", "deepseek-v4-pro"), overriding the correctcustom:xuanjiproviderresolve_runtime_providerthen fails becauseDEEPSEEK_API_KEYis not setNote: This bug is masked for models like
claude-opus-4-7ifANTHROPIC_API_KEYhappens to be set — the wrong provider is used but authentication succeeds by coincidence.Expected Behavior
/newshould respect theHERMES_INFERENCE_PROVIDERenv var set by/model, since it represents the user's explicit provider choice.Suggested Fix
In
_resolve_startup_runtime(), checkHERMES_INFERENCE_PROVIDERbefore falling through todetect_static_provider_for_model():This should be inserted after the
HERMES_TUI_PROVIDERcheck (line 630-632) and before the static detection logic.Environment