问题描述
在一次使用 DSH 并行执行搜索密集型研究任务时，我发现 dsh-usage 显示的
deepseek-official 用量与 DeepSeek 官方账单存在较大差异：
- dsh-usage 当日统计费用：约 ¥1.37
- DeepSeek 官方当日实际费用：约 ¥21.05
最初怀疑是并行子 Agent 的 usage 未被统计，但进一步核对 DSH 原生 session
日志和 DeepSeek 官方用量 CSV 后发现，插件对普通 Agent 模型调用的统计本身是准确的，
差异主要来自 DeepSeek Search 后端产生的 LLM 调用。
取证结果
本次任务中：
普通 Agent 调用
DSH 原生 session 中记录：
- provider:
deepseek-official
- 请求数：22
- inputTokens: 163,438
- cacheReadTokens: 3,211,648
- outputTokens: 62,347
- reasoningTokens: 7,571
dsh-usage 对这 22 条调用的 token 和费用统计均与原生日志一致，
费用约为 ¥1.37。
因此普通 Agent 调用部分没有发现漏统计。
DeepSeek Search 后端调用
同一批 session 中还存在：
web/deepseek-search-llm-request: 1660 条- endpoint:
https://api.deepseek.com/anthropic/v1/messages
- model:
deepseek-v4-flash
这些调用由 web_search 产生。
DSH 原生 session 中可以看到这些 request 事件，但没有看到对应的 token usage
被持久化，因此 dsh-usage 当前也没有统计这些调用产生的 token / cost。
与官方账单交叉核对
DeepSeek 官方当日 CSV 中，对应 DSH 专用 API Key 的数据为：
- request_count: 1682
- cache_miss: 8,037,500
- cache_hit: 6,137,472
- output: 1,496,738
- 实际费用：约 ¥21.05
而原生日志中的调用数量：
1660 次 Search 后端调用
与 DeepSeek 官方 request_count 精确一致。
按账单差额看，22 条普通 Agent 调用约 ¥1.37，而 Search 后端调用产生的费用约为
¥19.7。
因此在这种搜索密集型 workload 中，dsh-usage 显示的费用会明显低于用户实际
产生的 DeepSeek API 账单。
可能的改进方向
不确定目前 DSH 插件 API 和 session persistence 能提供哪些能力，因此这里只作为
功能建议提出几种可能方向，不对具体实现方式做假设：
-
如果 DSH 上游可以持久化 Search backend 的 usage
如果 web/deepseek-search-llm-request 对应的响应能够将 token usage 一并写入
session，dsh-usage 或许可以直接将这部分 usage 纳入现有统计。
-
如果插件运行时可以观察 Search backend 的 response / usage
如果当前插件 API 提供相关 hook，也许可以在运行时获取这些调用的实际 usage，
从而补充 Search backend 的 token / cost。
-
如果目前无法获得实际 usage
也许可以考虑：
- 根据可获得的数据提供 estimated usage / cost（并明确标记为估算）；或者
- 在 UI / 导出结果中注明当前统计口径不包含 Search backend 的模型调用，
避免用户将插件显示费用理解为完整的 provider API 消费。
具体采用哪种方式可能取决于 DSH 当前提供的能力，作者按项目架构判断即可。
为什么我觉得这个问题值得提示
对于普通对话 / coding workload，这部分差异可能并不明显。
但在大量使用 web_search、并行 Research Agent 等场景下，Search backend 的实际
API 消耗可能远高于普通 Agent 对话本身。
例如本次实际案例：
- 插件可见费用：约 ¥1.37
- Provider 实际费用：约 ¥21.05
两者相差约 15 倍。
如果用户主要通过 dsh-usage 判断当前 API 消费，可能无法意识到 Search backend
仍在产生额外的真实计费。
因此想建议看看，是否有可能将这部分 usage 纳入统计；如果受限于 DSH 上游能力暂时
无法统计，至少可以考虑在统计口径中对此做一个提示。
感谢开发和维护这个插件 🙏
问题描述
在一次使用 DSH 并行执行搜索密集型研究任务时，我发现 dsh-usage 显示的
deepseek-official用量与 DeepSeek 官方账单存在较大差异：最初怀疑是并行子 Agent 的 usage 未被统计，但进一步核对 DSH 原生 session
日志和 DeepSeek 官方用量 CSV 后发现，插件对普通 Agent 模型调用的统计本身是准确的，
差异主要来自 DeepSeek Search 后端产生的 LLM 调用。
取证结果
本次任务中：
普通 Agent 调用
DSH 原生 session 中记录：
deepseek-officialdsh-usage 对这 22 条调用的 token 和费用统计均与原生日志一致，
费用约为 ¥1.37。
因此普通 Agent 调用部分没有发现漏统计。
DeepSeek Search 后端调用
同一批 session 中还存在：
web/deepseek-search-llm-request: 1660 条https://api.deepseek.com/anthropic/v1/messagesdeepseek-v4-flash这些调用由
web_search产生。DSH 原生 session 中可以看到这些 request 事件，但没有看到对应的 token usage
被持久化，因此 dsh-usage 当前也没有统计这些调用产生的 token / cost。
与官方账单交叉核对
DeepSeek 官方当日 CSV 中，对应 DSH 专用 API Key 的数据为：
而原生日志中的调用数量：
1660 次 Search 后端调用
= 1682 次
与 DeepSeek 官方
request_count精确一致。按账单差额看，22 条普通 Agent 调用约 ¥1.37，而 Search 后端调用产生的费用约为
¥19.7。
因此在这种搜索密集型 workload 中，dsh-usage 显示的费用会明显低于用户实际
产生的 DeepSeek API 账单。
可能的改进方向
不确定目前 DSH 插件 API 和 session persistence 能提供哪些能力，因此这里只作为
功能建议提出几种可能方向，不对具体实现方式做假设：
如果 DSH 上游可以持久化 Search backend 的 usage
如果
web/deepseek-search-llm-request对应的响应能够将 token usage 一并写入session，dsh-usage 或许可以直接将这部分 usage 纳入现有统计。
如果插件运行时可以观察 Search backend 的 response / usage
如果当前插件 API 提供相关 hook，也许可以在运行时获取这些调用的实际 usage，
从而补充 Search backend 的 token / cost。
如果目前无法获得实际 usage
也许可以考虑：
避免用户将插件显示费用理解为完整的 provider API 消费。
具体采用哪种方式可能取决于 DSH 当前提供的能力，作者按项目架构判断即可。
为什么我觉得这个问题值得提示
对于普通对话 / coding workload，这部分差异可能并不明显。
但在大量使用
web_search、并行 Research Agent 等场景下，Search backend 的实际API 消耗可能远高于普通 Agent 对话本身。
例如本次实际案例：
两者相差约 15 倍。
如果用户主要通过 dsh-usage 判断当前 API 消费，可能无法意识到 Search backend
仍在产生额外的真实计费。
因此想建议看看，是否有可能将这部分 usage 纳入统计；如果受限于 DSH 上游能力暂时
无法统计，至少可以考虑在统计口径中对此做一个提示。
感谢开发和维护这个插件 🙏