Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix Auxiliary tasks don't inherit provider-level base_url/api_key from config [1 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#17737•Fetched 2026-05-01 05:56:13
View on GitHub
Comments
2
Participants
2
Timeline
7
Reactions
0
Author
wjameswen888wjameswen888
Participants
alt-glitchalt-glitchwjameswen888wjameswen888
Timeline (top)
labeled ×4commented ×2cross-referenced ×1

When a user configures a custom base_url for a provider (e.g., xiaomi with token-plan-sgp.xiaomimimo.com), auxiliary tasks (session_search, compression, title_generation, flush_memories, approval) ignore the user's providers.<name>.base_url and instead use the hardcoded inference_base_url from PROVIDER_REGISTRY in hermes_cli/auth.py. This causes silent failures — auxiliary tasks timeout/401 and fall back to other providers, creating cascading issues (gateway idle timeouts, broken session_search).

Root Cause

auxiliary_client.py → _resolve_task_provider_model() reads auxiliary.<task>.provider but not base_url. When the task config only has provider: xiaomi, it returns with base_url=None, and later _resolve_api_key_provider() uses pconfig.inference_base_url — the hardcoded default.

Fix Action

Fix / Workaround

Workaround (current)

Users must explicitly set base_url and api_key in EACH auxiliary.<task> section, requiring credential duplication across 5+ auxiliary tasks.

PR fix notes

PR #17760: fix(auxiliary): inherit provider-level base_url/api_key for auxiliary tasks

Description (problem / solution / changelog)

Summary

When auxiliary.<task>.provider references a user-configured provider (e.g. xiaomi with a custom base_url), the resolved base_url and api_key were not inherited from the providers.<name> config entry. Instead, auxiliary tasks fell back to the hardcoded inference_base_url from PROVIDER_REGISTRY, causing silent failures (timeouts, 401s) and cascading fallback to other providers.

Changes

agent/auxiliary_client.py

  1. _resolve_task_provider_model() — When cfg_provider is set (not "auto") but no explicit base_url is configured on the auxiliary task, look up providers.<cfg_provider> in config.yaml to inherit base_url and api_key. Supports base_url, api, url field variants and key_env environment variable resolution.

  2. resolve_provider_client() — In the PROVIDER_REGISTRY code path, honor explicit_base_url / explicit_api_key over hardcoded registry defaults. This allows the inherited provider config from (1) to flow through correctly.

Resolution Chain (as specified in #17737)

  1. auxiliary.<task>.base_url / api_key (explicit override) ✅ already worked
  2. providers.<task_provider>.base_url / api_key (inherited) ✅ NEW
  3. Hardcoded PROVIDER_REGISTRY default ✅ already worked

Testing

  • All 231 auxiliary-related tests pass
  • Syntax validated

Closes #17737

Changed files

  • agent/auxiliary_client.py (modified, +26/-2)
RAW_BUFFERClick to expand / collapse

Issue: auxiliary tasks don't respect user's provider-level base_url (falls back to hardcoded PROVIDER_REGISTRY)

Summary

When a user configures a custom base_url for a provider (e.g., xiaomi with token-plan-sgp.xiaomimimo.com), auxiliary tasks (session_search, compression, title_generation, flush_memories, approval) ignore the user's providers.<name>.base_url and instead use the hardcoded inference_base_url from PROVIDER_REGISTRY in hermes_cli/auth.py. This causes silent failures — auxiliary tasks timeout/401 and fall back to other providers, creating cascading issues (gateway idle timeouts, broken session_search).

Root Cause

auxiliary_client.py → _resolve_task_provider_model() reads auxiliary.<task>.provider but not base_url. When the task config only has provider: xiaomi, it returns with base_url=None, and later _resolve_api_key_provider() uses pconfig.inference_base_url — the hardcoded default.

Workaround (current)

Users must explicitly set base_url and api_key in EACH auxiliary.<task> section, requiring credential duplication across 5+ auxiliary tasks.

Desired Behavior

auxiliary.<task>.provider should inherit base_url and api_key from providers.<name> when not explicitly overridden. Resolution chain:

  1. auxiliary.<task>.base_url / api_key (explicit override)
  2. providers.<task_provider>.base_url / api_key (inherit from provider)
  3. Hardcoded PROVIDER_REGISTRY default

Affected Code

  • agent/auxiliary_client.py: _resolve_task_provider_model() — returns None for base_url when only provider is set
  • agent/auxiliary_client.py: _resolve_api_key_provider() — uses pconfig.inference_base_url unconditionally

Environment

  • Hermes v0.11.0
  • Provider: xiaomi (MiMo) with non-standard base_url

extent analysis

TL;DR

Update auxiliary_client.py to inherit base_url and api_key from providers.<name> when not explicitly overridden in auxiliary.<task>.

Guidance

  • Modify _resolve_task_provider_model() in auxiliary_client.py to check for providers.<name>.base_url when auxiliary.<task>.base_url is not set.
  • Update _resolve_api_key_provider() to use the inherited base_url and api_key from providers.<name> when available.
  • Verify the fix by configuring a custom base_url for a provider and checking if auxiliary tasks use the correct URL.
  • Test the resolution chain to ensure it follows the desired order: explicit override, provider inheritance, and hardcoded default.

Example

# In auxiliary_client.py
def _resolve_task_provider_model(self, task):
    # ...
    if not task.base_url:
        provider = task.provider
        task.base_url = self.providers.get(provider, {}).get('base_url')
    # ...

Notes

This fix assumes that the providers dictionary is accessible in the auxiliary_client.py module. If not, additional modifications may be needed to pass the required information.

Recommendation

Apply workaround: update auxiliary_client.py to inherit base_url and api_key from providers.<name> to fix the issue without waiting for a new version release.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#indexing error#inference speed#output truncation#response parsing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING