[Bug] dsh-base 4处硬编码付费API默认值，models:[] 仅隐藏UI不禁路由，用户无感产生DeepSeek账单

[flyfox326]

Summary

@deepseek-ai/dsh-base 的 cordis.patch.yml 中有 4 处硬编码将所有用户默认指向付费 DeepSeek API。即使用户通过 Models 页面隐藏 DeepSeek 模型（llm-deepseek: models: []），底层路由适配器仍然存活，web_search 等工具的调用会无感走付费端点。另有 1 处遥测端点默认未硬禁用。

Severity: High — 导致用户产生非预期付费调用，且用户无法通过现有 UI 完整规避。

Affected Version: @deepseek-ai/dsh v0.1.0-rc.7 + @deepseek-ai/dsh-base

---

Root Cause

dsh-base/cordis.patch.yml 作为所有 profile（web/tui/headless）的共享基础层，其默认配置硬编码了付费端点。Cordis patch 层的 models: [] 仅控制 UI picker 展示，不等于禁用路由适配器。这是两套独立机制：

机制	作用范围	效果
llm-deepseek: models: [] (settings.yaml)	UI Models 页面	隐藏模型选项，用户看不到
llm-deepseek: disabled: true (cordis patch)	Cordis Loader	适配器不加载，路由不注册

用户通过 UI 隐藏模型后以为已切换，但适配器仍在后台解析 DEEPSEEK_API_KEY 并注册路由，其他组件引用 deepseek-official 时仍可达。

---

Detailed Findings

F1: agent-default-model 默认走付费 (dsh-base/cordis.patch.yml Line 63-67)

- id: agent-default-model
  name: '@deepseek-ai/dsh-agent-default-model'
  config:
    provider: deepseek-official     # ← 付费
    model: deepseek-v4-flash        # ← 付费模型
影响：新建 Agent 未显式指定模型时，自动使用付费端点。
F2: web.searchProvider 默认走付费 (Line 404-407)
- id: web
  name: '@deepseek-ai/dsh-web'
  config:
    searchProvider: deepseek-official  # ← 付费
影响：所有 web_search 工具调用直接走 api.deepseek.com/anthropic/v1/messages，消耗 DEEPSEEK_API_KEY 额度。子 agent（如 subagent spawn）被授予 web_search 时同样受影响。
F3: web-search-deepseek 始终加载 (Line 409-412)
- id: web-search-deepseek
  name: '@deepseek-ai/dsh-web-search-deepseek'
  config:
    apiKeyEnv: DEEPSEEK_API_KEY  # ← 自动解析用户 key
影响：搜索插件始终注册为 provider，配合 F2 形成"搜索→找 deepseek-official provider→用 DEEPSEEK_API_KEY→付费调用"的完整链路。用户在 settings 中设 models: [] 对此无影响。
F4: llm-deepseek 适配器始终加载 (Line 450-451)
- id: llm-deepseek
  name: '@deepseek-ai/dsh-llm-deepseek'
影响：无 disabled: true，适配器始终加载并注册路由。models: [] 仅让 Models 页不展示选项，但路由可达。当 agent-default-model 或 searchProvider 引用 deepseek-official 时，请求直接走此路由。
F5: session-telemetry-otel 遥测端点未硬禁用 (Line 148-154)
- id: session-telemetry-otel
  config:
    mode: !!js process.env.DSH_TELEMETRY_MODE || 'DISABLED'
    exporter:
      url: !!js process.env.DSH_TELEMETRY_OTLP_URL ?? 'https://harness-telemetry.deepseeksvc.com/v1/logs'
影响：默认 DISABLED，但无 disabled: true。若 DSH_TELEMETRY_MODE 环境变量被意外设置为非 DISABLED 值，会向 harness-telemetry.deepseeksvc.com 发送包含完整 session log 的遥测数据。
Impact Analysis
所有安装 DSH 并在 ~/.dsh/.credentials.yaml 中存储了 DEEPSEEK_API_KEY 的用户，只要满足以下任一条件即产生付费调用：
1. 创建 Agent 未显式指定模型（触发 F1 → F4 链路）
2. 使用 web_search 工具（触发 F2 → F3 链路）
3. 子 agent 使用 web_search（同上）
账单不对齐的原因：账单是历史累计不区分会话；models: [] 让用户误以为已完全禁用，实际仅隐藏 UI。
Proposed Fix
方案 A：dsh-base 层修复（推荐，根本解决）
将 dsh-base 的默认值改为不默认依赖付费端点：
# dsh-base/cordis.patch.yml proposed changes

- id: agent-default-model
  name: '@deepseek-ai/dsh-agent-default-model'
  config:
    provider: llm-deepseek
    model: deepseek-v4-flash
  # 当 DEEPSEEK_API_KEY 不存在时应优雅降级，而非静默走付费

- id: web
  name: '@deepseek-ai/dsh-web'
  config:
    searchProvider: ''  # 要求用户显式配置，而非默认付费
更彻底的方案：llm-deepseek 和 web-search-deepseek 在 DEEPSEEK_API_KEY 未配置时应自动 disabled，而非始终加载等待 key 解析。
方案 B：文档 + UI 提示（最小改动）
在 Models 页面添加明确提示：
"隐藏模型 ≠ 禁用路由。要彻底禁用 DeepSeek API 调用，请在 profile 的 cordis.patch.yml 中设置 llm-deepseek: disabled: true。"
方案 C：models: [] 语义增强
让 llm-deepseek: models: [] 在 settings 层也等效于 disabled: true，即空模型列表时自动禁用适配器加载。这是最符合用户直觉的方案，但需要修改 dsh-llm-deepseek 插件逻辑。
Workaround (Current User Fix)
用户可在 ~/.dsh/cordis.patch.yml 中添加以下覆盖（已验证有效）：
- id: agent-default-model
  config:
    provider: nvidiaz
    model: nvidia/nemotron-3-ultra-550b-a55b

- id: llm-deepseek
  disabled: true

- id: web-search-deepseek
  disabled: true

- id: web
  config:
    searchProvider: pi-ai/opencodezen

- id: session-telemetry-otel
  disabled: true
Verification Steps
1. Settings → Models：deepseek-official 应消失或显示 "No models advertised"
2. 调用 web_search：不应产生 api.deepseek.com 流量（可抓包验证）
3. 新建 Agent：默认模型应为覆盖后的免费模型
4. DeepSeek 账单：次日应为 0
Environment
- OS: Windows 11
- DSH: v0.1.0-rc.7
- Node: v22.x
- Profile: web (primary), tui, headless

[denial123789]

I checked this against the rc.7 source. The important distinction is correct: models is an advisory discovery catalog, and resolveModel() still accepts an uncatalogued model ID. The DeepSeek chat adapter and DeepSeek Web-search provider are also independent routes. One nuance: a loaded route alone does not prove billing; selection, successful credential resolution, and network dispatch must all occur. Telemetry is a separate path.\n\nI turned the source trace into an English operator runbook with an emergency provider-side key stop, a home-level patch that first selects an approved replacement and then disables llm-deepseek, web-search-deepseek, and tool-web, plus --dump-config and observed-egress verification gates:\n\nhttps://sandbaseai.github.io/deepseek-harness-handbook/deepseek-api-cost-boundary.html\n\nThe provider-side revoke/cap remains the authoritative cost boundary; a quiet Models picker or local patch alone should not be reported as proof of zero spend.

[flyfox326]

账单时间对应分析

账单时段 (北京时间) | 对应 UTC | 可能触发原因 -- | -- | -- 11:00-12:00 ¥0.24 | 03:00-04:00 | 早间任务触发 web 搜索 15:00-16:00 ¥0.52 + ¥2.00 | 07:00-08:00 | 白天交互中使用了 web 搜索 16:00-17:00 ¥0.96 | 08:00-09:00 | 同上 17:00-18:00 ¥0.03 | 09:00-10:00 | 收尾时的搜索

[argszero]

按 rc.8（141eb6fef8）源码核对了报告与方案，有一个关键事实修正会让方案 A 失效，需要提醒：

方案 A 的 provider 改法（deepseek-official → llm-deepseek）无效——两者是同一件事。
packages/llm/llm-deepseek/src/index.ts:49：const PROVIDER = 'deepseek-official'——@deepseek-ai/dsh-llm-deepseek 插件注册的 provider id 就是 deepseek-official（直接 fetch + eventsource-parser SSE 的 DeepSeek 官方适配器，llm/README.md:88）。也就是说：

• agent-default-model 的 provider: deepseek-official 指向的正是 llm-deepseek 插件
• 方案 A 改成 provider: llm-deepseek 要么是无效 provider id（适配器注册的是 deepseek-official，不是 llm-deepseek），要么仍走同一个付费 DeepSeek API
• 改这个值不会改变计费事实——它只是同一个付费端点的别名

真正有效的修复方向（与你的 workaround 一致）：把默认 provider/model 换成用户自己的免费端点（如你 workaround 里的 nvidiaz），或禁用 llm-deepseek 插件让 deepseek-official 路由不可达。这两件事你的 workaround 已经正确覆盖（llm-deepseek: disabled: true + agent-default-model 改免费 provider + web-search-deepseek: disabled: true）。

对方案 C 的语义提醒：models: [] 自动禁用适配器（llm-deepseek: models: [] → 等效 disabled: true）与现有设计冲突——models 是 discovery 目录（advisory catalog），不是 enable 开关。denial123789 已经核验：resolveModel() 仍接受未收录的 model id（目录外直呼合法）。把"空目录"耦合到"禁用适配器"会破坏这个语义：用户想自定义模型列表但保留 provider 路由（如临时直呼某个未收录模型）时会被意外禁用；且跨插件（llm-deepseek + web-search-deepseek 等）都要改，语义不一致风险高。

我的分层建议：

1. 默认值（F1/F2）是产品定位选择（DeepSeek 是默认），不是 bug——但值得文档明示"默认走 DeepSeek 付费 API，改免费端点见 …"；
2. UI 认知鸿沟（"隐藏模型 = 已禁用"的误以为）是真正的 UX 问题——Models 页加一行提示（你的方案 B）成本最低且直击痛点；
3. 优雅降级（DEEPSEEK_API_KEY 未配置时默认不静默走付费）是合理的默认行为改进——未配置 key 时 agent-default-model 不应指向不可达路由（或应大声报错）；
4. 成本边界权威仍在 provider 侧（key 吊销/限额），denial123789 的 runbook 已覆盖。

补充一点：你的 Impact Analysis 里"创建 Agent 未显式指定模型 → 触发 F1 → F4 链路"的表述准确，但触发前提是 DEEPSEEK_API_KEY 已在凭据库——无 key 时路由不可达、无计费。这个前提让问题从"无感付费"精确化为"有 key 的用户在默认配置下的预期行为 + 误以为已禁用的 UI 鸿沟"，后者才是值得修的。

[weijiafu14]

@argszero 那条修正（llm-deepseek 注册的 provider id 就是 deepseek-official，所以方案 A 改 provider 名等于没改）是这帖里最关键的一句，@denial123789 那句"provider-side revoke/cap 才是权威的成本边界、本地 patch 不能当作零支出的证明"也完全对。我不重复这两块，补两件他们没覆盖的。

一、验证那一步：把"我希望都关掉了"变成"漏掉的会自己喊出来"

你的 Verification Steps 第 2 条是"可抓包验证"。抓包能证明"我观察的这段时间里没有流量"，但证明不了"没有我没想到的路径"——F1 到 F4 这四条链路正是你逐条读源码才发现的，谁也不敢说没有第五条。

有个更省事也更严格的做法：在 hosts 里把端点指回本地。

127.0.0.1 api.deepseek.com

它把失败模式整个翻了过来：

	现在（只做 patch）	加上 hosts 之后
你漏掉了一条路径	静默计费，次日看账单才知道	当场报连接错误，带着完整调用栈告诉你是谁发的
你全关对了	什么也不发生（无法与"漏了但没触发"区分）	什么也不发生（这次是真的）

也就是说：它不是用来阻断的，是用来把"沉默"变成"报错"的。 你只要照常用几天——新建 Agent、跑 web_search、派子代理——任何还没被你堵住的路径都会自己跳出来指认自己，而不是等到账单。确认干净之后删掉那行即可，完全可逆，也不影响你 key 的正常用途（这一点比 provider 侧吊销 key 温和得多，两者可以配合：先用 hosts 找漏网之鱼，找干净了再决定要不要动 key）。

这条和 @denial123789 的观点不冲突——权威成本边界仍然在 provider 侧，hosts 只是一个本地的、可逆的发现工具。

二、searchProvider 那一条其实有一整个社区生态，不必留空

你的 workaround 把 searchProvider 指到了一个免费网关，方案 A 建议改成 searchProvider: ''（要求用户显式配置）。这里可以更进一步：ctx.web.search 是一个公开的能力 seam，npm 上已经有一批第三方 provider 实现，装一个就能让 web_search 彻底不经过 DeepSeek 端点。我搜了一下当前在架的：

包	特点
dsh-web-search-searxng	SearXNG 后端，自建实例，无需任何 API key
dsh-web-search-thirdparty	把 ctx.web.search 路由到多个第三方引擎的门面
@yugasun/dsh-web-search	多 provider（百度/豆包/Tavily/Exa 等）
@deepseek-ai/dsh-web-search-exa、@monotykamary/dsh-web-search-exa	Exa 后端

对你的场景，dsh-web-search-searxng 大概是最贴的——自建 SearXNG 之后连第二张账单都不会有。

这对提案本身也有意义：F2 提"默认值指向付费端点"时，"有免费且无 key 的替代实现存在"是个有分量的论据——它说明默认值不是"没有别的选择只能这样"，而是一个可以重新考虑的产品决策。

披露：上面四个都是社区包，不是我的。我自己维护的兼容层里也有 web 搜索能力，但它注册的是一个 web_search 工具，不是 ctx.web.search 的 provider——接不进你这个 searchProvider 位，所以对你这条没用，这里不推销。而且那条能力我们只做到"能挂载 + 探针能调起来"，没做过真实端到端，按我们自己的规矩也不该拿出来推。

三、关于方案 C，我倾向 @argszero 那边

models: [] 自动等于 disabled: true 这个耦合我也觉得危险，理由和他一样：models 是 discovery 目录不是开关，而且 resolveModel() 接受目录外的 id 是已被核验的现有行为，有人正靠它直呼未收录模型。

但我觉得你方案 B 提的那句 UI 提示被低估了。这帖真正的伤害不是"关不掉"（你的 workaround 证明关得掉），是**"用户以为关掉了"**——models: [] 之后 Models 页面变干净，界面给出的信号和实际状态相反。一个会误导的正确实现，用户成本高于一个诚实的缺失功能。 所以哪怕 A 和 C 都不做，B 也值得单独做。

边界与利益相关

我们不修 DSH 自家组件——dsh-base、llm-deepseek、Models 页面都在 DSH 里。上面的 hosts 手法是通用运维技巧，不需要经过任何插件。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销，理由见上面第二节——我们那条 web 能力接的不是你需要的那个 seam，而且核证等级不够。