# dsh-handbook documents an agent runtime that was two days old

> A Chinese-first community manual for DeepSeek's dsh agent runtime, fifteen chapters covering plugins, tuning, and an ecosystem report cross-checked against 1804 plugin repositories. It shipped within a day of the release it covers, its own warning block puts dsh at an alpha tag on GitHub and an rc line on npm, and the reasoning tiers it measured are not the ones the vendor ships.

**Electricitysheep/dsh-handbook** — DeepSeek Harness (dsh) 从 0 到 1 深度手册：安装/插件开发/性能调优/实测案例/同模型多 Agent 实测对比（中文 + 英文 PDF）

- Repository: https://github.com/Electricitysheep/dsh-handbook
- Website: https://github.com/Electricitysheep/dsh-handbook
- Stars: 832 · Forks: 49
- Language: HTML
- License: not declared
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/electricitysheep-dsh-handbook

## The handbook shipped within a day of the release it documents

The subject is DeepSeek Harness, the runtime the handbook calls dsh: an agent framework built on an everything-is-a-plugin idea, written in TypeScript, released under MIT, and open-sourced by DeepSeek on 2026-08-13. The community section says the handbook collected its first feedback two days after that release, with 280 or more stars and 195 replies in the official repository's discussion area. The tags line up with the claim. The first three releases are v1.6.0 and v1.7.0 both dated 2026-08-13 and v1.8.0 dated 2026-08-14, so all three landed inside about a day of the thing they describe. The last push on the handbook repository is 2026-09-07, which is more than three weeks after the newest tag. So the prose is contemporaneous with a release week rather than a retrospective, and the document kept being revised after its own version numbers stopped moving.

## The first block on the page is a warning about prerelease versions

Before anything else, the front page carries a warning rather than an introduction. It states that dsh's current GitHub version is `v0.1.3-alpha.1`, a prerelease tag, while the line already published to npm is `0.1.2-rc.1`, and it tells the reader to evaluate carefully before using it in production, with a pointer to a version-notes section further down. So the two distribution channels sit on different lines, and both are pre-1.0 with an alpha or release-candidate marker attached. That matters more here than it would in an ordinary handbook, because the book's central claim is that every command in it was verified on a real machine. The path the page gives for trying it runs straight through npm:

```bash
# 1. 安装（需要 Node.js ≥ 22）
npx -y @deepseek-ai/dsh web

# 2. 浏览器打开 http://127.0.0.1:3080，开始对话
# 3. 或跑一次性任务（适合脚本/CI）
dsh --profile headless "你好，请用一句话介绍自己"
```

So a web mode on port 3080 at the loopback address, a one-shot headless mode for scripts and CI, and a Node.js floor of 22 rather than the 18 that most JavaScript tooling asks for. The question the warning raises is what that verification was against, and the answer is a runtime sitting between an alpha tag and a published rc line, which is exactly the situation in which a verified command stops being verified.

## The lowest reasoning tier in the handbook is not the lowest on the vendor's adapter

Three reasoning tiers are described: `low` for the fastest path and simple tasks, `high` as the default, and `max` for the hardest reasoning. A note qualifies them, and the qualification is the important part. The `low` tier is the tier the handbook measured through its own gateway, named as pi-ai and opencode-go, while the DeepSeek official adapter exposes `off`, meaning thinking turned off and the fastest setting, then `high`, then `max`. So the bottom rung has a different name depending on which path you are on, and a setting written against one will not read the same on the other. The underlying performance claim is stated plainly alongside: thinking accounts for ninety percent of the time in a toolchain task, spent before each tool call. That is the reason the book presents downgrading a tier as the largest single speedup available, and it is also the reason the tier naming matters more than it first appears.

## Mounting a plugin is two edits against a cordis patch file

A profile is defined as a bundle stack plus your own patch layer, expressed as a `package.json` and a `cordis.patch.yml`. Mounting a plugin on top of that takes two changes: add the dependency and add an insert line. One npm package carries both halves of a plugin, Node-side tools or services on one side and browser-side UI on the other, which the handbook calls the host and client split. Five extension points are named: the `agent/request` waterfall, `conversationEvents`, `ctx.slots`, `settings`, and `ctx.provide`. Then six pitfalls are listed without softening any of them: release candidate dependency breakage, a plugin missing its main entry, a `next()` that is never awaited, types not being recognised, ModuleLoader, and an occupied port. The repository ships a plugin template under `examples/plugin-template/`, and the chapter on writing plugins describes it as cloneable.

## Two of the fifteen chapters are about what has not been built yet

The contents put an honest accounting inside the book rather than after it. Chapter 12 is titled known limitations and boundaries and is described in the contents as an honest version of the release candidate, covering instability, an early ecosystem, and cross-platform gaps. Chapter 11 is the outlook chapter, covering technology, ecosystem, competition, opportunity, and risk predictions plus a timeline. Between them, chapter 10 reports runs rather than forecasts: a data cleaning pipeline in 186 seconds and a five-bug fix in 94 seconds. Chapter 13 covers the sandbox mechanism, the permission model, an approval flow, and a plugin security audit checklist. Chapter 14 covers a measured ninety-seven percent cache hit rate, a cost model, how reasoning tiers interact with cost, and budget practice. Those timings and that percentage are the handbook's own measurements of dsh rather than third-party benchmarks, and the appendices add a glossary of thirty or more terms, a list of the official `@deepseek-ai` packages, and a same-model comparison across three agents.

## The ecosystem report counts 1804 plugin repositories and names one supply gap

Chapter 15 is the longest document in the set and works by cross-checking an inventory of 1804 plugin repositories against 780 discussion threads. Five conclusions come out of it. Windows is the top pain point, with fifteen or more threads sharing one root cause on the Chinese-language path, alongside koffi, ports, and subprocesses. Official work is thin while community work is broad, counted as 140 or more desktop shells, 77 in memory, and 132 in vision. Security audit is active but tooling is scarce, with only nine plugins in the sandbox category, which the report names as a supply gap. A family of serialization bugs is called the main battleground of the release candidate period, naming an unknown tool, omitted reasoning, and discarded `run_code`. Cost transparency is treated as a necessity rather than a nicety. Six capability seams then follow as build priorities: a vision channel, a memory seam, a desktop TUI protocol, an evaluation loop, first-class Windows support, and a plugin registry.

## No licence file at the root, and a site built to be read by a model

Two structural facts sit underneath everything else on this page. The repository record carries no licence assertion, and no licence file appears at the top level of the tree, so the terms for a document other people may quote, translate, or republish are not stated in the repository itself. Second, the deliverable is a site before it is a repository: the root carries `llms.txt` and `llms-full.txt` alongside `index.html`, `_sidebar.md`, `_404.md`, and a `.nojekyll` file, which is the shape of a documentation site meant to be read by a browser and by a language model from the same source. There is also `README-REVIEW.md`, `ROADMAP.md`, `CONTRIBUTING.md`, a `docs/` tree, an `examples/` directory, and a `scripts/` directory. So a fork or a redistribution has to answer the licence question somewhere other than here, and the machine-readable entry points are part of the project rather than an afterthought.

## Conclusion

Read dsh-handbook as a snapshot of one week in the life of a new tool rather than as maintained reference. That cuts both ways. Its value is that every command was run on a real machine, including plugin mounts, a data cleaning pipeline in 186 seconds, a five-bug fix in 94 seconds, and a measured 97 percent cache hit rate, and its chapter 12 is an honest account of the release candidate's instability. The cost is that its own release tags stopped three weeks before its last commit, so the text is still moving while the versions it describes are not. Two things to check before you follow it. The handbook's lowest reasoning tier is named differently from the one DeepSeek's own adapter exposes, so a configuration copied from its benchmarks will not read the same on the official path. And the repository carries no licence assertion and no licence file at the root, so if you intend to republish or fork the text, resolve that before you do. For anything beyond reading, pin your dsh version to something you have tested, since the handbook's own first block calls it a prerelease.

## FAQ

### What is dsh-handbook and who wrote it?

It is a Chinese-first community manual for DeepSeek Harness, the agent runtime DeepSeek open-sourced on 2026-08-13. The front page credits the community rather than one author, reporting 280 or more stars, 195 replies in the official repository's discussion area, and 39 FAQ entries that came from real questions.

### What version of dsh does dsh-handbook cover?

A warning block at the top states that dsh's current GitHub version is v0.1.3-alpha.1, a prerelease tag, while the line published to npm is 0.1.2-rc.1, and it advises evaluating carefully before production use. The handbook's own releases are v1.8.0, v1.7.0, and v1.6.0.

### Which reasoning tiers does dsh-handbook describe?

Three: low for the fastest path and simple tasks, high as the default, and max for the hardest reasoning. A note adds that low is the tier measured through the handbook's own gateway, pi-ai and opencode-go, while the DeepSeek official adapter exposes off for thinking turned off, then high, then max.

### How does dsh-handbook say to mount a plugin?

A profile is a bundle stack plus a patch layer made of package.json and a cordis.patch.yml. Mounting a plugin takes two changes: add the dependency and add an insert line. The manual also lists five extension points and six pitfalls, including release candidate dependency breakage and a next() that is never awaited.

### What does the dsh-handbook ecosystem report find?

It cross-checks an inventory of 1804 plugin repositories against 780 discussion threads and reports five conclusions, among them Windows as the top pain point, only nine sandbox-category plugins as a supply gap, and a serialization bug family covering an unknown tool, omitted reasoning, and discarded run_code. It then proposes six capability seams as build priorities.

## Sources

- [Electricitysheep/dsh-handbook on GitHub](https://github.com/Electricitysheep/dsh-handbook)
- [Issues](https://github.com/Electricitysheep/dsh-handbook/issues)
- [Project website](https://github.com/Electricitysheep/dsh-handbook)
- [README](https://github.com/Electricitysheep/dsh-handbook/blob/main/README.md)
- [Releases](https://github.com/Electricitysheep/dsh-handbook/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/electricitysheep-dsh-handbook