Skip to content

Agent runs fall back to openrouter despite model.provider=custom in config.yaml #12146

@rbeben

Description

@rbeben

Environment

  • Hermes Agent image: nousresearch/hermes-agent:latest (Docker, pulled 2026-04-18)
  • Backend LLM: Ollama (hermes3:8b) on http://host.docker.internal:11434/v1 (DGX Spark)
  • Also tried: local vLLM Sehyo/Qwen3.5-35B-A3B-NVFP4 on http://host.docker.internal:8003/v1 — same symptom
  • Mode: Docker gateway (docker compose up -d), API_SERVER_ENABLED=true
  • OS: Linux (DGX Spark, aarch64)

Expected behavior

With the following config.yaml:

model:
  default: "hermes3:8b"
  provider: "custom"
  base_url: "http://host.docker.internal:11434/v1"

and no OPENROUTER_API_KEY in .env, the gateway should route all LLM calls (including agent runs triggered by /api/jobs/{id}/run and /v1/chat/completions) to the configured base_url.

Actual behavior

hermes config show correctly displays the model block:

◆ Model
  Model: {'default': 'hermes3:8b', 'provider': 'custom', 'base_url': 'http://host.docker.internal:11434/v1'}

But at runtime, agent runs still hit https://openrouter.ai/api/v1 and fail with 401:

⚠️  API call failed (attempt 1/3): AuthenticationError [HTTP 401]
   🔌 Provider: openrouter  Model: hermes3:8b
   🌐 Endpoint: https://openrouter.ai/api/v1
   📝 Error: HTTP 401: Missing Authentication header
❌ Non-retryable error (HTTP 401): HTTP 401: Missing Authentication header

Additional warnings in gateway logs:

WARNING agent.auxiliary_client: resolve_provider_client: unknown provider 'ollama'
WARNING agent.auxiliary_client: OPENAI_BASE_URL is set (http://host.docker.internal:11434/v1)
  but model.provider is 'openrouter'. Auxiliary clients may route to the wrong endpoint.
WARNING agent.auxiliary_client: resolve_provider_client: openrouter requested but OPENROUTER_API_KEY not set
WARNING agent.auxiliary_client: Auxiliary auto-detect: no provider available
  (tried: openrouter, nous, local/custom, openai-codex, api-key).

Notes:

  • Even after restart, config.yaml is re-read correctly (confirmed via hermes config show).
  • Clearing OPENAI_BASE_URL, OPENAI_MODEL, OPENAI_API_KEY from .env does not help.
  • Docs (user-guide/configuration) say "ollama" is an alias for "custom", but the warning explicitly says unknown provider 'ollama'.

Reproduction steps

  1. docker compose up -d with the official nousresearch/hermes-agent:latest image
  2. Edit /opt/data/config.yaml:
    • model.default: "hermes3:8b"
    • model.provider: "custom"
    • model.base_url: "http://<local-ollama>:11434/v1"
  3. Remove OPENROUTER_API_KEY (and any other provider keys) from /opt/data/.env
  4. docker restart <container>
  5. Create a job: POST /api/jobs with a simple prompt
  6. Force-run: POST /api/jobs/{id}/run
  7. Check last_status — it stays error with Agent completed but produced empty response
  8. Check gateway logs — you'll see the provider is openrouter instead of custom

Impact

Agent jobs (scheduled cron via /api/jobs) cannot run against a local LLM, which forces us to keep a paid OpenRouter subscription just to use Hermes Agent as a self-healing monitor — defeating the "self-hosted" value proposition.

Workaround

Currently none — even explicit provider: custom + base_url does not force local routing. We tested both provider: "custom" and provider: "ollama"; both fall back to openrouter in agent runs.

We'd appreciate guidance on the correct way to force local-only inference for agent runs.


Thanks for the great project — we've got a working /v1/chat/completions flow through the same config (proving routing works in some code paths), so this feels like a narrow bug somewhere in the agent-run code path. Happy to provide more diagnostics or test a patch.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High — major feature broken, no workaroundarea/configConfig system, migrations, profilescomp/agentCore agent loop, run_agent.py, prompt buildertype/bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions