Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix Custom providers in config.providers are misclassified as unknown by hermes model and doctor [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#14850•Fetched 2026-04-24 06:14:26
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
linglichaolinglichao
Participants
linglichaolinglichao
Timeline (top)
labeled ×4cross-referenced ×3

Named user-defined providers configured under config.yaml -> providers: are correctly surfaced in picker/runtime flows, but some validation/entrypoint code paths still treat them as unknown because they call hermes_cli.auth.resolve_provider() (built-in providers only) instead of the user-aware provider resolution path.

This produces false warnings like:

Warning: Unknown provider 'volcengine-plan'. Check 'hermes model' for available providers, or run 'hermes doctor' to diagnose config issues. Falling back to auto provider detection.

and config diagnostics like model.provider points to a provider not found in config, even though the provider is present in config.yaml, appears in the model picker, and can fetch models successfully.

Root Cause

There are currently two different provider-resolution paths in play:

  • The shared switch/runtime flows correctly support user-defined providers via resolve_provider_full(...) and compatibility helpers.
  • But some validation/display entrypoints still call resolve_provider(...), which only knows built-in providers.

Fix Action

Fixed

PR fix notes

PR #14857: fix(cli): validate user-defined providers consistently

Description (problem / solution / changelog)

Summary

  • resolve the active provider in through the user-aware provider resolver
  • teach ┌─────────────────────────────────────────────────────────┐ │ 🩺 Hermes Doctor │ └─────────────────────────────────────────────────────────┘

◆ Python Environment ✓ Python 3.12.8 ⚠ Not in virtual environment (recommended)

◆ Required Packages ✓ OpenAI SDK ✓ Rich (terminal UI) ✓ python-dotenv ✓ PyYAML ✓ HTTPX ⚠ Croniter (cron expressions) (optional, not installed) ⚠ python-telegram-bot (optional, not installed) ⚠ discord.py (optional, not installed)

◆ Configuration Files ✓ ~/.hermes/.env file exists ✓ API key or custom endpoint configured ✓ ~/.hermes/config.yaml exists ✗ model.provider 'kimi-coding' is not a recognised provider (known: ai-gateway, alibaba, anthropic, arcee, auto, bedrock, copilot, copilot-acp, custom, deepseek, gemini, google-gemini-cli, huggingface, kilocode, kimi-coding, kimi-coding-cn, minimax, minimax-cn, nous, nvidia, ollama-cloud, openai-codex, opencode-go, opencode-zen, openrouter, qwen-oauth, stepfun, xai, xiaomi, zai) ⚠ Config version outdated (v16 → v22) (new settings available)

◆ Auth Providers ⚠ Nous Portal auth (not logged in) ✓ OpenAI Codex auth (logged in) ⚠ Google Gemini OAuth (not logged in) ✓ codex CLI

◆ Directory Structure ✓ ~/.hermes directory exists ✓ ~/.hermes/cron/ exists ✓ ~/.hermes/sessions/ exists ✓ ~/.hermes/logs/ exists ✓ ~/.hermes/skills/ exists ✓ ~/.hermes/memories/ exists ✓ ~/.hermes/SOUL.md exists (persona configured) ✓ ~/.hermes/memories/ directory exists → MEMORY.md not created yet (will be created when the agent first writes a memory) → USER.md not created yet (will be created when the agent first writes a memory) ✓ ~/.hermes/state.db exists (91 sessions)

◆ Command Installation ✓ Venv entry point exists (.venv/bin/hermes) ⚠ ~/.local/bin/hermes points to wrong target (→ /Users/leongong/Library/Python/3.12/bin/hermes, expected → /Users/leongong/Desktop/LeonProjects/gho_workspace/hermes-agent/.venv/bin/hermes)

◆ External Tools ✓ git ✓ ripgrep (rg) (faster file search) ✓ docker (optional) ✓ Node.js ⚠ agent-browser not installed (run: npm install)

◆ API Connectivity ⚠ OpenRouter API (not configured) Checking Kimi / Moonshot API... ⚠ Kimi / Moonshot (HTTP 402)

◆ Submodules ⚠ tinker-atropos not found (run: git submodule update --init --recursive)

◆ Tool Availability ✓ browser ✓ clarify ✓ code_execution ✓ cronjob ✓ delegation ✓ file ✓ image_gen ✓ memory ✓ terminal ✓ session_search ✓ skills ✓ todo ✓ tts ✓ vision ⚠ browser-cdp (system dependency not met) ⚠ discord (missing DISCORD_BOT_TOKEN) ⚠ feishu_doc (system dependency not met) ⚠ feishu_drive (system dependency not met) ⚠ homeassistant (system dependency not met) ⚠ moa (missing OPENROUTER_API_KEY) ⚠ rl (missing TINKER_API_KEY, WANDB_API_KEY) ⚠ messaging (system dependency not met) ⚠ web (missing EXA_API_KEY, PARALLEL_API_KEY, TAVILY_API_KEY, FIRECRAWL_API_KEY, FIRECRAWL_API_URL)

◆ Skills Hub ✓ Skills Hub directory exists ⚠ No GITHUB_TOKEN (60 req/hr rate limit — set in ~/.hermes/.env for better rates)

◆ Memory Provider ✓ Built-in memory active (no external provider configured — this is fine)

──────────────────────────────────────────────────────────── Found 4 issue(s) to address:

  1. model.provider 'kimi-coding' is unknown. Valid providers: ai-gateway, alibaba, anthropic, arcee, auto, bedrock, copilot, copilot-acp, custom, deepseek, gemini, google-gemini-cli, huggingface, kilocode, kimi-coding, kimi-coding-cn, minimax, minimax-cn, nous, nvidia, ollama-cloud, openai-codex, opencode-go, opencode-zen, openrouter, qwen-oauth, stepfun, xai, xiaomi, zai. Fix: run 'hermes config set model.provider <valid_provider>'
  2. Run 'hermes doctor --fix' or 'hermes setup' to migrate config
  3. Broken symlink at ~/.local/bin/hermes — run 'hermes doctor --fix'
  4. Run 'hermes setup' to configure missing API keys for full tool access

Tip: run 'hermes doctor --fix' to auto-fix what's possible. to validate and saved custom providers alongside built-in providers

  • add regression tests covering both the picker and doctor diagnostics for named providers from

Closes #14850

Testing

  • python3 -m pytest -o addopts= tests/hermes_cli/test_setup.py
  • python3 -m pytest -o addopts= tests/hermes_cli/test_doctor.py

Changed files

  • hermes_cli/doctor.py (modified, +23/-6)
  • hermes_cli/main.py (modified, +23/-6)
  • tests/hermes_cli/test_doctor.py (modified, +53/-0)
  • tests/hermes_cli/test_setup.py (modified, +35/-0)

Code Example

Warning: Unknown provider 'volcengine-plan'. Check 'hermes model' for available providers, or run 'hermes doctor' to diagnose config issues. Falling back to auto provider detection.

---

model:
  default: doubao-seed-2.0-code
  provider: volcengine-plan

providers:
  volcengine-plan:
    name: volcengine-plan
    base_url: https://ark.cn-beijing.volces.com/api/coding/v3
    api_key: ${VOLCENGINE_API_KEY}
    default_model: doubao-seed-2.0-code
    models:
      doubao-seed-2.0-code: {}

---

hermes model

---

Warning: Unknown provider 'volcengine-plan'. Check 'hermes model' for available providers, or run 'hermes doctor' to diagnose config issues. Falling back to auto provider detection.

---

29. volcengine-plan (ark.cn-beijing.volces.com/api/coding/v3) — doubao-seed-2.0-code

---

active = resolve_provider(effective_provider)

---

canonical_provider = _resolve_provider(provider)
RAW_BUFFERClick to expand / collapse

Summary

Named user-defined providers configured under config.yaml -> providers: are correctly surfaced in picker/runtime flows, but some validation/entrypoint code paths still treat them as unknown because they call hermes_cli.auth.resolve_provider() (built-in providers only) instead of the user-aware provider resolution path.

This produces false warnings like:

Warning: Unknown provider 'volcengine-plan'. Check 'hermes model' for available providers, or run 'hermes doctor' to diagnose config issues. Falling back to auto provider detection.

and config diagnostics like model.provider points to a provider not found in config, even though the provider is present in config.yaml, appears in the model picker, and can fetch models successfully.

Environment

  • Reproduced on official main
  • Commit: 6fdbf2f2d76cf37393e657bf37ceda3d84589200
  • Remote: https://github.com/NousResearch/hermes-agent.git

Repro

Use a config like:

model:
  default: doubao-seed-2.0-code
  provider: volcengine-plan

providers:
  volcengine-plan:
    name: volcengine-plan
    base_url: https://ark.cn-beijing.volces.com/api/coding/v3
    api_key: ${VOLCENGINE_API_KEY}
    default_model: doubao-seed-2.0-code
    models:
      doubao-seed-2.0-code: {}

Then run:

hermes model

Actual

  1. hermes model first prints:
Warning: Unknown provider 'volcengine-plan'. Check 'hermes model' for available providers, or run 'hermes doctor' to diagnose config issues. Falling back to auto provider detection.
  1. The picker then still shows the provider correctly, for example:
29. volcengine-plan (ark.cn-beijing.volces.com/api/coding/v3) — doubao-seed-2.0-code

  1. Selecting that provider succeeds and fetches models from the endpoint.

  2. hermes doctor / Web UI diagnostics also misclassify model.provider: volcengine-plan as unknown.

Expected

If a provider exists in config.yaml -> providers: (or the compatibility view from get_compatible_custom_providers()), entrypoint validation and diagnostics should accept it consistently. No false warning should be emitted before opening the picker, and doctor should not report the provider as unknown.

Root cause

There are currently two different provider-resolution paths in play:

  • The shared switch/runtime flows correctly support user-defined providers via resolve_provider_full(...) and compatibility helpers.
  • But some validation/display entrypoints still call resolve_provider(...), which only knows built-in providers.

Affected call sites

  1. hermes_cli/main.py

select_provider_and_model() pre-validates the current provider with:

active = resolve_provider(effective_provider)

This is what emits the false Unknown provider warning before the picker opens.

  1. hermes_cli/doctor.py

Doctor validates model.provider with:

canonical_provider = _resolve_provider(provider)

This incorrectly reports user-defined providers: entries as unknown.

Suggested fix

Use the user-aware resolution path for these validation/entrypoint checks, e.g. resolve_provider_full(...) with:

  • cfg.get("providers")
  • get_compatible_custom_providers(cfg)

That should bring hermes model, doctor, and UI diagnostics into alignment with the already-correct picker/runtime behavior.

Notes

This is not a local divergence issue: the reproduction above was verified against official main at 6fdbf2f2d76cf37393e657bf37ceda3d84589200.

extent analysis

TL;DR

Update the provider resolution in hermes_cli/main.py and hermes_cli/doctor.py to use the user-aware resolve_provider_full function.

Guidance

  • Replace resolve_provider with resolve_provider_full in hermes_cli/main.py to correctly validate user-defined providers.
  • Update hermes_cli/doctor.py to use resolve_provider_full for validating model.provider to avoid reporting user-defined providers as unknown.
  • Pass cfg.get("providers") and get_compatible_custom_providers(cfg) to resolve_provider_full to ensure it has the necessary information to resolve user-defined providers.
  • Verify the fix by running hermes model and checking that the warning about the unknown provider is no longer emitted.

Example

# In hermes_cli/main.py
active = resolve_provider_full(effective_provider, cfg.get("providers"), get_compatible_custom_providers(cfg))

# In hermes_cli/doctor.py
canonical_provider = resolve_provider_full(provider, cfg.get("providers"), get_compatible_custom_providers(cfg))

Notes

This fix assumes that resolve_provider_full is correctly implemented to handle user-defined providers. If issues persist, further debugging of resolve_provider_full may be necessary.

Recommendation

Apply the suggested fix to update the provider resolution in hermes_cli/main.py and hermes_cli/doctor.py to use the user-aware resolve_provider_full function, as this should bring the behavior of hermes model, doctor, and UI diagnostics into alignment with the picker/runtime behavior.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#inference speed#output truncation#response parsing#generation error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING