dsh-token-dashboard

LIMITATIONS

已知限制

- **只向前记录。** 见上面的口径选择。 - **日界是固定偏移，不是你的系统时区。** 默认 UTC+8 且可配置，但它不会跟着笔记本 跨时区走。这是刻意的：会移动的日界会悄悄拆开或合并已经记下的日子。 - **没有成本、预算、告警。** 只有 token。 - **用量就是 provider 上报的那个数。** 不上报用量的 provider 只会产生零 token 的请求； 看板把它们记为请求，不会编造数字。 - **被重试取代的那次尝试各算一次请求，且不计为错误。** `llm/stream` 每发起一次 provider 尝试就进入一次，而 DSH 会把失败的尝试在同一个 step 内重试成一次全新尝试。 因此一次结束时未上报用量的尝试，会贡献 1 个 `requests`、0 个 token，并在「最近调用」 里显示为一条零 token 且标为 `ok` 的行。对照会话日志实测，它的指纹非常明确： `ttftMs === durationMs`（唯一的 chunk 在流结束时才到达，于是首字样本等于总耗时）、 `usageReported: false`、跨度内同一会话存在一个 `llm/retry` 事件，且为传输层失败。 结果是：`requests` 统计的是**尝试次数**，会跟随但略高于计费调用数；`errors` 也不 反映重试。token 总量不受影响 —— 被取代的尝试不上报用量，所以不贡献任何 token。 实测的一天里，插件总量与日志推导值相差在 0.06% 以内，295 次调用中 294 次逐字段一致。 - **开发和测试都是在 Desktop profile 上做的。** 只要组合里提供了 `llm` 和一个 `connection` 载体，理论上都能跑，但只有 Desktop 组合被实际验证过。