fix(client): 会话总计改为 Σ 各轮成本（模型名回退最后一轮历史）

[rezon-aki]

这个改动带来什么

• 把成本计算的颗粒度提高到每一轮对话：每轮按自己发生的时段（高峰/空闲）和模型计价，会话总计 = 各轮徽章之和。
• 跨高峰与空闲的会话不再虚高：以前在高峰时段打开面板，整个会话都会被按高峰价算一遍（最多差一倍）；现在什么时候打开，数字都一样。
• 没有历史数据时（新会话、读取失败）仍按原来的估算显示，不会出现空白或 0。

现象

指示器行 / 面板头部的会话总计与每条消息尾部「本轮 ≈ ¥0.0x」徽章之和对不上 —— 高峰时段最多差一倍；同一会话在高峰时段打开会比空闲时段看到更大的总计。

根因

总计走的是「会话累计 token × 刊例价」，而计费时段只取单一时刻：指示器用 Date.now()，面板用最后一轮的开始时刻。逐轮徽章则不同 —— 宿主按轮折叠，每轮用自己的开始时刻计价。因此跨高峰/空闲的会话会把一个时段应用到全部 token 上。另外在 dsh >= 0.1.2 上快照节点不再带 provenance / requestConfig，模型名取不到，价格解析静默落到回退档。

修法

• 新增 sumRoundCosts()（src/client/rounds/types.ts）：把每轮各自的成本（双币种）相加。指示器行与面板共用它，总计因此与逐轮徽章天然一致；跨时段的会话按每轮开始时刻分别计价。
• 旧估算在「仍是唯一选择」的场景原样保留：历史不可用、还没有任何轮次、或任一轮没有成本 —— 这些情况下 sumRoundCosts() 返回 null，走原来的「会话总量 × 刊例价」路径。
• 快照取不到模型时回退取历史最后一轮的模型（面板原本就优先用宿主折叠的归因，指示器行现在与它一致）。

3 个文件，+51/−7，无新增依赖。

验证

• npm run typecheck：0 错误。
• npm test：41/41 通过（node 22，dsh 0.1.5-rc.2）。
• 本机实测（dsh 0.1.5-rc.2）：指示器行总计 = 各轮徽章之和；跨高峰边界的会话不再因为「什么时候打开」而变数字。

说明：本 PR 与 #12 互不依赖（改的是同一文件 UsageIndicator.tsx 的相邻两行），两者中后合并的一个需要一次很小的 rebase。

[Max-Samson]

非常感谢你的敏锐洞察和贡献！

会话总成本如果按单一时刻（特别是高峰时段）乘以全量累计 tokens，确实会导致跨峰谷时段的历史会话总计虚高翻倍，与逐轮徽章的金额产生不一致。你能精准定位到这个痛点并提出 $\Sigma$ 各轮成本累加的思路非常棒！

在仔细阅读代码时，我们注意到一个活动会话中的实时流式场景可能需要进一步斟酌：
由于输入框底栏的指示器（UsageIndicator）是常驻挂载且不随轮次卸载的，useHistoryRounds 仅在组件初次挂载时发起一次 HTTP 异步请求。如果在已有历史轮次的会话中继续对话，AI 正在流式生成新回复（或者新一轮刚刚产生但页面未刷新时），totals（来自实时投影 tokenUsage）在不断递增，但 history.rounds 尚未刷新。此时若无条件以 historyCost 优先，底栏展示的成本数字可能会在整个活跃生成期间处于“停滞/冻结”状态，无法实时反映新轮次消耗的 token 费用。

这个痛点本身非常关键，我们可以一起探讨下如何把“历史已封存轮次求和”与“当前未封存/流式增量”做更丝滑的衔接（例如在有新 token 增量时补偿实时估算，或者在轮次推进时触发历史数据的防抖对齐刷新）。

再次由衷感谢你为项目提交的这些高质量贡献！

[Max-Samson]

非常感谢你的敏锐洞察和贡献！

会话总成本如果按单一时刻（特别是高峰时段）乘以全量累计 tokens，确实会导致跨峰谷时段的历史会话总计虚高翻倍，与逐轮徽章的金额产生不一致。你能精准定位到这个痛点并提出 Σ 各轮成本累加的思路非常棒！

在仔细阅读代码时，我们注意到一个活动会话中的实时流式场景可能需要进一步斟酌： 由于输入框底栏的指示器（UsageIndicator）是常驻挂载且不随轮次卸载的，useHistoryRounds 仅在组件初次挂载时发起一次 HTTP 异步请求。如果在已有历史轮次的会话中继续对话，AI 正在流式生成新回复（或者新一轮刚刚产生但页面未刷新时），totals（来自实时投影 tokenUsage）在不断递增，但 history.rounds 尚未刷新。此时若无条件以 historyCost 优先，底栏展示的成本数字可能会在整个活跃生成期间处于“停滞/冻结”状态，无法实时反映新轮次消耗的 token 费用。

这个痛点本身非常关键，我们可以一起探讨下如何把“历史已封存轮次求和”与“当前未封存/流式增量”做更丝滑的衔接（例如在有新 token 增量时补偿实时估算，或者在轮次推进时触发历史数据的防抖对齐刷新）。

再次由衷感谢你为项目提交的这些高质量贡献！

我检查了当前 main：PR #12、#14、#15 的合并提交都已进入分支，但 #15 修改 UsageIndicator.tsx 时覆盖了 #12 的一处改动。

• fix(client): read conversation nodes from the chat slot source (dsh >= 0.1.2) #12（chat 节点源）：成本徽章仍使用新的 chat 源；用量指示器却退回从旧 session 快照取节点，导致 DSH 0.1.2+ 上可能读不到节点。同时 ChatNodesHook 类型导入丢失，合并后的代码无法通过类型检查。
• fix(client): 面板锚点按最近包含块换算（修复皮肤下偏到屏幕右侧） #14（面板定位）：定位改动仍保留在当前代码中，未发现被后续合并覆盖。
• fix(client): 会话总计改为 Σ 各轮成本（模型名回退最后一轮历史） #15（逐轮成本汇总）：求和逻辑仍保留；上述节点读取回退发生在它修改的同一个文件中。
  我已恢复指示器的 useSessionNodes(useChat, useSession) 调用并补齐类型导入，保留 fix(client): 面板锚点按最近包含块换算（修复皮肤下偏到屏幕右侧） #14、fix(client): 会话总计改为 Σ 各轮成本（模型名回退最后一轮历史） #15 的改动。新增了节点源选择和多轮成本汇总的回归测试。npm run verify 已通过，44 项测试全部通过。