为什么我在dsh中使用第三方模型也会消耗官方deepseek-flash的token？

[AIWfei]

为什么我在dsh中使用第三方模型也会消耗官方deepseek-flash的token？

[milixiang]

是不是走websearch了 好像websearch默认会走ds的llm接口 通过llm内置的web搜索功能实现

[ABao1]

是因为用了subagent吧，这个有bug，subagent会调用官方的模型，不会继承
用第三方的模型

[zoahdev]

大概率不是主对话在消耗 flash，而是辅助请求仍然走默认模型。DSH 里会话标题这类辅助生成由 dsh-session-title-* 负责，它的配置（SessionTitleLlmConfig）里 provider / model 是可选的——不配就落到默认 LLM 策略，也就是你配置文件里的默认模型（很多模板默认 deepseek-flash）。所以你可能看到"明明主对话用第三方模型，用量里却有 flash 的 token"。

验证与修复：

1. 在 profile 配置里显式给标题/总结类请求配上第三方模型：

   # session-title 相关插件配置 provider + model 成对出现
   provider: your-third-party
   model: your-model

2. 如果开了 compaction 摘要，检查 @deepseek-ai/dsh-compaction-basic 的 summarizationProvider / summarizationModel，不配就继承对话目标模型，但标题请求是独立的。
3. 用 dsh web --dump-config 确认组合后的配置里这些 key 的实际值。

如果你确定没有标题/总结请求，把 --dump-config 输出贴出来，我可以帮你定位是哪条链路。

[Sutera-Diffusus]

楼上三位基本把路都堵上了:web_search 辅助请求、subagent 模型继承 bug、会话标题等辅助生成默认走官方 flash。先装个常驻用量统计行盯着——我们 dsh-statusbar 常驻 缓存/Token/花费/余额,每次跑完直接看数字,是哪个会话在烧 flash 一目了然:https://github.com/Sutera-Diffusus/dsh-statusbar

[ethan-cur]

这看起来很奇怪，一般不太会的，我去查查看 q

[XinyueZ]

把deep seek key变空呢？

[huliyoudiangou]

因为如果配置了官key，搜索默认会用官key little-boy ***@***.***> 于2026年8月21日周五 00:11写道：

…

这看起来很奇怪，一般不太会的，我去查查看 q <https://qcode.cc/?from=github> — Reply to this email directly, view it on GitHub <#2779?email_source=notifications&email_token=AR6HQEZOUORXOPNQNFXNOED5K4PMDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQHE2TQMBZUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-18095809>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR6HQE25JF7XKIOPPWQ4L635K4PMDAVCNFSNUABJKJSXA33TNF2G64TZHMYTGMZTGA3DKMBZGE5UI2LTMN2XG43JN5XDWMJQGYZTCMRQGKQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AR6HQE5LNAD7OPAJRAQICSL5K4PMDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQHE2TQMBZUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FKMZXW65DFOJPWS33T> and Android <https://github.com/notifications/mobile/android/AR6HQE67XVD3GRD4GRF2ERD5K4PMDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQHE2TQMBZUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FOMZXW65DFOJPWC3TEOJXWSZA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: <deepseek-ai/deepseek-harness/repo-discussions/2779/comments/18095809@ github.com>

[AIWfei]

我把websearch和subagent 模型、会话标题配置为第三方后问题解决了。

[XinyueZ]

~/.dsh/cordis.patch.yml

~/.dsh/profiles/headless/cordis.patch.yml

~/.dsh/profiles/web/cordis.patch.yml

- id: llm-deepseek
  disabled: true

- id: web-search-deepseek
  disabled: true

[weijiafu14]

楼上的解法（把 websearch/subagent/会话标题的模型也配到第三方）是对的；补一下为什么会这样和怎么核实，给后来搜到的人：

一次普通对话背后不止一个 LLM 消费者。除了主对话轮，至少还有：会话标题生成（每个新会话第一条消息后发一次小请求）、web_search、子代理——它们各有自己的模型选择，不自动跟随你聊天窗里选的模型。你只切了主对话的模型时，这些辅助请求仍走各自的默认（官方 flash），token 就是这么烧掉的。

这不是猜测：会话日志里能直接看到。开启 jsonl 会话持久化后，每个会话文件里有独立的 session/title-llm-request 记录，带着它自己的 route（provider/model）——我们的端到端装置里抓到的标题请求就带着独立的路由与独立的 max_tokens（装置，随手能复现）。想彻底核实自己的 token 去向，还可以把透传录制代理挡在官方端点前跑一轮——落盘的每条请求体自报用途。

顺带一个上游值得考虑的点：辅助消费者（标题/搜索/子代理）默认跟随主模型、或至少在消耗官方 token 时有一次性提示——现状对用户是隐形计费面。