Preface¶

When running a longer task with DeepSeek Harness (dsh), the most common uncertainties in the web interface are: Is the model still generating? Where am I in the todos? Is the sub-agent stuck on approval? Did that previous interruption leave any traces? The core interface displays tool calls and post-settlement statistics, but there is often no always-visible session status near the input box.

DeepSeek Harness is an agent runtime open-sourced by DeepSeek AI, with the architectural slogan “Everything is a plugin”, using Cordis for composition at the underlying layer. The official repository is still marked as developer preview, and breaking compatibility will continue to occur. Capabilities like interface enhancements usually do not modify the agent-loop, but are hooked into the slots of the Web GUI. dsh-ui-progress does exactly this: placing a persistent progress bar in the input box dock area, reading session snapshots to display the real execution status.

Below is a collation after checking against the plugin directory page, GitHub README/INSTALL.md, and the official Harness repository: what it is, what it can display, how to install it, and what boundary cases to pay attention to when using it.

What It Is¶

dsh-ui-progress is an interface enhancement plugin for the DeepSeek Harness Web UI, with the npm package name @dsh-external/dsh-ui-progress, maintained by lhh010, licensed under BSD-3-Clause, and mainly written in TypeScript. As of 2026-08-18, both the directory page and GitHub repository show 8 stars. The current default version is v0.9.1 (the version field in package.json).

It solves a specific problem: providing a persistent session progress bar in the conversation.input.dock (input box dock area), covering real todos progress, real-time token generation rate, interrupted orange state, and todo reminders. It is implemented as a pure client-side browser plugin that does not touch the agent-loop; starting from v0.8.0, the host half is empty, and no visible input is injected into the model either.

In package.json, the client declaration is written as a nested dsh.client, with platform set to web, and injects @deepseek-ai/dsh-client-locale, @deepseek-ai/dsh-client-runtime, and @deepseek-ai/dsh-client-ui-conversation. That is to say, it only serves dsh web, and is not a terminal TUI plugin.

The DeepSeek Harness Plugin Repository that hosts it is an independent community directory, and has no affiliation or endorsement relationship with DeepSeek / HyperGryph. The directory page links to the maintainer’s repository, and you should review the source code and license before installing.

Core Features¶

Persistent Progress Bar Reads Session Snapshots¶

The progress bar is attached to the input box dock area, reading the framework’s useSession snapshot instead of estimating a “session completion percentage” on its own. The README clearly states that it renders the following information:
- Running / Idle
- Currently flying tool name
- Number of tool results that have been settled for the current window
- Current round

When running, the left loading spinner rotates, the progress bar has a shimmer sweep and brand color halo pulse, and the fill width eases in.

Fill width is calculated based on todos projection: when there are todos, the ratio is (completed + in-progress) / total, and in-progress tasks are counted towards progress; when there are no todos, it is fixed at 100%. The repository explicitly states that there is no dedicated projection for overall session progress, so pseudo-percentages are not displayed. v0.8.0 has removed the old segmented fill of “each settled tool result counts as one block, with a window limit of 10”.

When running, it also displays:
- Elapsed time: Starts from the beginning of the current round, stepping by 0.1 seconds; after one minute, it collapses to XmYs, and then increments by seconds.
- ETA: Only displayed if the model’s latest report_progress report includes an eta field. The plugin does not perform linear extrapolation on its own, and will not display it if the model does not report one.

When idle, it displays the time taken for the previous round. After a session has run at least one round and enters idle, the progress bar turns light green; a session that has never been run remains neutral blue-gray.

Interrupted Orange State¶

v0.8.0 added the interrupted state: if the most recently ended round of this session was interrupted or stopped—whether manually interrupted, API failure, or other accidental reasons—the progress bar turns orange (light orange background + orange-red fill/icon/percentage + slow pulse), with the label “Interrupted”. This takes priority over normal running/completion color schemes.

The judgment only looks at the most recent round. A new round that continues to be sent and completes normally after interruption will restore the progress bar to its regular color scheme; the interrupted legacy marker in the window will still exist, but will no longer trigger the color scheme. The attention state (amber below) still takes priority over the interrupted state.

The repository also lists undetectable scenarios: an interrupted round leaves no traces when there is no partial content or in-flight tool call; after paging or compressing and truncating old markers, the interrupted state will fade; rounds in the model-retry path will not display the interrupted state.

Real-time Token Generation Rate¶

Starting from v0.9.0, when running and the model is generating (there is streaming partial content, and no pending human-computer interaction), the progress bar displays the real-time rate next to the elapsed time, for example 12.3 tok/s. It is not displayed during tool execution, waiting for human-computer interaction, or when the round ends; the exact rate after the round ends is presented by the core StatsLine to avoid duplication.

The streaming chunk itself does not carry token counts, and the core end only has provider usage after the round ends, so this number is a self-calibrated estimated value:
1. Initially, the current partial is converted based on CJK-aware character density: wide CJK characters ≈ 1 character ≈ 1 token, and the rest follow the same 4 characters ≈ 1 token as the core token-meter.
2. Once there is a settled step in the window that reports real output tokens, scale the subsequent estimates with real tokens ÷ weighted character count to make the number close to the density of the model tokenizer in use.
3. The rate is averaged over a roughly 1-second sliding window, only counting newly added tokens in the window; an empty window retains the last reading and does not reset to zero.
4. The caliber is consistent with the core-side settled tokens/s (outputTokens / decodeMs), excluding TTFT; each new step restarts the calculation.

The README emphasizes: the displayed value is not the token number reported by the provider on the spot, and it is still character-heuristic before the first calibration step.

Todo Reminders (Attention)¶

When there are interactions waiting for human processing in this session or its descendant subagents, the progress bar switches to the amber warning state, and prompts the source and type:

Plan review also falls into this category of interactions waiting for human processing. Sub-agent sessions will be hidden by the official sidebar, and the pending state is read from pendingInteraction in the origin: 'subagent' line of the global session list. This is the main way the main agent perceives that the sub-agent is waiting for you.

The state priority, according to the README, is:
pending (amber) > running (blue) > interrupted (orange-red) > done (green) > idle (neutral)

No Longer Injects Content into the Model¶

Starting from v0.8.0, the plugin no longer injects any model-visible input: the built-in report_progress tool and the reporting guidance paragraph have been removed, the host half is empty, and only browser-side rendering is performed. It does not modify user messages or the session context.

ETA still works, provided that other host plugins have registered report_progress, and the model has provided an eta field in the report. This plugin no longer provides this tool itself.

Configuration: No configuration keys. After installation, you only need to insert one plugin ID line into the configuration tree.

Installation and Activation¶

The installation command given on the directory page is:

dsh plugin add github:lhh010/dsh-ui-progress

For reproducible installations, the directory page recommends pinning the commit hash:

dsh plugin add github:lhh010/dsh-ui-progress#commit

Replace commit with the actual hash. The directory page also reminds users that the plugin runs with the permissions of the current dsh process, may execute code during installation, and you should check the source code repository and license before installing.

The repository’s INSTALL.md provides more specific details for the current default path. v0.9.1 targets DSH snapshot snapshot0810 (snapshots/20260810T155924Z), and states compatibility with snapshot0811 and the final snapshot snapshot0812 (snapshots/20260812T172954Z-final), as well as the npm release versions @deepseek-ai/dsh@0.0.1-rc.5 (dist-tag next) and @deepseek-ai/dsh@0.0.1-rc.2. The prerequisites are: the locally built DSH snapshot already exists on the machine (~/.dsh/source/current points to the snapshot containing the lib/ artifacts), and dsh web is running.

The way to pin the version by tag and install it into the web profile is as follows:

git clone https://github.com/lhh010/dsh-ui-progress.git
cd dsh-ui-progress && pnpm install

dsh plugin --profile web add '@dsh-external/dsh-ui-progress@github:lhh010/dsh-ui-progress#v0.9.1'

Local development can also use link:

dsh plugin --profile web add link:/path/to/dsh-ui-progress

Then insert the following into $DSH_HOME/profiles/web/cordis.patch.yml:

- insert:
    - id: dsh-ui-progress
      name: '@dsh-external/dsh-ui-progress'

INSTALL.md clearly states: this configuration supports hot reload, and you do not need to restart to add the configuration line. Starting from v0.8.0, the host half is empty, and refreshing the browser page will take effect for the browser half. If you have modified the source code or changed the snapshot, hosts after 0809 will verify the client build artifacts when activated, and a missing one will throw ClientPackageCompositionError and refuse to start dsh web. In this case, you need to re-run pnpm run build before starting.

Do not mix default tags with old snapshots. The corresponding relationship in the README can be condensed into the following table:

Users of 0809 should pin #v0.9.0, users of 0808 should pin #v0.8.0, users of 0807 should pin #v0.6.0, and users of 0805 should pin #v0.1.0. DSH is still iterating rapidly, so double-check your snapshot or npm version before installing.

Typical Usage¶

The plugin has no additional configuration items. After enabling it, just look at the progress bar above the input box. The verification steps given in INSTALL.md can be done as-is:
1. Start a session that runs tools, preferably with todos. When running, you should see the spinning loading spinner and real-time elapsed time; when the model is generating, the token rate will appear; if other plugins provide report_progress and the model reports eta, the estimated remaining time will also appear.
2. When there is a todos list, the fill width should change according to the real completion proportion; when there are no todos, the fill is fixed at 100%, do not read it as “all tasks have been completed”.
3. Manually stop the session, or wait for an API error interruption, and the progress bar should turn orange-red “Interrupted”.
4. Send a new message and let the round complete normally after interruption, and the progress bar should return to the green completion state.
5. If this session or sub-agent is waiting for approval/selection, the progress bar should first enter the amber attention state, and the copy will distinguish between this session and the sub-agent.

The README also mentions a troubleshooting method: after starting dsh web, the browser’s window.__DSH_BOOT__ manifest should include @dsh-external/dsh-ui-progress, and /plugins/@dsh-external/dsh-ui-progress/client.js should return 200. Starting from 0810, if package.json only has the top-level dshClient and no nested dsh.client, the host will silently exclude it from the boot graph — “starts successfully but the plugin is completely missing”. The current v0.9.1 has been migrated to the nested field.

Applicable Scenarios and Notes¶

It is suitable for these situations:
- You use dsh web daily and want to always see near the input box whether the current round is running, where you are in the todos, and how much time has elapsed
- You often encounter sandbox approvals, option selections, or sub-agents in tasks, and need a todo reminder that will not be hidden by the sidebar
- You care about streaming generation speed and want to compare the running estimated tok/s with the post-round StatsLine settlement value
- You accept “pure UI, zero core changes” and do not want the progress plugin to modify the agent-loop or inject prompts into the context

Before using it, please note the following items, all from the directory page and repository documentation:
1. Only covers the Web UI. dsh.client.platform is web. TUI or pure CLI sessions in the terminal cannot see this progress bar.
2. Fill ratio is not full progress. It is fixed at 100% when there are no todos; when there are todos, it only reflects the current todos list. Do not use it to judge “how long this session will take to completely end”, unless the model provides eta through report_progress separately.
3. Token rate is an estimated value. There is no official token count during the streaming phase; before calibration, it is character-heuristic, and after calibration, it is still a sliding window average. The final settlement value in the core StatsLine shall prevail.
4. ETA depends on other plugins. This plugin no longer includes the built-in report_progress. If no other plugin has registered this tool, or the model does not report eta (non-string/non-positive numbers are also considered invalid), the ETA line will not appear. The progress bar only takes the most recent report in the window.
5. Interruption detection has blind spots. Interruptions without partial content or in-flight tools may not be detected; old markers will be lost after window compression; retry paths will not display the interrupted state.
6. Version must match the snapshot. The default v0.9.1 targets 0810 and later; earlier snapshots need to use the corresponding tag. The official Harness is still in developer preview, so you should check the compatibility description in the README after changing snapshots.
7. Permissions and source. The plugin runs with the permissions of the current dsh process. The community directory is not an official app store, so check the GitHub source code and BSD-3-Clause license before installing; pin the tag or commit for reproducible environments.

Summary¶

dsh-ui-progress pins the session execution status to the input box dock area of the Web UI: it fills the progress based on the real todos list, displays elapsed time and self-calibrated token rate when running, turns orange-red when interrupted, amber when waiting for human processing, and light green when completed. It is an open-source client plugin maintained by lhh010, does not modify the agent-loop, and has not injected content into the model since v0.8.0.

For users who are already using dsh web and want to stop staring at the sidebar and tool cards, the main change after installation is an always-visible status bar above the input box. The version must match the current DSH snapshot, and check the source code and license before installing.

Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-ui-progress/

GitHub: https://github.com/lhh010/dsh-ui-progress