[BUG] "Fetch available models" fails on every route: Ark /models rejects x-api-key (401), postpaid baseURL yields 404

Start by reading the provider route definitions and the model discovery adapter used by the plugin; the report names the anthropic-messages plan routes and postpaid routes with a /api/v3/compatible base URL. Check how discovery builds its authentication header and URL, then verify the expected /models paths and behavior against the route configuration. Done means discovery succeeds where supported, or the unsupported routes are clearly documented and the UI guidance matches.

Summary

@volcengine/[email protected] on DeepSeek Harness Desktop 0.2.1-rc.2: the plugin loads correctly, the Ark providers appear in Settings → Models, and inference works — but "Fetch available models" (获取可用模型) fails on every route this plugin registers, even with a valid API key.

The reported 401 is misleading: the key is valid. The discovery request uses the wrong auth header for Ark's /models endpoint.

Environment

• macOS (Apple Silicon), DSH Desktop 0.2.1-rc.2 (bundled Node 24.21.0, pnpm 11.28.5)
• @volcengine/[email protected], installed into the desktop profile
• Routes visible in Settings → Models: Ark Agent Plan, Ark Coding Plan, Ark Coding Plan (BytePlus), Ark (后付费), Ark BytePlus (后付费)

Steps to reproduce

1. Install: dsh plugin --profile desktop add @volcengine/ark-plan-api and restart DSH.
2. Settings → Models → Ark Coding Plan → paste a valid Ark Coding Plan API key → Save.
3. Click Fetch available models (获取可用模型).

Actual

https://ark.cn-beijing.volces.com/api/coding/v1/models?limit=1000 answered 401; check the API key

Expected

HTTP 200 and a model list (Ark returns 137 models for this key).

Evidence — same key, only the auth header differs

Request	Result
GET /api/coding/v1/models?limit=1000 + Authorization: Bearer <key>	200 (137 models)
GET /api/coding/v1/models?limit=1000 + x-api-key: <key>	401 the API key or AK/SK in the request is missing or invalid
GET /api/coding/v1/models?limit=1000 + both headers	200
POST /api/coding/v1/messages + x-api-key: <key>	200 (inference OK)
POST /api/coding/v1/messages + Authorization: Bearer <key>	200

Conclusion: Ark's /messages accepts both auth styles (so the key and the route are fine), but Ark's /models only accepts Authorization: Bearer.

Root cause

DSH's bundled @deepseek-ai/dsh-llm-pi-ai builds the model-discovery request per API style:

• for api: anthropic-messages it sends x-api-key only (source comment: "Anthropic Messages uses x-api-key");
• the discovery URL is ${baseURL minus trailing /v1}/v1/models?limit=….

Because this plugin declares api: anthropic-messages for the plan routes, discovery is sent with x-api-key, which Ark's /models rejects with 401.

Second, separate problem: postpaid routes hit a non-existent discovery path

The postpaid routes declare:

baseURL: https://ark.cn-beijing.volces.com/api/v3/compatible

so discovery requests https://ark.cn-beijing.volces.com/api/v3/compatible/models → 404.
Ark's OpenAI-compatible model list lives at https://ark.cn-beijing.volces.com/api/v3/models → 200 (verified with the same key).

If /compatible is required for inference, this route has no correct discovery path at all.

Impact

• Only model discovery is broken. The model picker and inference work, because every provider's model list is already statically declared in the bundle's cordis.patch.yml.
• The UX is still damaging: the UI says "check the API key", so users conclude their key is invalid and cannot diagnose it. Related: #28 (plugin not visible at all on 0.2.0-rc.2 — different symptom; on 0.2.1-rc.2 the providers do appear and inference works).

Suggested fixes

1. Plan routes (anthropic-messages): make model discovery authenticate with Authorization: Bearer (or send both headers) for these providers. If the adapter does not allow per-provider discovery overrides, document that "Fetch available models" is unsupported on plan routes and that the predeclared model list should be used instead (ideally disable/hide the button for those routes).
2. Postpaid routes: consider baseURL: https://ark.cn-beijing.volces.com/api/v3 (drop /compatible) so /models discovery resolves; otherwise document discovery as unsupported for this route.
3. Docs: state explicitly which routes support model discovery, since the model list is already declared and discovery is optional.

Notes

• Upstream DSH hard-codes the discovery auth header and discards the non-2xx response body (answered 401; check the API key), so the real Ark error is invisible to the user. A DSH-side improvement would be to surface the body. deepseek-ai/deepseek-harness has Issues disabled (Discussions only), so this is not filed there.
• No credentials are included in this report; requests were made locally with the reporter's own key.

---

中文摘要

@volcengine/[email protected] + DSH Desktop 0.2.1-rc.2：插件生效、Ark provider 可见、对话推理正常，但「设置 → 模型 → 获取可用模型」在所有路由上都失败。

• key 本身有效：用 Authorization: Bearer 请求 https://ark.cn-beijing.volces.com/api/coding/v1/models?limit=1000 返回 200（137 个模型）；/api/coding/v1/messages 也是 200。
• 401 的真正原因：DSH 的 dsh-llm-pi-ai 对 api: anthropic-messages 的 provider 做模型发现时只发 x-api-key，而 Ark 的 /models 只接受 Authorization: Bearer（实测 x-api-key → 401；两种头同时发 → 200；但 /messages 两种头都接受）。
• 后付费路由另有问题：baseURL 是 .../api/v3/compatible，模型发现请求 .../api/v3/compatible/models → 404；Ark 的 OpenAI 兼容模型列表在 .../api/v3/models → 200。

建议：① plan 路由的模型发现改用 Authorization: Bearer（或两种头都发），若不支持则在文档中说明并用内置模型列表；② 后付费路由 baseURL 考虑去掉 /compatible；③ 明确文档说明哪些路由支持"获取可用模型"。