The local area network model cannot be used on the web UI, and it always prompts that I have not configured the API key.

[usnake978-crypto]

The local area network model cannot be used on the web UI, and it always prompts that I have not configured the API key.

[nesquena-hermes]

@usnake978-crypto thanks for the screenshot — the error reads:

Provider 'custom:48.48.48.88-11434' is set in config.yaml but no API key was found. Set the CUSTOM:48.48.48.88-11434_API_KEY environment variable, or switch to a different provider with hermes model.

You're running a LAN-hosted model (looks like Ollama on 48.48.48.88:11434) but configured it as a custom: provider, and WebUI is requiring an API key. Local-server providers like Ollama / LM Studio / vLLM normally don't need an API key, but the custom: provider path doesn't currently know that — it applies the "must have API key" rule uniformly.

Needinfo — confirm your config

Can you share the providers: section of your ~/.hermes/config.yaml (mask any actual API keys)? Specifically:

providers:
  <name>:
    base_url: ...
    type: ...           # is there a 'type' or 'kind' field?
    models: ...

Two paths from here, depending on the answer:

If your provider has base_url: http://48.48.48.88:11434 and points at Ollama, the cleanest fix is to use the ollama: provider kind instead of custom:. Try:

providers:
  myollama:
    type: ollama
    base_url: http://48.48.48.88:11434
    models:
      qwen3:8b:
        context_length: 32768

And in the model picker, select ollama:qwen3:8b (or whatever your model is named). The ollama: provider kind is exempt from the API-key requirement and is what most LAN model setups should use.

If it really does need to be custom: (e.g. you're hitting a Ollama-compatible-but-not-Ollama endpoint), there are two existing workarounds:

1. Set the environment variable to an empty placeholder: export CUSTOM:48.48.48.88-11434_API_KEY=none before launching WebUI. The provider will accept the placeholder.
2. Add an api_key_optional: true field to the provider entry (this exists in recent versions for exactly this case).

Underlying bug

Regardless of your workaround, the WebUI should recognize that LAN/private-IP base_url values (127.0.0.1, 192.168.*, 10.*, 48.48.*, etc.) probably don't need an API key. We have _LOCAL_SERVER_PROVIDERS for the kind-based check, but the LAN-IP heuristic for custom: isn't there yet. I'll track that as a separate enhancement.

Labeling bug + needinfo + auth, Milestone 3 (Platform expansion). Ping back with the config snippet and we'll pick a path forward.

[usnake978-crypto]

model: default: ministral-3:latest provider: ollama think: false timeout_seconds: 3000 stale_timeout_seconds: 3000 base_url: http://48.48.48.88:11434/v1 providers: {} This is my configuration information. I configured it using the Hermes Model command. nesquena-hermes ***@***.***> 于2026年5月15日周五 22:54写道：

…

*nesquena-hermes* left a comment (nesquena/hermes-webui#2271) <#2271 (comment)> @usnake978-crypto <https://github.com/usnake978-crypto> thanks for the screenshot — the error reads: Provider 'custom:48.48.48.88-11434' is set in config.yaml but no API key was found. Set the CUSTOM:48.48.48.88-11434_API_KEY environment variable, or switch to a different provider with hermes model. You're running a LAN-hosted model (looks like Ollama on 48.48.48.88:11434) but configured it as a custom: provider, and WebUI is requiring an API key. Local-server providers like Ollama / LM Studio / vLLM normally don't need an API key, but the custom: provider path doesn't currently know that — it applies the "must have API key" rule uniformly. Needinfo — confirm your config Can you share the providers: section of your ~/.hermes/config.yaml (mask any actual API keys)? Specifically: providers: <name>: base_url: ... type: ... # is there a 'type' or 'kind' field? models: ... Two paths from here, depending on the answer: *If your provider has base_url: http://48.48.48.88:11434 <http://48.48.48.88:11434> and points at Ollama*, the cleanest fix is to use the ollama: provider kind instead of custom:. Try: providers: myollama: type: ollama base_url: http://48.48.48.88:11434 models: qwen3:8b: context_length: 32768 And in the model picker, select ollama:qwen3:8b (or whatever your model is named). The ollama: provider kind is exempt from the API-key requirement and is what most LAN model setups should use. *If it really does need to be custom:* (e.g. you're hitting a Ollama-compatible-but-not-Ollama endpoint), there are two existing workarounds: 1. Set the environment variable to an empty placeholder: export CUSTOM:48.48.48.88-11434_API_KEY=none before launching WebUI. The provider will accept the placeholder. 2. Add an api_key_optional: true field to the provider entry (this exists in recent versions for exactly this case). Underlying bug Regardless of your workaround, the WebUI should recognize that LAN/private-IP base_url values (127.0.0.1, 192.168.*, 10.*, 48.48.*, etc.) probably don't need an API key. We have _LOCAL_SERVER_PROVIDERS for the kind-based check, but the LAN-IP heuristic for custom: isn't there yet. I'll track that as a separate enhancement. Labeling bug + needinfo + auth, Milestone 3 (Platform expansion). Ping back with the config snippet and we'll pick a path forward. — Reply to this email directly, view it on GitHub <#2271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CD3ACNQSUG74M2BLRD64KY3424VRVAVCNFSM6AAAAACY6OGYQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRQHAYTONZQHE> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nesquena-hermes]

Thanks for sharing the config, @usnake978-crypto.

Looking at what you posted:

model:
  default: ministral-3:latest
  provider: ollama
  ...
  base_url: http://48.48.48.88:11434/v1
providers: {}

Two things are off here that together produce the error:

1. provider: ollama but providers: {} is empty. The model dropdown uses what's in providers: to know what to talk to. With an empty providers block, the WebUI doesn't have an Ollama provider registered, so it falls back to constructing a synthetic custom:48.48.48.88-11434 from the bare base_url — which is what's triggering the API-key prompt.
2. base_url is at the top level under model:, not under a provider entry. The CLI happens to accept this shape for the agent runtime, but the WebUI's provider/model picker reads providers: for the dropdown source-of-truth.

Fix: declare an explicit Ollama provider

Replace your providers: {} block with:

providers:
  ollama:
    base_url: http://48.48.48.88:11434
    models:
      ministral-3:latest:
        context_length: 32768

Then either restart the WebUI or use hermes model to re-select. The model dropdown should now offer ollama:ministral-3:latest and won't ask for an API key (Ollama is a registered local-server provider, exempt from the key check).

Note: drop the /v1 suffix from base_url — the WebUI provider handler appends it for OpenAI-compatible endpoints, so leaving it on the configured URL leads to /v1/v1/ paths in some code paths.

Removing the needinfo label and labeling as bug + Milestone 3 for the underlying issue (the LAN-IP heuristic + the provider: ollama + empty providers: {} interaction). The workaround above should unblock you immediately.

If it doesn't work, please share the WebUI version and the new error so we can keep narrowing.

[Spiritdude]

IMHO custom endpoint should not probe for API key and fail if it doesn't exist. If it's there then use it, if it's not there, don't throw error for non-existing API key unless the request actually fails because of auth problems - much simpler than doing heuristics or special settings in .hermes/config.yaml for providers custom .

I reference base_url = 'http://gpu.local:8000/v1' which is a llama-server with a couple of models in my local network.

Btw, export "CUSTOM:something-8000_API_KEY=none" is invalid, the ':' and '-' are not valid in env variables, so non [A-Za-z0-9] should rather fallback to '_' like "CUSTOM_something_8000_API_KEY" as env name.

[nesquena-hermes]

Two separate points worth pulling out from @Spiritdude's comment, because they're both real and one of them is a quick fix:

1. Probing the /models endpoint when the user only configured chat

This is the right product instinct. The legacy behavior was "test /models first to populate the picker, surface an error if it fails." That made sense before the OpenAI-compatible relay ecosystem exploded — now we see endpoints that:

• Authenticate /v1/chat/completions but not /v1/models (different scopes / different keys)
• Don't implement /v1/models at all (e.g. some llama-server setups, some self-hosted proxies)
• Implement /v1/models but require auth even though chat doesn't

Filing this in two pieces:

• Surface models-endpoint errors per named custom provider instead of silently empty picker #2540 (already open, just merged into Milestone 1) covers the named custom provider case — surface the models-endpoint error per-provider instead of silently emptying the picker. Once that lands, "endpoint authenticates chat but not models" produces a visible, actionable hint instead of a mystery empty dropdown.
• The deeper "don't fail if /models 401s, just trust chat" change applies to the anonymous custom:host-port case too. That's worth a separate small issue — I'll file it as a follow-up.

2. Env-var name normalization (CUSTOM:something-8000_API_KEY)

You're right — : and - are not valid in POSIX environment variable names. bash will accept the assignment but won't export it cleanly across shells, and most process managers reject it outright.

The fix is exactly the shape you suggested — normalize the env-var name to [A-Z0-9_] by replacing any non-alphanumeric character with _:

def _api_key_env_name(provider_id: str) -> str:
    sanitized = re.sub(r'[^A-Za-z0-9]', '_', provider_id).upper()
    return f"CUSTOM_{sanitized}_API_KEY"

That gives CUSTOM_GPU_LOCAL_8000_API_KEY instead of CUSTOM:gpu.local-8000_API_KEY. The challenge is backwards compatibility: if anyone has the broken-shaped variable already set, we'd want to check both names during the migration window (try the sanitized form first, fall back to the old form, log a one-shot deprecation warning).

Filing this as a separate bug too — small, mechanical, clear test plan.

Will link both follow-ups back here once filed.