Proposal: integrate persistent token-usage tracking into DeepSeek Harness

[LeemanCheung]

Proposal

I built dsh-token-usage, an MIT-licensed DeepSeek Harness plugin that provides persistent, privacy-preserving token-usage analytics. I would like to propose integrating this capability into the official project—either as an officially maintained optional plugin or as a built-in feature.

What it provides

• Records the complete usage buckets: uncached input, output, cache read, and cache write tokens. reasoningTokens is already part of output usage and is not double-counted.
• Aggregates usage by provider/model, session, and UTC day across normal requests, retries, and context compaction.
• Avoids duplicate accounting when streaming usage is followed by final-message usage.
• Backfills readable historical sessions asynchronously without delaying startup.
• Adds a compact Settings → Token usage dashboard with summary cards, per-model totals, searchable session records, and a 30-week activity heatmap.
• Stores only aggregate usage buckets, dates, and model routes—never prompts, responses, or session contents.

Why upstream integration could help

Token usage is fundamental observability for both personal and team DSH deployments. A first-party implementation would make the data model stable across providers, eliminate the need for each user to install and maintain a separate plugin, and give users visibility into cache effectiveness and consumption trends without compromising session privacy.

The plugin is already packaged as a standard DSH host projection plus Web settings UI and can be installed today with:

dsh plugin --profile web add github:LeemanCheung/dsh-token-usage

Suggested path

1. Review it as an official optional plugin first, so the feature can evolve independently.
2. If appropriate, move the usage projection/event contracts into official packages and retain the dashboard as a maintained UI surface.
3. Define the desired data-retention, migration, and aggregation APIs together to ensure compatibility with future providers and clients.

I am happy to contribute the implementation, adapt it to the project conventions, split it into reviewable PRs, or transfer ownership if that makes integration easier. Feedback on the preferred scope and architecture would be very welcome.

Source: https://github.com/LeemanCheung/dsh-token-usage

[Sutera-Diffusus]

官方内置是条好路,进程外是另一条:一个独立于 dsh 的本地桌面监测器,不依赖插件 API(不随 rc 版本漂移),还能把 dsh、claude、codex 等工具的用量统一到一个视图。我们 metera 走的就是这条路(本地优先、跨工具):https://github.com/Sutera-Diffusus/metera