openclaw - ✅(Solved) Fix [Bug] Control UI 选择 DeepSeek 模型时错误添加 moonshot/ 前缀 [1 pull requests, 4 comments, 5 participants]

derekcscn · 2026-03-22T07:08:16Z

[openclaw] PR 51381: fix ui : prevent double-qualifying already-qualified model values - Repository: openclaw/openclaw - Author: Cypherm - State: open | merged… # PR #51381: fix(ui): prevent double-qualifying already-qualified model values - Repository: openclaw/openclaw - Author: Cypherm - State: open | merged: False - Link: https://github.com/openclaw/openclaw/pull/51381 ## Description (problem / solution / changelog) ## Summary **Problem**: When switching models in the Control UI, `resolveServerChatModelValue()` blindly prepends the session's default provider to the model string — even when it's already provider-qualified (e.g. `ollama/gpt-oss:120b-cloud`). This produces invalid refs like `anthropic/ollama/gpt-oss:120b-cloud`, which the server rejects with `model not allowed`. **Why it matters**: Users with multi-provider setups (Ollama + Anthropic, OpenRouter nested models) cannot switch models in the Control UI without hitting this error. **What changed**: - Rewrote `resolveServerChatModelValue()` to use `startsWith(provider + "/")` guard instead of delegating to `buildQualifiedChatModelValue` - `buildQualifiedChatModelValue()` is unchanged — it remains a general-purpose builder - Added test cases for Together vendor-prefixed IDs, OpenRouter nested IDs, and already-qualified detection - Added `chat-model-ref.test.ts` to vitest include list **What did NOT change**: - `buildQualifiedChatModelValue()` is untouched — this PR only changes the call site that resolves server-bound model values - `normalizeChatModelOverrideValue()`, `formatChatModelDisplay()`, `buildChatModelOption()` are untouched - No changes to server-side model resolution or validation ## Change Type - [x] Bug fix (non-breaking) ## Scope UI/DX (Control UI model picker) ## Linked Issue Closes #51139 Closes #51306 Closes #51809 Closes #52002 Closes #52061 Closes #52127 Closes #52173 Closes #52474 ## Security Impact - New permissions requested: none - Secrets handling changes: none - New network calls: none - New command/tool execution: none - Data access changes: none ## Human Verification I personally verified: - [x] `pnpm build` passes - [x] `pnpm test -- ui/src/ui/chat-model-ref.test.ts` — 8/8 tests pass (5 existing + 3 new) - [x] New test: `resolveServerChatModelValue("ollama/gpt-oss:120b-cloud", "anthropic")` returns `"ollama/gpt-oss:120b-cloud"` (not `"anthropic/ollama/gpt-oss:120b-cloud"`) - [x] New test: `resolveServerChatModelValue("openrouter/anthropic/claude-sonnet-4-6", "openrouter")` preserves nested path ## Evidence ``` Test Files 1 passed (1) Tests 8 passed (8) Duration 131ms ``` `git diff --stat upstream/main...HEAD`: 3 files changed, 18 insertions(+) ## What I Did NOT Verify - Not verified: end-to-end in running Control UI with a real multi-provider gateway (tested via unit tests only) - Not verified: edge case where a model alias intentionally contains `/` but is not provider-qualified (no such case exists in the current codebase — `createChatModelOverride` already treats `/` as the qualified signal) ## Failure Recovery If this breaks in production: - **Detection**: Model picker shows wrong model or fails to match selected model - **Rollback**: Revert the single guard clause in `resolveServerChatModelValue` - **Blast radius**: Only affects model selection display/matching — no server-side impact --- 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.6 ## Changed files - `ui/src/ui/chat-model-ref.test.ts` (modified, +33/-0) - `ui/src/ui/chat-model-ref.ts` (modified, +16/-1) - `vitest.config.ts` (modified, +1/-0) ## Fixed - Fixed by PR: fix(ui): prevent double-qualifying already-qualified model values (https://github.com/openclaw/openclaw/pull/51381) ## 问题描述在 Control UI 界面选择 DeepSeek 模型时，系统错误地将模型 ID 设置为 `moonshot/deepseek-chat`，导致请求失败。 ## 错误信息 ``` Failed to set model: GatewayRequestError: model not allowed: moonshot/deepseek-chat ``` ## 预期行为选择 DeepSeek 模型时应该使用正确的 provider 前缀：`deepseek/deepseek-chat` ## 实际行为 Control UI 错误地添加了 `moonshot/` 前缀，导致模型 ID 变成 `moonshot/deepseek-chat`，网关拒绝该请求。 ## 环境信息 - OpenClaw 版本: 2026.3.13 - 界面: Control UI - 浏览器: Web 界面 ## 配置文件配置文件中模型定义是正确的： ```json "deepseek/deepseek-chat": {}, "deepseek/deepseek-reasoner": {} ``` ## 临时解决方案 1. 手动输入模型 ID `deepseek/deepseek-chat` 而不是从下拉菜单选择 2. 通过命令行或 API 直接切换模型 ## 相关 Issue 可能与 Control UI 的模型选择器组件有关。

openclaw2026-03-22 07:08:16

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#52127•Fetched 2026-04-08 01:15:17

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×4cross-referenced ×1

Error Message

Failed to set model: GatewayRequestError: model not allowed: moonshot/deepseek-chat

Fix Action

Fixed

Fixed by PR: fix(ui): prevent double-qualifying already-qualified model values (https://github.com/openclaw/openclaw/pull/51381)

PR fix notes

PR #51381: fix(ui): prevent double-qualifying already-qualified model values

Repository: openclaw/openclaw
Author: Cypherm
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/51381

Description (problem / solution / changelog)

Summary

Problem: When switching models in the Control UI, resolveServerChatModelValue() blindly prepends the session's default provider to the model string — even when it's already provider-qualified (e.g. ollama/gpt-oss:120b-cloud). This produces invalid refs like anthropic/ollama/gpt-oss:120b-cloud, which the server rejects with model not allowed.

Why it matters: Users with multi-provider setups (Ollama + Anthropic, OpenRouter nested models) cannot switch models in the Control UI without hitting this error.

What changed:

Rewrote resolveServerChatModelValue() to use startsWith(provider + "/") guard instead of delegating to buildQualifiedChatModelValue
buildQualifiedChatModelValue() is unchanged — it remains a general-purpose builder
Added test cases for Together vendor-prefixed IDs, OpenRouter nested IDs, and already-qualified detection
Added chat-model-ref.test.ts to vitest include list

What did NOT change:

buildQualifiedChatModelValue() is untouched — this PR only changes the call site that resolves server-bound model values
normalizeChatModelOverrideValue(), formatChatModelDisplay(), buildChatModelOption() are untouched
No changes to server-side model resolution or validation

Change Type

Bug fix (non-breaking)

Scope

UI/DX (Control UI model picker)

Linked Issue

Closes #51139 Closes #51306 Closes #51809 Closes #52002 Closes #52061 Closes #52127 Closes #52173 Closes #52474

Security Impact

New permissions requested: none
Secrets handling changes: none
New network calls: none
New command/tool execution: none
Data access changes: none

Human Verification

I personally verified:

pnpm build passes
pnpm test -- ui/src/ui/chat-model-ref.test.ts — 8/8 tests pass (5 existing + 3 new)
New test: resolveServerChatModelValue("ollama/gpt-oss:120b-cloud", "anthropic") returns "ollama/gpt-oss:120b-cloud" (not "anthropic/ollama/gpt-oss:120b-cloud")
New test: resolveServerChatModelValue("openrouter/anthropic/claude-sonnet-4-6", "openrouter") preserves nested path

Evidence

Test Files  1 passed (1)
     Tests  8 passed (8)
  Duration  131ms

git diff --stat upstream/main...HEAD: 3 files changed, 18 insertions(+)

What I Did NOT Verify

Not verified: end-to-end in running Control UI with a real multi-provider gateway (tested via unit tests only)
Not verified: edge case where a model alias intentionally contains / but is not provider-qualified (no such case exists in the current codebase — createChatModelOverride already treats / as the qualified signal)

Failure Recovery

If this breaks in production:

Detection: Model picker shows wrong model or fails to match selected model
Rollback: Revert the single guard clause in resolveServerChatModelValue
Blast radius: Only affects model selection display/matching — no server-side impact

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 [email protected]

Changed files

ui/src/ui/chat-model-ref.test.ts (modified, +33/-0)
ui/src/ui/chat-model-ref.ts (modified, +16/-1)
vitest.config.ts (modified, +1/-0)

Code Example

Failed to set model: GatewayRequestError: model not allowed: moonshot/deepseek-chat

---

"deepseek/deepseek-chat": {},
"deepseek/deepseek-reasoner": {}

RAW_BUFFERClick to expand / collapse

问题描述

在 Control UI 界面选择 DeepSeek 模型时，系统错误地将模型 ID 设置为 moonshot/deepseek-chat，导致请求失败。

错误信息

Failed to set model: GatewayRequestError: model not allowed: moonshot/deepseek-chat

预期行为

选择 DeepSeek 模型时应该使用正确的 provider 前缀：deepseek/deepseek-chat

实际行为

Control UI 错误地添加了 moonshot/ 前缀，导致模型 ID 变成 moonshot/deepseek-chat，网关拒绝该请求。

环境信息

OpenClaw 版本: 2026.3.13
界面: Control UI
浏览器: Web 界面

配置文件

配置文件中模型定义是正确的：

"deepseek/deepseek-chat": {},
"deepseek/deepseek-reasoner": {}

临时解决方案

手动输入模型 ID deepseek/deepseek-chat 而不是从下拉菜单选择
通过命令行或 API 直接切换模型

extent analysis

Fix Plan

To resolve the issue, we need to update the Control UI to use the correct provider prefix deepseek/ instead of moonshot/ when selecting the DeepSeek model.

Code Changes

Update the model selector component in Control UI to use the correct prefix:

// Before
const modelId = 'moonshot/' + model.name;

// After
const modelId = 'deepseek/' + model.name;

Alternatively, you can also update the model selector to use a dictionary that maps model names to their correct IDs:

const modelIds = {
  'deepseek-chat': 'deepseek/deepseek-chat',
  'deepseek-reasoner': 'deepseek/deepseek-reasoner',
};

const modelId = modelIds[model.name];

Configuration Changes

No changes are required in the configuration file, as the model definitions are already correct.

Verification

To verify that the fix worked, follow these steps:

Open the Control UI and select the DeepSeek model from the dropdown menu.
Check that the model ID is correctly set to deepseek/deepseek-chat.
Verify that the request is successful and the model is loaded correctly.

Extra Tips

Make sure to test the fix thoroughly to ensure that it works for all models and scenarios.
Consider adding automated tests to prevent similar issues in the future.
If the issue persists, check the browser console for any error messages that may indicate a different root cause.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#api #request error #file not found #serialization error #model compatibility

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.