🐛 Alibaba provider hardcoded to coding-intl endpoint — breaks standard DashScope API keys

[ankinow]

Problem Description

The Alibaba Cloud (DashScope) provider has a hardcoded default endpoint that doesn't work with standard DashScope API keys! (╥﹏╥)

Root Cause

In hermes_cli/auth.py line 163:

"alibaba": ProviderConfig(
    id="alibaba",
    name="Alibaba Cloud (DashScope)",
    auth_type="***",
    inference_base_url="https://coding-intl.dashscope.aliyuncs.com/v1",  # ← hardcoded!
    api_key_env_vars=("DASH...",),
    base_url_env_var="DASHSCOPE_BASE_URL",
),

The coding-intl endpoint is only for Alibaba Coding Plan keys, not standard DashScope API keys!

Three Endpoints, Three Key Types

Endpoint	Status	Key Type Required
https://coding-intl.dashscope.aliyuncs.com/v1	❌ Hardcoded default	Coding Plan key only
https://dashscope.aliyuncs.com/compatible-mode/v1	❌ China region	China-registered keys
https://dashscope-intl.aliyuncs.com/compatible-mode/v1	✅ International	Standard DashScope keys

Error When Using Standard Key

{
  "error": {
    "message": "Incorrect API key provided. For details, see: https://help.aliyun.com/zh/model-studio/error-code#apikey-error",
    "type": "invalid_request_error",
    "code": "invalid_api_key"
  }
}

Current Workaround

Setting DASHSCOPE_BASE_URL in .env to override:

DASHSCOPE_BASE_URL=https://dashscope-intl.aliyuncs.com/compatible-mode/v1

And also setting base_url in config.yaml:

model:
  default: qwen3.5-plus
  provider: alibaba
  base_url: https://dashscope-intl.aliyuncs.com/compatible-mode/v1

This works! But the default should be the endpoint that works with standard keys~

Proposed Fix

Change the default inference_base_url in auth.py to the international OpenAI-compatible endpoint:

"inference_base_url": "https://dashscope-intl.aliyuncs.com/compatible-mode/v1",

This is the endpoint that:

• Works with standard DashScope API keys (the most common type)
• Supports OpenAI-compatible chat completions
• Routes to the international (Singapore) region

Users with Coding Plan keys can still override via DASHSCOPE_BASE_URL env var.

Additional Context

The models.py comments already acknowledge this (lines 211-215):

# Alibaba DashScope Coding platform (coding-intl) — default endpoint.
# Supports Qwen models + third-party providers (GLM, Kimi, MiniMax).
# Users with classic DashScope keys should override DASHSCOPE_BASE_URL
# to https://dashscope-intl.aliyuncs.com/compatible-mode/v1 (OpenAI-compat)

So the code knows standard keys need a different endpoint, but defaults to the Coding Plan one anyway~ This seems backwards! The default should serve the majority of users (standard keys), with Coding Plan users as the override case.

Verification

# Standard DashScope key - FAILS on coding-intl
curl https://coding-intl.dashscope.aliyuncs.com/v1/chat/completions \
  -H "Authorization: Bearer sk-standard-key" \
  -d '{"model":"qwen3.5-plus","messages":[{"role":"user","content":"test"}],"max_tokens":10}'
# → 401 invalid_api_key

# Standard DashScope key - WORKS on intl compatible-mode
curl https://dashscope-intl.aliyuncs.com/compatible-mode/v1/chat/completions \
  -H "Authorization: Bearer sk-standard-key" \
  -d '{"model":"qwen3.5-plus","messages":[{"role":"user","content":"test"}],"max_tokens":10}'
# → 200 OK ✨

---

Tested on Ubuntu 24.04, Hermes v0.5.0, Qwen 3.5 Plus via DashScope Singapore region ヽ(>∀<☆)ノ

[lianzhiweivincent-cloud]

This split is important and easy to miss:

• coding-intl.dashscope.aliyuncs.com/v1 is the Coding Plan route.
• dashscope-intl.aliyuncs.com/compatible-mode/v1 is the international OpenAI-compatible DashScope route.
• A standard DashScope key can be valid but still return 401 if Hermes sends it to the Coding Plan host.

For provider implementations, I would keep these as separate provider profiles instead of treating Alibaba as one default endpoint:

provider: alibaba-dashscope-compatible
base_url: https://dashscope-intl.aliyuncs.com/compatible-mode/v1
key_env: DASHSCOPE_API_KEY

and, separately:

provider: alibaba-coding-plan
base_url: https://coding-intl.dashscope.aliyuncs.com/v1
key_env: BAILIAN_CODING_PLAN_API_KEY

That makes the 401 easier to explain: wrong key for host, wrong region, or missing workspace/model permission.

I wrote a short checklist for the same key/endpoint mismatch pattern here:
https://black-eagle-ai.vercel.app/guides/qwen-code-401-coding-plan/

Disclosure: I am involved with Black Eagle AI, an independent OpenAI-compatible relay for Chinese models. If direct DashScope works, direct provider access is cleaner. If the blocker is account/payment/workspace setup, a small prepaid relay can be useful as a fallback test endpoint.