Description

When configuring custom_providers in config.yaml for use with auxiliary tasks (session_search, compression, title_generation, etc.), the custom: provider prefix is stripped by _normalize_aux_provider(), making named custom providers unreachable.

Environment

• Hermes Agent version: latest (post v0.6)
• OS: macOS (M4)
• Config: custom_providers with alternative base_url (coding-specific API endpoint)

Root Cause

In agent/auxiliary_client.py, the function _normalize_aux_provider() converts the provider string to lowercase for matching:

normalized = (provider or "auto").strip().lower()

This strips the custom: prefix distinction. For example, custom:GLM-Aux becomes custom:glm-aux.

However, in hermes_cli/runtime_provider.py, the function _get_named_custom_provider() requires the exact custom: prefixed string to look up named custom providers from the config. Since _normalize_aux_provider returns the lowercased string without preserving the custom: prefix as a recognized category, the downstream code cannot match it to any named custom provider entry.

The result: auxiliary tasks silently fall through to a broken fallback path and fail.

Steps to Reproduce

1. Define a custom provider in config.yaml:

custom_providers:
  - name: MyProvider
    base_url: https://example.com/v1
    key_env: MY_API_KEY
    model: some-model

1. Configure auxiliary tasks to use it:

auxiliary:
  session_search:
    provider: custom:MyProvider
    model: some-model
    timeout: 30

1. Restart gateway and trigger session_search — it fails with authentication/connection errors because the custom provider is never resolved.

Workaround

Patch _normalize_aux_provider() in auxiliary_client.py to preserve the custom: prefix:

normalized = (provider or "auto").strip().lower()
# Preserve custom: prefix so runtime_provider can match named custom providers
if (provider or "").strip().lower().startswith("custom:"):
    return normalized

Expected Fix

_normalize_aux_provider() should recognize and preserve custom:-prefixed provider strings, or the downstream _get_named_custom_provider() should handle the normalized (lowercased) name without requiring the custom: prefix.

Additional Note

There is a secondary issue: _resolve_task_provider_model() checks cfg_base_url before cfg_provider, meaning if a user sets both base_url and provider: custom:XXX in an auxiliary block, the base_url takes priority and the custom provider lookup is bypassed entirely. This should be documented or the priority reversed.