Skip to content

fix(doctor): accept catalog provider aliases#17135

Merged
teknium1 merged 1 commit into
NousResearch:mainfrom
scotttrinh:scotttrinh/fix-doctor-provider-aliases
Apr 29, 2026
Merged

fix(doctor): accept catalog provider aliases#17135
teknium1 merged 1 commit into
NousResearch:mainfrom
scotttrinh:scotttrinh/fix-doctor-provider-aliases

Conversation

@scotttrinh

Copy link
Copy Markdown
Contributor

What does this PR do?

Fixes a false-positive hermes doctor config validation error for
provider ids that have different Hermes runtime ids and models.dev catalog
ids.

The bug showed up with model.provider: ai-gateway: doctor displayed
ai-gateway as a valid provider, but still reported it as unknown because
the provider catalog normalizes ai-gateway to the models.dev id vercel.
The same path also caused doctor to warn incorrectly about vendor-prefixed
model names on aggregator providers.

False errors seen before this fix:

1. model.provider 'ai-gateway' is unknown. Valid providers: ai-gateway, alibaba, alibaba-coding-plan, anthropic, arcee, auto, azure-foundry, bedrock, copilot, copilot-acp, custom, deepseek, gemini, gmi, 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, tencent-tokenhub, xai, xiaomi, zai. Fix: run 'hermes config set model.provider <valid_provider>'
2. model.default 'openai/gpt-4.1' is vendor-prefixed but model.provider is 'ai-gateway'. Either set model.provider to 'openrouter', or drop the vendor prefix.

The fix validates configured providers against both Hermes runtime ids and
catalog-normalized ids, while keeping credential checks and policy warnings
anchored to the runtime id users configured.

This is not limited to ai-gateway. The runtime ids that currently differ
from their catalog-normalized ids are:

ai-gateway     -> vercel
copilot        -> github-copilot
kilocode       -> kilo
kimi-coding    -> kimi-for-coding
kimi-coding-cn -> kimi-for-coding
opencode-zen   -> opencode

Related Issue

Fixes #

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

  • Updated hermes_cli/doctor.py to accept provider ids resolved through
    both runtime auth normalization and catalog normalization.
  • Kept API key checks on the runtime provider id so diagnostics still use
    names users can configure directly.
  • Added regression coverage in tests/hermes_cli/test_doctor.py for
    ai-gateway, opencode-zen, kilocode, and kimi-coding.

How to Test

  1. Configure model.provider: ai-gateway and a vendor-prefixed model such
    as model.default: openai/gpt-4.1.
  2. Run hermes doctor.
  3. Confirm doctor no longer reports ai-gateway as unknown or suggests
    switching the vendor-prefixed model to openrouter.

Regression test run:

scripts/run_tests.sh tests/hermes_cli/test_doctor.py -v

Result: 27 passed.

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: macOS

Documentation & Housekeeping

  • I've updated relevant documentation (README, docs/, docstrings) — or N/A
  • I've updated cli-config.yaml.example if I added/changed config keys — or N/A
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
  • I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
  • I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Validate configured providers against both Hermes runtime provider ids and
catalog-normalized provider ids. This keeps providers like ai-gateway from
being rejected after catalog resolution maps them to models.dev ids.

Keep credential checks and vendor-slug warnings anchored to the runtime id
so doctor reports actionable provider names in follow-up diagnostics.
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/cli CLI entry point, hermes_cli/, setup wizard labels Apr 28, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related to #16085 (tracking issue) and #16086 (comprehensive fix PR). This PR appears to address the same doctor false-positive for aliased providers.

@teknium1 teknium1 merged commit fd94346 into NousResearch:main Apr 29, 2026
stevenchanin added a commit to stevenchanin/hermes-agent that referenced this pull request Apr 30, 2026
NousResearch#17135 fixed doctor for providers whose Hermes runtime id differs from
the models.dev catalog id (ai-gateway, copilot, kilocode, kimi-coding,
kimi-coding-cn, opencode-zen). It missed local-endpoint aliases —
ollama, vllm, llamacpp — which auth.resolve_provider routes to "custom"
but resolve_provider_full has no entry for, so catalog_provider is None.

The validator's failure check started with `if catalog_provider is None
or ...`, which short-circuited and rejected those providers even though
their auth-resolved runtime id ("custom") was already in
provider_ids_to_accept and known_providers.

Drop the short-circuit; rely on the intersection check below. Genuinely
unknown providers (e.g. "completely-made-up") still fail because the
intersection is empty.

Tests: parametrized regression test covering ollama / vllm / llamacpp
(the cases NousResearch#17135 didn't address) plus bedrock and lmstudio (regression
guards — those used to be on the list in NousResearch#16085 but were fixed by
adding a HERMES_OVERLAYS / PROVIDER_REGISTRY entry); an invariant test
asserting every name doctor prints in its "Valid providers" list passes
its own validator; and a negative test asserting a fake provider name
is still rejected.
@stevenchanin

Copy link
Copy Markdown
Contributor

@alt-glitch @teknium1 Thanks for landing this! Narrowed #16086 down to the remaining cases — ollama, vllm, llamacpp still trip the same validator because auth.resolve_provider routes them to custom but resolve_provider_full returns None, so the catalog_provider is None or … short-circuit rejects them before the intersection check runs. The fix is to drop that short-circuit; the runtime-id intersection you set up already accepts them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants