dsh-token-workbench

Token usage workbench for DeepSeek Harness (dsh). It reads the model-usage records already present in the session log, keeps a per-day detail store, turns them into tokens / cost / call numbers, and shows them in two places inside the app:

• Composer dock readout — today's tokens and reference cost right above the composer, at a glance.
• Settings page → 「Token 工作台」 — overview card, per-provider table, 7-day / 30-day trend charts and a rolling six-month heatmap, with paging for the granularity you picked and for the heatmap window.

Cost is a reference figure: tokens are multiplied by the official DeepSeek price list (peak / off-peak tiers, Beijing time 00:30–08:30 is off-peak). The price list is fetched from the DeepSeek pricing page and cached; when it cannot be fetched, a frozen default list is used and the UI says so.

Install

# from the published package
dsh plugin --profile web add dsh-token-workbench

# or straight from the release tarball
dsh plugin --profile web add https://github.com/dragonestdwolf/dsh-token-workbench/releases/download/v0.1.0/dsh-token-workbench-0.1.0.tgz

dsh plugin is the supported path: it records the package in the profile and applies the dsh.bundle.patch entry (cordis.patch.yml) that inserts the plugin into that profile's layer stack. A bare npm install does not mount anything. It needs a dsh ^0.2.1-rc.0 host with the web (client) platform enabled, then a restart of the app.

Privacy

• Everything is computed locally from the session logs dsh already writes to your DSH home; the plugin does not upload usage data anywhere.
• The only outbound request is the pricing page fetch (DeepSeek official pricing), and only to read numbers; if it fails the frozen default applies.
• No credentials, cookies or API keys are read or stored.

Development

The repository ships a set of local checks. None of them are part of the published package.

npm run check      # syntax-check the three entry points
npm run fixtures   # regenerate the synthetic session-log fixtures
npm run smoke      # Host-half assertions against the synthetic fixtures
npm run probe      # browser harness: client bundle + settings jump
npm run pack:dry   # npm pack --dry-run (what would be published)

scripts/make-fixtures.mjs writes fixtures/:

The fixtures are synthetic. They are generated session logs with invented provider and model names, invented token usage and invented prompt/tool text (synthetic fixture ...). They exist only so the smoke suite can fold real event shapes without shipping anyone's conversation content, and they are excluded from the published package. The generator is deterministic: running it twice produces byte-identical files.

The browser probes (scripts/probe-*.mjs) drive headless Chrome/Chromium ($DSH_CHROME overrides the binary) and load the harness pages from scripts/; those pages resolve React UMD from ?nodeModules= or a checkout-local node_modules ($DSH_NODE_MODULES overrides the lookup). React is a dev-only tool for the harness, never a package dependency.

License

MIT — see LICENSE.