[Bug]: config.yaml provider/base_url ignored on fresh session startup

[magnusbonnevier]

Bug Description

Bug Report: Config.yaml provider/base_url ignored on fresh session startup

Labels: bug, config, provider, cli

---

Summary

When starting a fresh Hermes CLI session, the provider and base_url values from ~/.hermes/config.yaml are not being read. Instead, the system falls back to hardcoded defaults (OPENROUTER_BASE_URL and "openrouter"), causing all API calls to route to OpenRouter regardless of user configuration.

---

Impact

Users with custom/local providers (Ollama, local LLMs, etc.) cannot use Hermes without workarounds, as the system silently falls back to unconfigured OpenRouter.

---

Environment

• Hermes Agent: Latest (post-config-version-10)
• Platform: CLI
• Config: Version 10 with provider/custom/base_url properly set
• OS: Linux (Ubuntu on WSL)

Steps to Reproduce

Steps to Reproduce

1. Configure a custom provider in ~/.hermes/config.yaml:

   model: kimi-k2.5:cloud
   provider: custom
   base_url: http://localhost:11434/v1

2. Ensure no environment variables like HERMES_PROVIDER or HERMES_BASE_URL are set

3. Start a completely fresh Hermes session (no existing process): hermes

4. Observe that requests are sent to https://openrouter.ai/api/v1 instead of the configured custom endpoint

---

Expected Behavior

Expected Behavior

The system should read provider and base_url from config.yaml and use the custom endpoint as the primary provider.

---

Actual Behavior

Actual Behavior

The system ignores config.yaml values and falls back to OpenRouter defaults. Request dumps show:

{
  "url": "https://openrouter.ai/api/v1/chat/completions",
  "headers": {
    "Authorization": "Bearer None"
  }
}

---

Affected Component

CLI (interactive chat), Configuration (config.yaml, .env, hermes setup), Agent Core (conversation loop, context compression, memory)

Messaging Platform (if gateway-related)

No response

Operating System

Ubuntu 24.04

Python Version

3.12.3

Hermes Version

v0.4.0 (2026.3.18)

Relevant Logs / Traceback

{
     "timestamp": "2026-03-21T08:48:50.427845",
     "reason": "non_retryable_client_error",
     "request": {
       "url": "https://openrouter.ai/api/v1/chat/completions",
       "headers": {
         "Authorization": "Bearer None"  // ← Tom API-nyckel!
       },
       "body": {
         "model": "kimi-k2.5:cloud"
       }
     }
   }
   


   ## Logs and Evidence

   **Request dump showing fallback to OpenRouter with empty API key:**
   
   {
     "timestamp": "[TIMESTAMP]",
     "reason": "non_retryable_client_error",
     "request": {
       "url": "https://openrouter.ai/api/v1/chat/completions",
       "headers": {
         "Authorization": "Bearer None"
       },
       "body": {
         "model": "kimi-k2.5:cloud"
       }
     }
   }
   

   **Also observed in session files:**
   - `session_20260321_XXXXX` files with `base_url: https://openrouter.ai/api/v1`
   - Log warnings: `resolve_provider_client: openrouter requested but OPENROUTER_API_KEY not set`

Root Cause Analysis (optional)

Root Cause Analysis

In run_agent.py, the AIAgent.__init__() method sets:

self.base_url = base_url or OPENROUTER_BASE_URL
self.provider = provider_name or "openrouter"

When provider and base_url are not passed as constructor arguments (and no environment variables exist), they default to OpenRouter values. The config file loading via load_config() happens later in initialization but doesn't feed back into these already-set instance variables.

Auxiliary Services Also Affected

The _resolve_auto() function in auxiliary_client.py tries OpenRouter first in the resolution chain, then Nous, then custom endpoints. This causes auxiliary services (vision, web_extract, session_search, etc.) to also fail when OpenRouter credentials are not configured.

---

Proposed Fix (optional)

Suggested Fix

1. Load config.yaml EARLY in AIAgent.__init__() BEFORE setting fallback values
2. Use config values as fallback before OpenRouter defaults:

   config = load_config()
   self.base_url = base_url or config.get('base_url') or OPENROUTER_BASE_URL
   self.provider = provider_name or config.get('provider') or "openrouter"

3. Alternatively, consider custom providers in the _resolve_auto() chain before trying OpenRouter/Nous

---

Workaround

Set environment variables in ~/.hermes/.env:

HERMES_PROVIDER=custom
HERMES_BASE_URL=http://localhost:11434/v1
HERMES_MODEL=kimi-k2.5:cloud

Or pass explicit CLI flags:

hermes --provider custom --base-url http://localhost:11434/v1

---

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[ygd58]

Submitted a fix in PR #2283 . Root-level provider and base_url in config.yaml were never merged into the model config in load_cli_config(). Added explicit handling to pick up these root-level keys so custom endpoints work without workarounds.