Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix Auxiliary custom/main should inherit named main providers [1 pull requests, 1 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#16435•Fetched 2026-04-28 06:53:19
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
qwertyscqwertysc
Participants
qwertyscqwertysc
Timeline (top)
labeled ×4cross-referenced ×1

Error Message

When resolving custom/main, after the legacy anonymous custom endpoint fails, try resolving through _read_main_provider() / _read_main_model() if the main provider is a named provider. Only warn if that fallback also fails.

Fix Action

Fixed

PR fix notes

PR #16437: fix(auxiliary): resolve custom/main via named main provider

Description (problem / solution / changelog)

Summary

  • Resolve legacy custom/main auxiliary requests through the configured main provider when no anonymous custom endpoint is available.
  • Normalize underscores in named custom provider lookup so config names like cliproxyapi_local match their normalized provider IDs.
  • Add regression coverage for custom/main inheriting a named main provider.

Root cause

Some auxiliary call paths use custom/main as a shorthand for "use the main chat endpoint". In v12+ configs, the main endpoint can be a named custom provider rather than the legacy anonymous OPENAI_BASE_URL / OPENAI_API_KEY custom runtime. When the anonymous endpoint was absent, resolution emitted a misleading warning even though a valid named main provider was configured.

What changed

  • After legacy anonymous custom resolution fails for custom/main, try _read_main_provider() / _read_main_model().
  • If the main provider is a named provider, resolve through the normal named-provider path and return that client/model.
  • Treat underscores like spaces when normalizing custom provider names, so cliproxyapi_local and cliproxyapi-local resolve consistently.

Tests

  • python -m pytest tests/agent/test_auxiliary_client.py -q -o 'addopts='

Verification

  • Verified custom/main no longer emits custom/main requested but no endpoint credentials found when a named main provider is available.
  • Verified the existing auxiliary client test suite still passes.

Fixes #16435

Changed files

  • agent/auxiliary_client.py (modified, +31/-0)
  • hermes_cli/runtime_provider.py (modified, +1/-1)
  • tests/agent/test_auxiliary_client.py (modified, +24/-0)

Code Example

resolve_provider_client: custom/main requested but no endpoint credentials found
RAW_BUFFERClick to expand / collapse

Bug Description

Some auxiliary call paths request resolve_provider_client("custom", "main") as a shorthand for inheriting the main chat endpoint. With v12+ configuration, the main endpoint may be a named custom provider such as cliproxyapi_local rather than the legacy anonymous OPENAI_BASE_URL / OPENAI_API_KEY custom endpoint.

When no anonymous custom endpoint is configured, custom/main currently falls through to:

resolve_provider_client: custom/main requested but no endpoint credentials found

This warning is misleading if the profile does have a valid named main provider configured.

Steps to Reproduce

  1. Configure the main model provider as a named custom provider, e.g. cliproxyapi_local.
  2. Leave the legacy anonymous custom runtime unset.
  3. Trigger an auxiliary path that resolves custom/main.
  4. Inspect warnings.

Expected Behavior

custom/main should inherit the configured main provider/model when the anonymous custom endpoint is absent.

Actual Behavior

Hermes emits a warning about missing custom endpoint credentials even though a valid main provider exists.

Impact

The warning is noisy and makes it look like auxiliary routing is misconfigured, while the real problem is resolution not following the named main provider fallback.

Proposed Fix

When resolving custom/main, after the legacy anonymous custom endpoint fails, try resolving through _read_main_provider() / _read_main_model() if the main provider is a named provider. Only warn if that fallback also fails.

extent analysis

TL;DR

Update the resolve_provider_client function to fallback to the named main provider when the anonymous custom endpoint is not configured.

Guidance

  • Verify that the main provider is correctly configured as a named custom provider (e.g., cliproxyapi_local) and the legacy anonymous custom runtime is unset.
  • Modify the resolve_provider_client function to check for a named main provider using _read_main_provider() and _read_main_model() after failing to find the anonymous custom endpoint.
  • Only emit a warning if both the anonymous custom endpoint and the named main provider fallback fail.
  • Test the updated function with the provided steps to reproduce to ensure the warning is no longer emitted when a valid named main provider exists.

Example

def resolve_provider_client(provider, model):
    # ... existing code ...
    if provider == "custom" and model == "main":
        # Check for anonymous custom endpoint
        if not anonymous_custom_endpoint_configured:
            # Fallback to named main provider
            main_provider = _read_main_provider()
            if main_provider:
                return main_provider
            else:
                # Only warn if both fallbacks fail
                warn("No custom endpoint credentials found")

Notes

This solution assumes that the _read_main_provider() and _read_main_model() functions are correctly implemented and return the named main provider if configured.

Recommendation

Apply the proposed fix to update the resolve_provider_client function to correctly handle the named main provider fallback, as it directly addresses the root cause of the issue and provides a clear solution.

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#embedding generation#cache error#pipeline error#runtime error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING