fix(providers): register Alibaba China + Token Plan provider profiles (#73265)

The models.dev catalog advertises alibaba-cn, alibaba-coding-plan-cn, and
alibaba-token-plan(-cn), and resolve_provider_full()'s catalog chain lets
the CLI --provider path resolve them — but auth.resolve_provider() (the
credential/runtime path used by 'hermes chat') consults only
PROVIDER_REGISTRY and raised "Unknown provider 'alibaba-coding-plan-cn'"
(hermes_cli/auth.py:1937). PROVIDER_REGISTRY auto-extends from provider
profiles (auth.py:461-490), so the fix registers the missing profiles at
that chokepoint: alibaba-cn joins the alibaba plugin, alibaba-coding-plan-cn
joins alibaba-coding-plan, and a new alibaba-token-plan plugin registers
both regional token-plan tiers. Names match the catalog keys exactly.

No core edits — plugins/model-providers is the designed extension path.
This commit is contained in:
Ayush Nangia
2026-07-28 18:15:29 +05:30
committed by Teknium
parent d6a6d87c4a
commit 7cf7df0297
5 changed files with 144 additions and 2 deletions

View File

@@ -262,3 +262,60 @@ class TestQwenProfile:
def test_build_api_kwargs_extras_empty(self):
p = ProviderProfile(name="test")
eb, tl = p.build_api_kwargs_extras()
assert eb == {}
assert tl == {}
class TestAlibabaRegionalAndTokenPlanProfiles:
"""#73265: the models.dev catalog advertises alibaba-cn /
alibaba-token-plan(-cn) / alibaba-coding-plan-cn, but none were registered
at runtime — `model.provider: alibaba-coding-plan-cn` failed with
"Unknown provider" and users were forced onto the `custom` escape hatch.
Profile names intentionally match the catalog keys exactly so model
metadata lines up."""
def test_alibaba_cn_registered(self):
p = get_provider_profile("alibaba-cn")
assert p is not None and p.name == "alibaba-cn"
assert p.base_url == "https://dashscope.aliyuncs.com/compatible-mode/v1"
assert "DASHSCOPE_API_KEY" in p.env_vars
def test_alibaba_coding_plan_cn_registered(self):
p = get_provider_profile("alibaba-coding-plan-cn")
assert p is not None and p.name == "alibaba-coding-plan-cn"
assert p.base_url == "https://coding.dashscope.aliyuncs.com/v1"
assert "ALIBABA_CODING_PLAN_API_KEY" in p.env_vars
def test_alibaba_token_plan_registered(self):
p = get_provider_profile("alibaba-token-plan")
assert p is not None and p.name == "alibaba-token-plan"
assert p.base_url == "https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1"
assert "ALIBABA_TOKEN_PLAN_API_KEY" in p.env_vars
def test_alibaba_token_plan_cn_registered(self):
p = get_provider_profile("alibaba-token-plan-cn")
assert p is not None and p.name == "alibaba-token-plan-cn"
assert p.base_url == "https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1"
assert "ALIBABA_TOKEN_PLAN_API_KEY" in p.env_vars
def test_cn_variants_resolve_in_auth_registry(self, monkeypatch):
"""The reporter's exact failure site: ``auth.resolve_provider()`` only
consults PROVIDER_REGISTRY (auto-extended from provider profiles,
hermes_cli/auth.py:461-490) and raised
"Unknown provider 'alibaba-coding-plan-cn'" (hermes_cli/auth.py:1937)
even though the models.dev catalog advertised the id — the
resolve_provider_full() catalog chain covers only the CLI --provider
path, not the credential/runtime path."""
from hermes_cli.auth import PROVIDER_REGISTRY, resolve_provider
monkeypatch.setenv("DASHSCOPE_API_KEY", "sk-test")
monkeypatch.setenv("ALIBABA_CODING_PLAN_API_KEY", "sk-test")
monkeypatch.setenv("ALIBABA_TOKEN_PLAN_API_KEY", "sk-test")
for pid in ("alibaba-cn", "alibaba-coding-plan-cn",
"alibaba-token-plan", "alibaba-token-plan-cn"):
assert pid in PROVIDER_REGISTRY, f"{pid} missing from PROVIDER_REGISTRY"
assert resolve_provider(pid) == pid
assert (PROVIDER_REGISTRY["alibaba-token-plan-cn"].inference_base_url
== "https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1")