Bug Description

When multiple custom_providers are configured with the same base_url (e.g., all pointing to a unified API gateway), the credential pool resolution in _resolve_named_custom_runtime matches by base_url and returns the credentials of the first matching provider, not the requested provider.

Root Cause

In hermes_cli/runtime_provider.py, the function _resolve_named_custom_runtime calls _try_resolve_from_custom_pool(base_url, "custom", ...) to get credentials from the shared credential pool. The pool is keyed by base_url, so when multiple custom providers share the same base_url, the pool lookup returns whichever provider was registered first in the configuration, ignoring the actual requested provider.

Impact

• Switching between custom providers that share the same base_url uses incorrect API keys
• Requests may fail with authentication errors (401) or be routed to wrong channels/groups
• Users cannot reliably use multiple providers through a single API gateway

Reproduction Steps

1. Configure multiple custom_providers with the same base_url but different api_key values
2. Switch model to a provider that is NOT the first one in the configuration list
3. Observe that the wrong API key is used (can be verified via logs or authentication errors)

Suggested Fix

Modify _resolve_named_custom_runtime to prioritize the provider's own api_key field before falling back to the shared credential pool. This ensures each provider uses its configured credentials even when sharing a base_url with other providers.

Related Code

• hermes_cli/runtime_provider.py - _resolve_named_custom_runtime() function
• hermes_cli/runtime_provider.py - _try_resolve_from_custom_pool() function
• hermes_cli/runtime_provider.py - get_custom_provider_pool_key() function

Workaround

Currently, the only workaround is to ensure each custom provider uses a unique base_url, which is not always possible when using a unified API gateway.