Plugin providers resolve in /model, the model picker and hermes model, aliases land on the canonical name (#69576, salvage #52549 #54705 #65968 #34368)

[teknium1]

Out-of-tree model-provider plugins now resolve everywhere a provider NAME is resolved at switch time — /model --provider <plugin|alias>, the Desktop/TUI model picker (tui_gateway → switch_model) and hermes model — including profiles whose endpoint is minted at runtime, and an alias switch lands on the profile's canonical name.

Part of #116408. Closes #69576.

What changed

• hermes_cli/providers.py::resolve_provider_full gains a last rung: any registered ProviderProfile becomes a ProviderDef after every user-configured rung (providers:, custom_providers:, managed llamacpp, models.dev), so config keeps precedence. Only the bare custom placeholder (aliases ollama/local/vllm) is excluded — model-switch completes it from the current endpoint, as before.
• get_provider() and the new rung share one builder (_plugin_profile_pdef): the ProviderDef.id is profile.name (not the requested alias), URL-shaped env vars (*_BASE_URL/*_URL) are the endpoint override rather than credentials, and a profile with an env-configured endpoint resolves at the get_provider() rung (@WolframRavenwolf, fix(providers): resolve ProviderProfile identity consistently #52549).
• hermes_cli/runtime_provider.py: a persisted model.provider written under a profile alias is the same registered provider as its canonical name, so its base_url/api_mode overrides apply (@WolframRavenwolf, fix(providers): resolve ProviderProfile identity consistently #52549 — compares the two registry rows' shared ProviderConfig.id; does not touch _detect_api_mode_for_url / profile api_mode propagation, which [Bug]: provider plugins' ProviderProfile.api_mode dropped at runtime — anthropic_messages plugins with non-/anthropic base_url 404 #53054's lane owns).
• Docs: website/docs/developer-guide/model-provider-plugin.md integration table row for /model --provider + model picker switch.
• Tests: tests/hermes_cli/test_provider_profile_identity.py — three invariants over a real plugin dir under the test HERMES_HOME (discovery + auth mirror real, only the remote model probe stubbed), all red on origin/main:
  1. alias switch carries the canonical identity + user providers: block wins,
  2. runtime-endpoint profile is a known provider while custom/ollama/custom:<x> placeholders stay None,
  3. persisted alias config applies to the canonical runtime provider.

Root cause

get_provider()'s plugin rung (7072fc4) admitted only profiles with a literal base_url and returned id=<requested alias>; a profile with an empty base_url (endpoint computed at runtime, vertex-style) never reached any rung of resolve_provider_full, so switch_model() rejected it as Unknown provider, while the picker listed it and the aux client already accepted it through the PROVIDER_REGISTRY mirror.

Live probe (temp HERMES_HOME, real plugin dir, real imports, providers*/hermes_cli*/agent* purged)

Profiles: example-key (base_url set, alias example-alias, anthropic_messages), example-runtime (empty base_url, api_key auth).

Surface	Name	base (76fe8f7)	head
resolve_provider_full	example-key	id=example-key ✅	identical ✅
resolve_provider_full	example-alias	id=example-alias (alias leaks as identity)	id=example-key ✅
resolve_provider_full	example-runtime	None ❌	id=example-runtime, source=plugin-profile ✅
switch_model(--provider)	example-key	target=example-key ✅	identical ✅
switch_model(--provider)	example-alias	target=example-alias	target=example-key ✅
switch_model(--provider)	example-runtime	Unknown provider 'example-runtime' ❌	target=example-runtime, api_key resolved ✅
tui_gateway.server._apply_model_switch (Desktop/TUI picker RPC)	example-runtime / rt-alias	Unknown provider ❌	model_override.provider=example-runtime for both ✅
aux.resolve_provider_client	example-key / alias / runtime	✅ (already via PROVIDER_REGISTRY mirror)	identical ✅
negative: custom, ollama, vllm, custom:nope (no custom_providers)	—	None	None ✅
negative: no-such-provider	—	None	None ✅
control: nous, openai-codex, anthropic, openrouter, custom:foo, kimi-coding-cn, azure-foundry, vertex	resolve_provider_full dict	—	byte-identical to base
vertex-ai (bundled profile alias)	resolve_provider_full	id=vertex-ai	id=vertex (intended: the profile-only alias @teknium1 named on #65968)

Tests: scripts/run_tests.sh tests/hermes_cli/ tests/agent/test_auxiliary_client_resolve_dedup.py tests/providers/ — the only failures (test_dashboard_auth_gate ×4, test_cmd_update::test_venv_repair_path_refreshes_memory_provider [uv not on PATH], test_local_runtime_recovery::test_reparented_router_keeps_its_endpoint [live-guard]) reproduce identically on a pristine origin/main worktree.

Salvage / credit

• Cherry-picked: fix(providers): preserve profile aliases and endpoint configuration — @WolframRavenwolf (fix(providers): resolve ProviderProfile identity consistently #52549, authorship preserved; its 266-line test file is replaced by the three invariants above in the follow-up commit; fix(providers): resolve ProviderProfile identity consistently #52549 carries Co-authored-by @david-bowiegxw for the discovery fixture provenance).
• Co-authored on the tail-rung commit: @Kyzcreig (fix(model-switch): resolve provider-module plugin providers in switch path #34368, earliest — closed by its author in favour of fix(providers): resolve ProviderProfile identity consistently #52549), @woota (fix(providers): resolve plugin-registered providers in resolve_provider_full() #54705), @byboscobarros (fix(cli): resolve model-provider plugins in /model --provider #65968) — all three proposed the same resolve_provider_full fallback; main had since landed it in get_provider() for concrete-endpoint profiles (7072fc4 by @greyvito), so what remained was the runtime-endpoint case + alias identity.
• @TF0rd (fix(auxiliary): fallback to providers plugin registry in resolve_provider_client #41544, aux client fallback): the mechanism is on main already — hermes_cli/auth_plugin_providers.py::sync_plugin_provider_registry runs at auth import, on registry miss (registry_lookup) and after discovery, and the probe shows resolve_provider_client green on base for name, alias and runtime-endpoint profiles even with hermes_cli.auth imported before providers discovery. Nothing to salvage; close as implemented-on-main with credit for the diagnosis.
• @nateEc (fix(models): resolve plugin-only providers during switches #69993, closed): same tail rung + vertex-ai alias regression; superseded by this PR.

Not covered

• Profile api_mode propagation into ProviderConfig / _detect_api_mode_for_url fallback order — owned by [Bug]: provider plugins' ProviderProfile.api_mode dropped at runtime — anthropic_messages plugins with non-/anthropic base_url 404 #53054's lane (fix(providers): a registered transport is reachable, and a late plugin profile is not dropped #116154 / fix(providers): gate plugin api_mode by endpoint (#53054) #53055); fix(providers): resolve ProviderProfile identity consistently #52549's runtime_provider.py hunk here is identity-only.
• A hand-written model.provider: <alias> in config.yaml still reports requested_provider=<alias>; only the resolved identity/base_url/api_mode are canonical.

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on c81d909 — docs: plugin profiles and their aliases resolve in /model --}

debug info

CI timings

CI timings · View report · View job

Wall time 8m39s vs 8m14s (+5.1%). 8 job(s) slower, 3 faster, 2 unchanged.

• OS-specific tests / Windows-only tests: +41.0s
• Docs Site / docs-site-checks: -30.0s
• Python lints / Windows footguns (blocking): +25.0s
• Python tests / Run tests: +11.0s
• Check contributors / check-attribution: +7.0s