hermes - 💡(How to fix) Fix Custom providers in config.providers are misclassified as unknown by and doctor [1 comments, 1 participants]

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.\n```\n\nand 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.\n\n## Environment\n\n- Reproduced on official `main`\n- Commit: `6fdbf2f2d76cf37393e657bf37ceda3d84589200`\n- Remote: `https://github.com/NousResearch/hermes-agent.git`\n\n## Repro\n\nUse a config like:\n\n```yaml\nmodel:\n  default: doubao-seed-2.0-code\n  provider: volcengine-plan\n\nproviders:\n  volcengine-plan:\n    name: volcengine-plan\n    base_url: https://ark.cn-beijing.volces.com/api/coding/v3\n    api_key: ${VOLCENGINE_API_KEY}\n    default_model: doubao-seed-2.0-code\n    models:\n      doubao-seed-2.0-code: {}\n```\n\nThen run:\n\n```bash\nhermes model\n```\n\n### Actual\n\n1. `hermes model` first prints:\n\n```text\nWarning: Unknown provider 'volcengine-plan'. Check 'hermes model' for available providers, or run 'hermes doctor' to diagnose config issues. Falling back to auto provider detection.\n```\n\n2. The picker then still shows the provider correctly, for example:\n\n```text\n29. volcengine-plan (ark.cn-beijing.volces.com/api/coding/v3) — doubao-seed-2.0-code\n```\n\n3. Selecting that provider succeeds and fetches models from the endpoint.\n\n4. `hermes doctor` / Web UI diagnostics also misclassify `model.provider: volcengine-plan` as unknown.\n\n### Expected\n\nIf 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.\n\n## Root cause\n\nThere are currently two different provider-resolution paths in play:\n\n- The shared switch/runtime flows correctly support user-defined providers via `resolve_provider_full(...)` and compatibility helpers.\n- But some validation/display entrypoints still call `resolve_provider(...)`, which only knows built-in providers.\n\n### Affected call sites\n\n1. `hermes_cli/main.py`\n\n`select_provider_and_model()` pre-validates the current provider with:\n\n```py\nactive = resolve_provider(effective_provider)\n```\n\nThis is what emits the false `Unknown provider` warning before the picker opens.\n\n2. `hermes_cli/doctor.py`\n\nDoctor validates `model.provider` with:\n\n```py\ncanonical_provider = _resolve_provider(provider)\n```\n\nThis incorrectly reports user-defined `providers:` entries as unknown.\n\n## Suggested fix\n\nUse the user-aware resolution path for these validation/entrypoint checks, e.g. `resolve_provider_full(...)` with:\n\n- `cfg.get("providers")`\n- `get_compatible_custom_providers(cfg)`\n\nThat should bring `hermes model`, `doctor`, and UI diagnostics into alignment with the already-correct picker/runtime behavior.\n\n## Notes\n\nThis is not a local divergence issue: the reproduction above was verified against official `main` at `6fdbf2f2d76cf37393e657bf37ceda3d84589200`.\n