web_search 在会话模型切到第三方 provider 后仍走 DEEPSEEK_API_KEY 独立计费——披露藏在参考页一行里，且从不说破计费后果

[f25h-233]

web_search 在会话模型切到第三方 provider 后仍走 DEEPSEEK_API_KEY 独立计费——披露藏在参考页一行里，且从不说破计费后果

deepseek-ai/deepseek-harness Discussion
所有代码引用基于当前 master（2026-08-31，0.1.2-alpha.1）。

一句话总结

web_search 由独立 provider（web-search-deepseek，id = deepseek-official）直接调用 DeepSeek 官方 Anthropic 兼容端点，刻意不走会话的 LLM provider（ctx.llm）。用户在 onboarding 存了 DEEPSEEK_API_KEY、后来又在 Models 页把会话模型切到第三方 provider 后，会话 token 走第三方账户，而每一次 web_search 仍用 deepseek-v4-flash 扣 DeepSeek 官方账户。社区文档仅在多模型路由参考页的表格里一行带过该机制（且只说机制、不说计费后果），快速上手文档与 Web UI 均不提及。

源码证据

事实	位置
"The wire format and native fetch client are provider-private and do not use ctx.llm"	packages/web/web-search-deepseek/src/provider.ts:5
provider id = deepseek-official	provider.ts:27
端点 https://api.deepseek.com/anthropic/v1（不是 chat-completions 的 api.deepseek.com；不复用 $DEEPSEEK_BASE_URL，只共享 key）	provider.ts:29-35
默认模型 deepseek-v4-flash	provider.ts:38
每次搜索 = 一次完整 Messages 模型轮次（max_tokens: 4096、原生 web_search_20250305 工具、max_uses: 5）	provider.ts:204-213；README："一次搜索会产生完整模型轮次的延迟与 token 开销"
key 解析：config 字面 apiKey → ctx.credentials 的 DEEPSEEK_API_KEY 引用 → 进程环境	provider.ts:278-300、index.ts:43
base 组合显式钉死搜索 provider：searchProvider: deepseek-official + apiKeyEnv: DEEPSEEK_API_KEY；注释明言 "Search is a full auxiliary model request with server-side retrieval"	packages/bundle/base/cordis.patch.yml:404-417
多模型路由 llm-pi-ai（Models 页写入的就是它）与 web seam 无任何关联	cordis.patch.yml:88-96
搜索 key 就是 Models 页存的那把："在 Web 的 Models 页中存储或轮换的密钥无需重启，即可用于下一次调用"	packages/web/web-search-deepseek/README.zh.md:15

复现与验证

1. 打开 Web UI，Models 页 onboarding 存下 DEEPSEEK_API_KEY（~/.dsh/.credentials.yaml）。
2. 在 Models 页添加第三方 provider profile（llm-pi-ai: 段）并把会话模型切过去。
3. 提问触发 web_search。
4. 会话 token 扣第三方账户；搜索扣 DeepSeek 官方账户（deepseek-v4-flash @ /anthropic/v1）。

无需抓包即可验证：每次搜索在发出前一刻都会往会话日志追加脱敏的 web/deepseek-search-llm-request 事件（provider.ts:117-122），携带已解析的端点和请求体：

zstdcat ~/.dsh/sessions/*/*/session.jsonl.zstd | grep deepseek-search-llm-request

设计意图（承认这是刻意的）

• 解耦让"只填一把 key 就能用搜索"的新手体验成立——searchProvider 未显式配置时单一可用 provider 自动选中（packages/web/web/src/index.ts:172-194），base 里也显式钉死了 deepseek-official。
• 包级文档确实写清了机制与 token 影响（web-search-deepseek README、docs/tool-catalog.md"提供方选择置于 ctx.web 之后"）。

问题：披露存在，但藏得深、且从不说破后果

• 快速上手文档（deepseekdocs.com/docs/getting-started/quickstart）——用户唯一会走的路径：只教配 DEEPSEEK_API_KEY、只说"想用别的 provider / 自建网关，配 llm-pi-ai.providers"，全文对 web_search 零提及。
• 多模型路由参考页（deepseekdocs.com/docs/features/multi-model）——唯一提到的地方：Provider 体系表一行"Web 搜索端点：独立 Anthropic 端点，复用主 key（web-search-deepseek）"，场景表一行"Web 搜索走独立端点：复用主 key、走 anthropic/v1（不复用主 baseURL）"。只描述机制，全文没有任何一句把计费后果说破——没有一处告诉用户"这意味着你切到第三方模型后，每次 web_search 仍会扣 DeepSeek 官方账户的钱"。
• Web UI：Models 页同时写入凭据与 llm-pi-ai profile，但按源码看没有任何界面元素披露搜索的计费归属（此点我未运行 Web UI 实测，如已有披露，本帖降级为"让它可被发现"，诉求不变）。
• 结果就是"配置时一把 key 一个心智账户，运行时两套账户"——近期已有用户对此感到疑惑，这不是个别人的误解：披露不是不存在，而是藏在参考页表格里、且从不把后果说成人话。

影响人群

• 只用 DeepSeek 模型的新手：单账户，无感，解耦反而帮了他们。
• 切到第三方模型的用户：一个心智账户、两个真实账户，静默两头烧。
• 彻底移除 DeepSeek key 的用户：web_search 以 WEB_PROVIDER_CREDENTIAL_MISSING 失败，且 available() 无法探测异步凭据存储（README 已知限制），UI 没有任何提示告诉他是哪个能力缺 key。

建议方向

• A. 全耦合：未显式配置 searchProvider 时，web_search 默认跟随会话当前 provider；searchProvider / $DSH_WEB_SEARCH_PROVIDER 保留为显式覆盖。
• B. 全解耦 + 披露：保留现有设计（用 flash 模型干搜索脏活是合理工程决策），但产品面补上归属声明——Models 页加一行"web_search 使用 DEEPSEEK_API_KEY · deepseek-v4-flash · api.deepseek.com/anthropic/v1"、快速上手文档补一段、首次触发搜索时提示一次。
• C. 中间态：默认跟随会话 provider，显式配置优先。

核心诉求一句话：要么全耦合，要么全解耦+披露；当前"配置时一个账户、运行时两个账户"的接缝，就是这次计费惊吓的来源。 现在是 Developer Preview，正是定默认值的最佳时机——别等 npm 通道变成正式产品再改。

验证边界

• 已核实：provider 解耦、key 解析链、base 组合钉死 deepseek-official、快速上手文档零提及、多模型路由参考页仅一行机制描述且无计费后果说明。
• 未核实：Web UI Models 页的实际渲染内容（未运行 Web 端）；建议维护者或发帖者打开 Models 页确认是否有搜索计费披露。

---

English TL;DR: web_search in DSH is executed by a standalone provider (web-search-deepseek, id deepseek-official) that calls DeepSeek's Anthropic-compatible endpoint (api.deepseek.com/anthropic/v1, model deepseek-v4-flash) directly and deliberately does not use the session's LLM provider (ctx.llm). If you store a DEEPSEEK_API_KEY during onboarding and later switch the conversation model to a third-party provider via the Models page, every web_search keeps billing your DeepSeek account while conversation tokens bill the third party — two accounts burning under one mental model. The billing consequence is not stated on any user-facing surface: the quickstart never mentions web_search, and the multi-model routing reference only notes the mechanism ("Web search uses a separate endpoint, reuses the main key") without ever spelling out the billing consequence. Suggested directions: (A) route web_search through the session's active provider by default, keeping searchProvider / $DSH_WEB_SEARCH_PROVIDER as an explicit override; or (B) keep the decoupling but disclose the attribution in the Models page, the quickstart, and/or a one-time notice on first search. This is Developer Preview — a good moment to settle the default before the npm channel ships.

[argszero]

这个报告质量很高，表格给的全是源码位置，我逐条对照当前 master（0a53fb55be，alpha.2）复核了一遍——核心机制全部属实，只有一处引用微调。

复核结果（对照 0a53fb5）

你的论断	alpha.2 现场证据	结论
独立 provider、不用 ctx.llm	packages/web/web-search-deepseek/src/provider.ts:5（"provider-private and do not use ctx.llm"）	✅
provider id = deepseek-official	provider.ts:27	✅
Anthropic 端点、不复用 $DEEPSEEK_BASE_URL、只共享 key	provider.ts:35（https://api.deepseek.com/anthropic/v1 + 注释明言 not the chat-completions base）	✅
默认模型 deepseek-v4-flash	provider.ts:38	✅
每次搜索 = 完整 Messages 轮次（max_tokens: 4096、原生 web_search_20250305 工具）	provider.ts:44（DEEPSEEK_DEFAULT_MAX_TOKENS = 4096）、:215（tools: web_search_20250305 + max_uses）	✅
key 解析：字面 apiKey → DEEPSEEK_API_KEY 引用 → 环境	provider.ts:287-306（options.apiKey 非空优先 → options.apiKeyEnv ?? 'DEEPSEEK_API_KEY' → 无 credentials 服务时进程环境）	✅
base 钉死 searchProvider: deepseek-official + apiKeyEnv: DEEPSEEK_API_KEY	packages/bundle/base/cordis.patch.yml:453 + :459	✅
搜索请求前写 web/deepseek-search-llm-request 日志事件	provider.ts:83（事件类型定义）+ 实现处	✅
tool-catalog 只一句"提供方选择置于 ctx.web 之后"	docs/tool-catalog.md:2279（"web_search and web_fetch keep provider selection behind ctx.web so model-visible schemas stay stable across backend swaps"）	✅
README 披露了机制与 token 成本	README.zh.md:12（"一次搜索在延迟与 token 上消耗一个完整模型轮次"）、:85（"一个凭据，逐次解析…但不复用 $DEEPSEEK_BASE_URL"）	✅

唯一微调：你引的 README.zh.md:15（"Models 页存储/轮换密钥无需重启"）在 alpha.2 里不是这句——第 15 行是目录。该机制本身成立（key 每次搜索经 ctx.credentials 逐次解析，provider.ts:287-306），但"Models 页存储"那句话应来自其它页面（如 Web UI onboarding 文案），不是这个 README。不影响结论。

这确实是"刻意设计 + 披露缺口"的组合，且披露缺口有真实成本

设计意图我认同——单 key onboarding 让新手"填一把 key 就能搜索"的体验成立，searchProvider 未显式配置时自动选中唯一可用 provider（packages/web/web/src/index.ts:172-194）。问题在用户视角：用户在 Models 页存 key 是为了会话模型计费，而 web_search 用同一把 key 走独立账户、独立模型、独立端点。切到第三方 provider 后会话账单去第三方、搜索账单留在 DeepSeek 官方——用户拿到的是两本账，其中一本没有任何可见提示。

这和此前报告的计费错配是同一族（#3552 子代理账单错配、#4077 配额烧光类）：辅助模型调用与主会话模型的解耦是平台的合理设计，但"谁在扣哪把 key"必须对用户透明。搜索每次扣一个完整模型轮次的 token（4096 max_tokens），如果用户日常重搜索，官方账户的配额消耗完全可能无感爆掉。

可操作建议

1. 验证：你给的命令有效——zstdcat ~/.dsh/sessions/*/*/session.jsonl.zstd | grep deepseek-search-llm-request，事件里带解析后的端点与请求体，无需抓包;
2. 隔离计费：web-search-deepseek 配置支持 apiKey 字面值（README 表："非空字面值优先"），可显式给搜索一把独立低配额 key，与主 key 物理隔离——既防配额串烧也防泄露面扩散;
3. 修复方向：这是纯披露问题，成本很低——① quickstart 在配置 key 的步骤旁加一行"web_search 使用 deepseek-v4-flash 独立按 DeepSeek 官方账户计费"; ② Web UI Models 页保存 key 时提示"该 key 同时供 web_search 使用"; ③ 参考页表格保留即可。没有运行时 bug，不必动 provider 语义。

报告值得官方正式回应——这不是"藏得深"的吹毛求疵，是会产生真实账单意外（且涉及 key 复用面）的用户成本问题。

[maxwell-feng]

用我的插件，去tinyfish注册，一天4万次联网搜索。

[maxwell-feng]

用我的插件，去tinyfish注册，一天4万次联网搜索。

[12869741]

是的，而且我deepseek账户没钱了，用的第三方api，也有websearch，但就提示Error: Insufficient Balance

[maxwell-feng]

用我的插件，去tinyfish注册，一天4万次联网搜索。