hermes - 💡(How to fix) Fix Provider aliases (ollama/vllm/llamacpp) silently fall through to OpenRouter when base_url is a LAN or remote IP

Bug

When config.yaml uses a provider alias that maps to custom — ollama, vllm, llamacpp, llama-cpp — with a non-loopback base_url (e.g. a LAN IP like 192.168.0.103 or a WireGuard-routed remote host), the configured endpoint is silently ignored and requests fall through to OpenRouter.

provider: "custom" works correctly. provider: "ollama" with the same base_url does not.

Steps to Reproduce

# ~/.hermes/config.yaml
model:
  provider: "ollama"
  base_url: "http://192.168.0.103:11434"
  default: "qwen2.5-coder:latest"

hermes
> hello
⚠️  API call failed (attempt 1/3): AuthenticationError [HTTP 401]
   🔌 Provider: openrouter  Model: qwen2.5-coder:latest
   🌐 Endpoint: https://openrouter.ai/api/v1

Changing provider to "custom" resolves it. Changing base_url to http://localhost:11434 (loopback) also resolves it.

Root Cause

_config_base_url_trustworthy_for_bare_custom() in hermes_cli/runtime_provider.py checks cfg_provider_norm == "custom" to decide whether to trust a non-loopback base_url. However, auth.py defines several aliases that all resolve to "custom" at runtime:

# auth.py _PROVIDER_ALIASES
"ollama": "custom",
"vllm": "custom",
"llamacpp": "custom",
"llama-cpp": "custom",
"llama.cpp": "custom",

The trustworthy check never normalises through these aliases, so cfg_provider_norm is "ollama" — not "custom" — and the non-loopback URL fails the check. The function then returns False, use_config_base_url stays False, and the base URL falls through to OPENROUTER_BASE_URL.

The OpenRouter rejection guard at the top of the function is correct and is preserved in the fix.

Expected Behaviour

Any provider value that the user legitimately writes to mean "local/custom" (ollama, vllm, llamacpp, llama-cpp, llama.cpp, custom) should allow a non-loopback base_url in config.yaml to be used as the custom endpoint.

Fix

Expand the trusted set from {"custom"} to include all aliases, checked after the OpenRouter rejection guard:

_CUSTOM_PROVIDER_ALIASES = {
    "custom", "ollama", "vllm", "llamacpp", "llama-cpp", "llama.cpp",
}
# ...
if base_url_host_matches(bu, "openrouter.ai"):
    return False
if cfg_provider_norm in _CUSTOM_PROVIDER_ALIASES:
    return True
return _loopback_hostname(base_url_hostname(bu))

A PR with this fix and a test covering LAN IP + ollama provider is attached.

Motivation

Common in homelab and research setups: Ollama or vLLM running on a GPU machine (e.g. NVIDIA DGX Spark) reachable over a LAN or WireGuard VPN. The loopback restriction was introduced to prevent stale OpenRouter URLs from hijacking custom sessions (#14676), which is correct — this fix preserves that guard while extending trust to explicitly declared custom-family providers.