778672151/dsh-session-turn-eta

Live remaining-time prediction for the current DeepSeek Harness turn, shown as a progress bar with a live percentage under the composer.

• Running — a bar whose width follows elapsed time over the predicted total, with a percentage and a humanised time left (~12m 34s left / 约剩 12 分 34 秒). The percentage ticks locally while the turn is open. The filled track ends in a leading dot and carries a slow shimmer.
• Finishing — once a turn outruns its own estimate the bar fills and pulses with a "finishing" label, instead of a misleading "0s left".
• Completed — 100%, with a short one-shot burst at the tip.
• Failed or interrupted — the bar turns red and reads "progress interrupted".

Install

dsh plugin --profile web add github:778672151/dsh-session-turn-eta

The repository ships a prebuilt lib/, so installing does not run a build step. Restart dsh web if the profile asks for it, then send any message: the bar appears under the input box while the turn runs.

Compatibility

DeepSeek-Harness desktop	0.2.1-rc.5 (type-checked against its published packages)
@deepseek-ai/cordis	>=4.0.5 <5
@deepseek-ai/dsh-session	^0.2.1-rc.1
@deepseek-ai/dsh-session-projection	^0.2.1-rc.1
@deepseek-ai/dsh-client-ui-conversation / dsh-client-locale	^0.2.1-rc.1 (client half, optional peers)
Node	>=22 for building; the shipped bundle runs on the DSH host

How it works

The host half registers one turnEta session projection and nothing else: it folds the durable turn/start, step/start, step/end and turn/end events into a prediction. The projection registry already drives every registered unit once per committed event, so the plugin does not replay session/event a second time; it only mirrors the registry's change feed (onChanged, which fires when the published view changed by Object.is) onto two typed Cordis events: turn-eta/update while a turn is open and turn-eta/complete once per turn.

• The per-step rate blends the live turn's own observed rate with the session's 90th-percentile historical step duration (read after winsorising the sample at 8 x median), so the rate tracks the steps that dominate a turn while a single 9-hour idle gap still cannot drag it up.
• The expected step count is the conditional median of the finished turns that were at least as long as this one, so a growing turn keeps a live estimate.
• The published total is held against early noise and re-anchored upward once the turn has passed 50% of it, so a turn that keeps working stops being pinned to its first guess and the estimate never sits at 100% while it runs.
• The total always keeps at least one step of runway while the turn is open, so a prediction can never report completion before the turn actually ends.
• A running turn renders at most 99%; only a turn that really ended shows 100%. A turn that outran its estimate fills and pulses under a "finishing" label instead.
• Every finished turn anchors the next one, whatever closed it (a turn that errored or was aborted is still evidence of how long turns run); the first turn bootstraps from a prior until the session has real history.

The client half reads that projection through the standard useProjection seat and renders it on the conversation.composer.dock slot. The plugin never mutates the session and registers no model-visible capability.

Skins

The bar ships five skins: auto (harness theme tokens, the default and the only one that follows light/dark automatically), bilibili, mint, sunset, and ocean. A skin only owns the fill gradient, the leading-dot glow, the track tint, and the celebration colour; layout and accessibility never change.

Pick one either per render or document-wide:

// per render (the dock entry accepts an optional `skin` prop)
<TurnProgress skin="bilibili" ... />

<!-- document-wide, e.g. in the host page or a user script -->
<body data-turn-eta-skin="ocean">

The client entry exports TURN_ETA_SKINS, TURN_ETA_DEFAULT_SKIN, TURN_ETA_SKIN_ATTRIBUTE, isTurnEtaSkin() and resolveTurnEtaSkin(). Unknown values fall back to auto. All motion (shimmer, pulse, celebration) is disabled under prefers-reduced-motion: reduce.

Embedding the estimator

The fold is plain data in, plain data out: the same code the bar renders from can be driven without Cordis, a session, or the plugin instance.

import { createTurnEtaFold, etaCore, ETA_TUNING } from '@dsh-external/dsh-session-turn-eta'

// full fold: the projection the client renders
const fold = createTurnEtaFold()
for (const event of durableLog) fold.apply(event)
const { remainingMs, predictedTotalMs, method } = fold.view()

// or just the math, from whatever facts you already have
const core = etaCore({ startTime, stepDurations, completedTurnSteps, stepSamples, asOf })

createTurnEtaFold(seed) accepts a captured state() so a fold can continue from a projection checkpoint instead of replaying the whole log. ETA_TUNING exposes every constant (RATE_PERCENTILE, REANCHOR_AT, OUTLIER_CAP, …) so a consumer can read the calibration instead of copying numbers.

Cost

The projection runs on every committed session event, so the fold is written to cost O(1) amortised per event rather than O(history) per event:

• the sample history is appended as a list and its ascending copy is grown by insertion (withSample), so sorting is never repeated for one append;
• the rate profile (0.9 / 0.25 / 0.75 quantiles of a winsorised list) is cached per sample-list reference, so it is recomputed once per finished step instead of once per event;
• the expected step count is read off the ascending anchors by binary search instead of filtering and re-sorting them;
• the view of an event reuses the core its anchor advance already computed.

Measured with npm run bench on Node 24 (per-event cost of the fold alone, no registry, no UI): 12.9k events over 8 turns of 50 steps run at ~245k events/s, up from ~9.5k events/s before these changes; the cost stays flat as the history grows (32k events over 80 turns: ~150k events/s).

npm run test:equiv fuzzes the optimised primitives against the reference formulas (9,300 comparisons) so the speed-ups cannot drift from the maths.

Build

The published bundle is built by tsdown (no monorepo checkout required):

npm install
npm run build      # -> lib/index.js (host) + lib/client.js (client)
npm test           # host estimator invariants + client render states

npm run typecheck checks both halves against the published 0.2.1-rc.x contract: the host half (tsconfig.json) against dsh-session / dsh-session-projection, and the client half (tsconfig.client.json) against dsh-client-ui-slots / dsh-api-session-controller / @types/react.

scripts/build.sh is an optional development helper that links a contract tree (DSH_CONTRACT_DIR, defaulting to a local copy of the published packages) and type-checks both halves, so the build and the desktop app agree on the same contract instead of on whatever a monorepo checkout happens to contain.

License

MIT