dsh-token-live

Live readings under the DeepSeek Harness composer: how big the draft is, what this session has cost, and how full the context is.

What it shows

Reading	Source	Moves when
Draft ≈ N tok · M chars	the session-scoped input hook (InputState.draft)	every keystroke
Cost ¥0.42 · ¥1.8/h	the tokenUsage projection × DeepSeek's published price list	each request settles
Compare v4-pro ¥3.81	the same buckets × the other model's prices	each request settles
Context used / window + bar	the contextPressure projection	a provider reports usage
Session N tok · X% cached	the tokenUsage projection	each request settles

The plugin adds one entry to the composer dock (conversation.composer.dock). It does not replace the harness's own stats pill.

Install

dsh plugin --profile web add dsh-token-live

Then reload the page. The browser bundle reloads on its own when a client bundle changes; the server-side row needs the plugin tree to re-compose, which the profile's patchReload: live does on save, or a dsh web restart.

The reading nothing else shows

What this session would have cost on the other model.

The 对照 / vs pill prices your exact token buckets — the same cache hits, the same cache misses, the same output — on the costliest other model in the price list, at the same billing tier. Hovering it lists every model in the table against your session, with the current one marked.

Why it earns its place: every other cost plugin answers what did I spend, and that question already has a dozen good answers. Choosing a model is a different question — what would the expensive route have cost me for this exact work — and it is the one a price list exists to answer. On this session, flash has cost ¥1.44 and v4-pro would have cost ¥3.81 for the same tokens; that is the number worth knowing before switching, and it costs nothing to compute from data the browser already has.

A survey of the 197 entries in the awesome-dsh-plugin Usage & Billing category (2026-09-12) found zero that report a cross-model counterfactual for the session in view. Several compare old and new list prices after a rate change; none compare your usage across models.

Rendered only when both models are priced: an unpriced model shows no comparison rather than a made-up one.

The session tooltip explains the big number

会话 30.7M tok looks alarming next to a 327K context. It is not 30M tokens of content — it is the same context sent again on every step. The session tooltip says so, dividing cumulative billed input by the newest provider-reported prompt size: "cumulative billed input is about 94x the current context". Only one of the 197 entries says anything comparable.

Why the draft counter is the interesting part

The harness reports tokens after the fact. Two things in particular are not available anywhere in it:

• What the composer currently holds. During streaming the client's PartialAccumulator.push() returns false for usage chunks, so no live token figure reaches the UI at all.
• What it will cost. Nothing in the harness carries money: the token meter's "pricing" is image-token pricing, unrelated to billing.

The harness's own estimator is a flat four characters per token (dsh-token-meter's CHARS_PER_TOKEN). That underprices CJK text by two to three times, so the draft estimate here weights dense scripts separately: about 0.7 token/character for CJK/Kana/Hangul/fullwidth, about 4 characters/token for everything else.

Cost model

Official prices, CNY per million tokens, at peak hours (source, effective 2026-09-10):

Model	Cached input	Uncached input	Output
deepseek-flash	0.04	2	8
deepseek-v4-pro	0.30	9	27

Idle hours bill at exactly half. Peak is Beijing time (UTC+8), Monday through Friday, 09:00–12:00 and 14:00–18:00; everything else is idle. The plugin computes the tier from the wall clock, independent of the browser's own time zone.

Details:

• The model comes from the modelSelection projection's lastUsed — the model that actually produced the recorded usage, not next.
• Cache writes are priced at the uncached rate, because the first send of a prefix is a cache miss.
• A model that is not in the table renders as 未定价 / unpriced rather than a guessed number. A wrong money figure is worse than none.
• Cumulative usage is priced at the current tier, so a single long session spanning a tier change can be off by up to 2×. The tooltip says so.
• ¥/h is a page-local burn rate (up to 15 minutes of history); it resets on reload.
• Prices change. The table is a constant in lib/client.js with the source and effective date next to it.

Design: this plugin has no host half

Everything lives in one browser bundle. lib/index.js is an empty Cordis plugin that exists only so the loader row has something to resolve — it injects no service, holds no state, registers no route, writes no file, and makes no network call.

The consequence worth stating plainly: this plugin never reads your API key. It cannot, because it has no host half to read it with and no way to send it anywhere. It reads four client-visible things — three projections and the composer draft — and nothing else.

That is a deliberate choice, not minimalism for its own sake. On the harness version this was developed against (0.1.5-rc.1), routes registered by a plugin on the web server are not behind the session-cookie fence: a bare GET /dsh-market/installed answers 200 with no cookie at all, while / and /api/ answer 401. So a plugin that fetches a balance on the host and serves it over its own route exposes that response to any local process that can reach the port — and to anything else if the server is ever bound beyond loopback. Having no host half removes that class of exposure entirely.

If you want account balance and are happy with a host half that holds your key, several plugins on the awesome-dsh-plugin list do exactly that. This one deliberately does not.

Accuracy and limits

• The draft figure is an estimate; cost, context and session are not.
• The draft estimate reads high on symbol-dense content (code, JSON) and is closest on prose. It is a pre-send sanity check, not billing.
• The context reading is absent until a provider reports usage for the session.
• Nothing here renders a live per-token count during generation. Doing that honestly needs the streaming usage path in dsh-client-ui-chat, which discards usage chunks by design.

Development

npm test     # offline suite: estimator, price table, tier rule, render, slot registration
npm run check  # the release guard `npm publish` runs automatically

npm test executes the real lib/client.js under a stub window.__ModuleLoader__ and a stub react, so it needs no browser and no DSH install. It pins:

• the CJK-weighted estimator, including where it differs from the harness's own
• the price table and the peak/idle boundary at every edge (08:59, 09:00, 11:59, 12:00, 13:00, 14:00, 18:00, weekend)
• the counterfactual: which model is picked as the alternative, that an alias resolves before picking, and that an unpriced model renders no comparison
• that the session re-read multiple is omitted rather than divided by zero when no provider-reported prompt size exists yet
• that a partial cache hit never rounds up to a full one
• that an unpriced model says so instead of inventing a number

The browser bundle is hand-written in the client module format (window.__ModuleLoader__.load), so there is no build step: lib/client.js in the repository is the file that ships and the file that runs.

License

MIT