Summary

Named custom providers defined under providers: drop the explicit api_mode during runtime resolution.

As a result, a provider that is configured with a non-default protocol (for example codex_responses) can resolve correctly when used through the legacy model.provider: custom path, but resolve incorrectly when selected by its named provider key.

Impact

This makes the new-style providers: config unsafe for some custom endpoints.

In my case, the same endpoint works through the legacy path, but the named-provider path falls back to URL detection and ends up using chat_completions instead of the configured protocol.

Minimal redacted repro

Config:

model:
  provider: custom
  base_url: https://<redacted-endpoint>/v1
  api_mode: codex_responses
  default: <redacted-model>

providers:
  <redacted-provider-name>:
    name: <redacted-display-name>
    base_url: https://<redacted-endpoint>/v1
    api_key: <redacted>
    default_model: <redacted-model>
    api_mode: codex_responses
    models:
      <redacted-model>: {}

Runtime behavior observed locally:

resolve_runtime_provider(requested='custom')
# => {
#      'provider': 'custom',
#      'base_url': 'https://<redacted-endpoint>/v1',
#      'api_mode': 'codex_responses',
#      ...
#    }

resolve_runtime_provider(requested='<redacted-provider-name>')
# => {
#      'provider': 'custom',
#      'base_url': 'https://<redacted-endpoint>/v1',
#      'api_mode': 'chat_completions',
#      ...
#    }

This reproduces even when providers.<name>.api_mode is explicitly set.

Suspected root cause

hermes_cli/runtime_provider.py:

• _get_named_custom_provider() returns name, base_url, api_key, and model
• but it does not return api_mode
• later _try_resolve_from_custom_pool(..., api_mode_override=None) falls back to:

_detect_api_mode_for_url(base_url) or "chat_completions"

Relevant current code:

if requested_norm in {ep_name, name_norm, f"custom:{name_norm}"}:
    base_url = entry.get("api") or entry.get("url") or entry.get("base_url") or ""
    if base_url:
        return {
            "name": entry.get("name", ep_name),
            "base_url": base_url.strip(),
            "api_key": resolved_api_key,
            "model": entry.get("default_model", ""),
        }

Expected behavior

If a named custom provider in providers: specifies api_mode, runtime resolution should preserve and use it.

In other words, the named-provider path should be behaviorally equivalent to the legacy custom-provider path for protocol selection.

Suggested fix

Include api_mode in _get_named_custom_provider() return data for providers: entries, and pass it through the same way other explicit runtime overrides are handled.

It would also be great to add a regression test covering:

• providers: named custom provider with explicit api_mode
• resolve_runtime_provider(requested='<name>')
• expected api_mode == configured value

Notes

I searched existing issues and found related but distinct reports around custom-provider protocol selection / codex behavior, but not this specific named-provider regression.