fix(fallback): look up custom_providers base_url before fallback API call by Feranmi10 · Pull Request #17827 · NousResearch/hermes-agent

Feranmi10 · 2026-04-30T08:10:34Z

What does this PR do?

Fixes a bug where fallback providers defined in custom_providers send requests to the wrong endpoint — they inherit the primary provider's base_url instead of using their own.

Root cause: Two gaps in the fallback resolution path:

_try_activate_fallback in run_agent.py only reads base_url from the fallback entry itself. When absent, it stays None. If the provider name aliases to a built-in (e.g. a custom provider named "kimi" → normalizes to "kimi-coding"), _get_named_custom_provider returns None and the code falls through to the PROVIDER_REGISTRY path — using the primary provider's endpoint.
resolve_provider_client in agent/auxiliary_client.py ignores explicit_base_url and explicit_api_key in the API-key provider path, so even when hints are passed, the built-in endpoint wins.

Fix:

In run_agent.py: when fb_base_url_hint is absent, call _get_named_custom_provider(fb_provider) with the original pre-normalization name to find the custom entry and populate fb_base_url_hint and fb_api_key_hint correctly.
In agent/auxiliary_client.py: honour explicit_base_url and explicit_api_key in the API-key provider path so the custom endpoint is always used when provided.

Related Issue

Fixes #15743

Type of Change

Bug fix

…call When a fallback_model entry names a provider defined in custom_providers but omits an explicit base_url, the resolution path skipped the custom_providers lookup entirely. If the provider name happened to alias to a built-in (e.g. "kimi" -> "kimi-coding"), _get_named_custom_provider would return None inside resolve_provider_client (because auth.resolve_provider succeeds for aliases and short-circuits the search), and the code fell through to the PROVIDER_REGISTRY path which used the built-in endpoint — typically the same as the primary provider's base_url. Fix (_try_activate_fallback in run_agent.py): when fb_base_url_hint is absent, call _get_named_custom_provider with the original fb_provider name (pre-normalization) so the custom_providers entry is found even when the name aliases to a registered built-in. api_key and key_env are resolved from the same entry. Fix (resolve_provider_client in agent/auxiliary_client.py): in the API-key provider path, honour explicit_base_url and explicit_api_key when provided so that the correct custom endpoint is used even after the provider name has been normalised to a built-in alias.

alt-glitch · 2026-04-30T08:29:57Z

Competes with #15756 — both fix #15743 (fallback provider ignoring custom_providers base_url). This PR also addresses auxiliary_client.py explicit_base_url/api_key passthrough.

@Feranmi10

When a user defines `custom_providers: [{name: kimi, ...}]` and references `provider: kimi` from fallback_model or the main config, the built-in alias rewriting (`kimi` → `kimi-coding`) was hijacking the request before the named-custom lookup ran. `_get_named_custom_provider` also refused to return a match when the raw name resolved to any built-in (including aliases), so the custom endpoint was unreachable. Fix at both layers of the resolution chain so every caller benefits, not just `_try_activate_fallback`: - hermes_cli/runtime_provider.py: narrow `_get_named_custom_provider`'s built-in-wins guard to canonical provider names only. An alias like `kimi` that resolves to a different canonical (`kimi-coding`) no longer blocks the custom lookup; a canonical name like `nous` still does. - agent/auxiliary_client.py: in `resolve_provider_client`, try the named- custom lookup with the original (pre-alias-normalization) name before the alias-normalized one, so aliased requests reach the user's custom entry. Also honour `explicit_base_url` and `explicit_api_key` in the API-key provider branch so callers that pass explicit hints (e.g. fallback activation) can override the registered defaults. Tests added for: - custom `kimi` shadowing built-in alias (regression for #15743) - custom `nous` NOT shadowing canonical built-in (behaviour preserved) - bare `kimi` without any custom entry still routing to built-in - explicit base_url/api_key override on the API-key provider branch Original PR #17827 by @Feranmi10 identified the same bug class and implemented a narrower fix in `_try_activate_fallback`; this reshapes the fix to live in the shared resolution layer so all callers benefit. Fixes #15743 Co-authored-by: Feranmi10 <89228157+Feranmi10@users.noreply.github.com>

@Feranmi10

When a user defines `custom_providers: [{name: kimi, ...}]` and references `provider: kimi` from fallback_model or the main config, the built-in alias rewriting (`kimi` → `kimi-coding`) was hijacking the request before the named-custom lookup ran. `_get_named_custom_provider` also refused to return a match when the raw name resolved to any built-in (including aliases), so the custom endpoint was unreachable. Fix at both layers of the resolution chain so every caller benefits, not just `_try_activate_fallback`: - hermes_cli/runtime_provider.py: narrow `_get_named_custom_provider`'s built-in-wins guard to canonical provider names only. An alias like `kimi` that resolves to a different canonical (`kimi-coding`) no longer blocks the custom lookup; a canonical name like `nous` still does. - agent/auxiliary_client.py: in `resolve_provider_client`, try the named- custom lookup with the original (pre-alias-normalization) name before the alias-normalized one, so aliased requests reach the user's custom entry. Also honour `explicit_base_url` and `explicit_api_key` in the API-key provider branch so callers that pass explicit hints (e.g. fallback activation) can override the registered defaults. Tests added for: - custom `kimi` shadowing built-in alias (regression for #15743) - custom `nous` NOT shadowing canonical built-in (behaviour preserved) - bare `kimi` without any custom entry still routing to built-in - explicit base_url/api_key override on the API-key provider branch Original PR #17827 by @Feranmi10 identified the same bug class and implemented a narrower fix in `_try_activate_fallback`; this reshapes the fix to live in the shared resolution layer so all callers benefit. Fixes #15743 Co-authored-by: Feranmi10 <89228157+Feranmi10@users.noreply.github.com>

teknium1 · 2026-05-01T03:19:04Z

Thanks @Feranmi10 — your PR identified the real bug and fix direction. Merged via #18185, which reshapes the fix to live in the shared resolution layer (_get_named_custom_provider + resolve_provider_client) so every caller benefits, not just _try_activate_fallback. Your authorship is preserved via Co-authored-by: on the merge commit 0ddc8ab. The explicit base_url/api_key hardening in _wrap_if_needed you wrote is in there too. Appreciate the clear bug analysis in the description.

@Feranmi10

When a user defines `custom_providers: [{name: kimi, ...}]` and references `provider: kimi` from fallback_model or the main config, the built-in alias rewriting (`kimi` → `kimi-coding`) was hijacking the request before the named-custom lookup ran. `_get_named_custom_provider` also refused to return a match when the raw name resolved to any built-in (including aliases), so the custom endpoint was unreachable. Fix at both layers of the resolution chain so every caller benefits, not just `_try_activate_fallback`: - hermes_cli/runtime_provider.py: narrow `_get_named_custom_provider`'s built-in-wins guard to canonical provider names only. An alias like `kimi` that resolves to a different canonical (`kimi-coding`) no longer blocks the custom lookup; a canonical name like `nous` still does. - agent/auxiliary_client.py: in `resolve_provider_client`, try the named- custom lookup with the original (pre-alias-normalization) name before the alias-normalized one, so aliased requests reach the user's custom entry. Also honour `explicit_base_url` and `explicit_api_key` in the API-key provider branch so callers that pass explicit hints (e.g. fallback activation) can override the registered defaults. Tests added for: - custom `kimi` shadowing built-in alias (regression for NousResearch#15743) - custom `nous` NOT shadowing canonical built-in (behaviour preserved) - bare `kimi` without any custom entry still routing to built-in - explicit base_url/api_key override on the API-key provider branch Original PR NousResearch#17827 by @Feranmi10 identified the same bug class and implemented a narrower fix in `_try_activate_fallback`; this reshapes the fix to live in the shared resolution layer so all callers benefit. Fixes NousResearch#15743 Co-authored-by: Feranmi10 <89228157+Feranmi10@users.noreply.github.com>

@Feranmi10

When a user defines `custom_providers: [{name: kimi, ...}]` and references `provider: kimi` from fallback_model or the main config, the built-in alias rewriting (`kimi` → `kimi-coding`) was hijacking the request before the named-custom lookup ran. `_get_named_custom_provider` also refused to return a match when the raw name resolved to any built-in (including aliases), so the custom endpoint was unreachable. Fix at both layers of the resolution chain so every caller benefits, not just `_try_activate_fallback`: - hermes_cli/runtime_provider.py: narrow `_get_named_custom_provider`'s built-in-wins guard to canonical provider names only. An alias like `kimi` that resolves to a different canonical (`kimi-coding`) no longer blocks the custom lookup; a canonical name like `nous` still does. - agent/auxiliary_client.py: in `resolve_provider_client`, try the named- custom lookup with the original (pre-alias-normalization) name before the alias-normalized one, so aliased requests reach the user's custom entry. Also honour `explicit_base_url` and `explicit_api_key` in the API-key provider branch so callers that pass explicit hints (e.g. fallback activation) can override the registered defaults. Tests added for: - custom `kimi` shadowing built-in alias (regression for NousResearch#15743) - custom `nous` NOT shadowing canonical built-in (behaviour preserved) - bare `kimi` without any custom entry still routing to built-in - explicit base_url/api_key override on the API-key provider branch Original PR NousResearch#17827 by @Feranmi10 identified the same bug class and implemented a narrower fix in `_try_activate_fallback`; this reshapes the fix to live in the shared resolution layer so all callers benefit. Fixes NousResearch#15743 Co-authored-by: Feranmi10 <89228157+Feranmi10@users.noreply.github.com>

@Feranmi10

When a user defines `custom_providers: [{name: kimi, ...}]` and references `provider: kimi` from fallback_model or the main config, the built-in alias rewriting (`kimi` → `kimi-coding`) was hijacking the request before the named-custom lookup ran. `_get_named_custom_provider` also refused to return a match when the raw name resolved to any built-in (including aliases), so the custom endpoint was unreachable. Fix at both layers of the resolution chain so every caller benefits, not just `_try_activate_fallback`: - hermes_cli/runtime_provider.py: narrow `_get_named_custom_provider`'s built-in-wins guard to canonical provider names only. An alias like `kimi` that resolves to a different canonical (`kimi-coding`) no longer blocks the custom lookup; a canonical name like `nous` still does. - agent/auxiliary_client.py: in `resolve_provider_client`, try the named- custom lookup with the original (pre-alias-normalization) name before the alias-normalized one, so aliased requests reach the user's custom entry. Also honour `explicit_base_url` and `explicit_api_key` in the API-key provider branch so callers that pass explicit hints (e.g. fallback activation) can override the registered defaults. Tests added for: - custom `kimi` shadowing built-in alias (regression for NousResearch#15743) - custom `nous` NOT shadowing canonical built-in (behaviour preserved) - bare `kimi` without any custom entry still routing to built-in - explicit base_url/api_key override on the API-key provider branch Original PR NousResearch#17827 by @Feranmi10 identified the same bug class and implemented a narrower fix in `_try_activate_fallback`; this reshapes the fix to live in the shared resolution layer so all callers benefit. Fixes NousResearch#15743 Co-authored-by: Feranmi10 <89228157+Feranmi10@users.noreply.github.com>

@Feranmi10

When a user defines `custom_providers: [{name: kimi, ...}]` and references `provider: kimi` from fallback_model or the main config, the built-in alias rewriting (`kimi` → `kimi-coding`) was hijacking the request before the named-custom lookup ran. `_get_named_custom_provider` also refused to return a match when the raw name resolved to any built-in (including aliases), so the custom endpoint was unreachable. Fix at both layers of the resolution chain so every caller benefits, not just `_try_activate_fallback`: - hermes_cli/runtime_provider.py: narrow `_get_named_custom_provider`'s built-in-wins guard to canonical provider names only. An alias like `kimi` that resolves to a different canonical (`kimi-coding`) no longer blocks the custom lookup; a canonical name like `nous` still does. - agent/auxiliary_client.py: in `resolve_provider_client`, try the named- custom lookup with the original (pre-alias-normalization) name before the alias-normalized one, so aliased requests reach the user's custom entry. Also honour `explicit_base_url` and `explicit_api_key` in the API-key provider branch so callers that pass explicit hints (e.g. fallback activation) can override the registered defaults. Tests added for: - custom `kimi` shadowing built-in alias (regression for NousResearch#15743) - custom `nous` NOT shadowing canonical built-in (behaviour preserved) - bare `kimi` without any custom entry still routing to built-in - explicit base_url/api_key override on the API-key provider branch Original PR NousResearch#17827 by @Feranmi10 identified the same bug class and implemented a narrower fix in `_try_activate_fallback`; this reshapes the fix to live in the shared resolution layer so all callers benefit. Fixes NousResearch#15743 Co-authored-by: Feranmi10 <89228157+Feranmi10@users.noreply.github.com>

@Feranmi10

When a user defines `custom_providers: [{name: kimi, ...}]` and references `provider: kimi` from fallback_model or the main config, the built-in alias rewriting (`kimi` → `kimi-coding`) was hijacking the request before the named-custom lookup ran. `_get_named_custom_provider` also refused to return a match when the raw name resolved to any built-in (including aliases), so the custom endpoint was unreachable. Fix at both layers of the resolution chain so every caller benefits, not just `_try_activate_fallback`: - hermes_cli/runtime_provider.py: narrow `_get_named_custom_provider`'s built-in-wins guard to canonical provider names only. An alias like `kimi` that resolves to a different canonical (`kimi-coding`) no longer blocks the custom lookup; a canonical name like `nous` still does. - agent/auxiliary_client.py: in `resolve_provider_client`, try the named- custom lookup with the original (pre-alias-normalization) name before the alias-normalized one, so aliased requests reach the user's custom entry. Also honour `explicit_base_url` and `explicit_api_key` in the API-key provider branch so callers that pass explicit hints (e.g. fallback activation) can override the registered defaults. Tests added for: - custom `kimi` shadowing built-in alias (regression for NousResearch#15743) - custom `nous` NOT shadowing canonical built-in (behaviour preserved) - bare `kimi` without any custom entry still routing to built-in - explicit base_url/api_key override on the API-key provider branch Original PR NousResearch#17827 by @Feranmi10 identified the same bug class and implemented a narrower fix in `_try_activate_fallback`; this reshapes the fix to live in the shared resolution layer so all callers benefit. Fixes NousResearch#15743 Co-authored-by: Feranmi10 <89228157+Feranmi10@users.noreply.github.com>

@Feranmi10

When a user defines `custom_providers: [{name: kimi, ...}]` and references `provider: kimi` from fallback_model or the main config, the built-in alias rewriting (`kimi` → `kimi-coding`) was hijacking the request before the named-custom lookup ran. `_get_named_custom_provider` also refused to return a match when the raw name resolved to any built-in (including aliases), so the custom endpoint was unreachable. Fix at both layers of the resolution chain so every caller benefits, not just `_try_activate_fallback`: - hermes_cli/runtime_provider.py: narrow `_get_named_custom_provider`'s built-in-wins guard to canonical provider names only. An alias like `kimi` that resolves to a different canonical (`kimi-coding`) no longer blocks the custom lookup; a canonical name like `nous` still does. - agent/auxiliary_client.py: in `resolve_provider_client`, try the named- custom lookup with the original (pre-alias-normalization) name before the alias-normalized one, so aliased requests reach the user's custom entry. Also honour `explicit_base_url` and `explicit_api_key` in the API-key provider branch so callers that pass explicit hints (e.g. fallback activation) can override the registered defaults. Tests added for: - custom `kimi` shadowing built-in alias (regression for NousResearch#15743) - custom `nous` NOT shadowing canonical built-in (behaviour preserved) - bare `kimi` without any custom entry still routing to built-in - explicit base_url/api_key override on the API-key provider branch Original PR NousResearch#17827 by @Feranmi10 identified the same bug class and implemented a narrower fix in `_try_activate_fallback`; this reshapes the fix to live in the shared resolution layer so all callers benefit. Fixes NousResearch#15743 Co-authored-by: Feranmi10 <89228157+Feranmi10@users.noreply.github.com>

alt-glitch added comp/agent Core agent loop, run_agent.py, prompt builder P2 Medium — degraded but workaround exists type/bug Something isn't working labels Apr 30, 2026

This was referenced May 1, 2026

fix(status): add NVIDIA_API_KEY to hermes status API keys display #18168

Merged

fix(status): add NVIDIA_API_KEY to hermes status API keys display #18067

Closed

fix(fallback): let custom_providers shadow built-in aliases #18185

Merged

teknium1 closed this in #18185 May 1, 2026

teknium1 mentioned this pull request May 5, 2026

fix(setup): add keep/replace/clear menu when API key already exists #18355

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(fallback): look up custom_providers base_url before fallback API call#17827

fix(fallback): look up custom_providers base_url before fallback API call#17827
Feranmi10 wants to merge 1 commit into
NousResearch:mainfrom
Feranmi10:fix/fallback-custom-provider-base-url

Feranmi10 commented Apr 30, 2026

Uh oh!

alt-glitch commented Apr 30, 2026

Uh oh!

teknium1 commented May 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Feranmi10 commented Apr 30, 2026

What does this PR do?

Related Issue

Type of Change

Uh oh!

alt-glitch commented Apr 30, 2026

Uh oh!

teknium1 commented May 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants