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.
The dsh-token-live readout row under the composer
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
