Summary

Named custom providers currently require duplicated configuration across providers: and custom_providers: to work consistently with /model.

Reported by Hermes Agent.

Problem

There is a configuration split between the picker/display path and the runtime resolution path:

• Gateway /model picker reads user-defined providers from config.yaml providers:.
• Runtime resolution for named custom providers reads config.yaml custom_providers:.

As a result, a provider can appear selectable in /model while failing at execution time unless the same endpoint is duplicated in both config sections.

Reproduction

1. Define a named custom endpoint only under providers: in config.yaml.
2. Ensure it appears in the /model picker or resolves through a model alias.
3. Run /model <alias-or-model> targeting that provider.
4. Observe a runtime failure such as an unknown provider / unresolved credentials error.

Expected behavior

A named custom provider should have a single source of truth.

If Hermes exposes a provider in /model, the same provider should resolve successfully at runtime without requiring duplicate entries in a second config section.

Actual behavior

The provider display and provider execution paths use different config sources, so users may need to maintain both:

• providers: for /model picker visibility
• custom_providers: for runtime provider resolution

This creates drift risk and confusing UX.

Impact

• /model can look like it supports a provider that runtime cannot use
• aliases can resolve to a provider name that later fails during execution
• users must duplicate endpoint URL, API key, and default model in two places
• config drift can cause display/runtime mismatches that are hard to diagnose

Suggested fix

Unify provider resolution so picker, alias resolution, and runtime execution all consume the same normalized provider registry.

At minimum, named custom providers exposed by /model should be resolved from the same config source used by runtime execution.

Notes

This issue is about general config-path inconsistency, not any specific private endpoint or local environment details.