dsh-routing-suite: a three-part DSH kit that picks a reasoning mode per task
dsh-routing-suite — injector + router-standard kit: install the runtime injector first, then the task-aware reasoning-mode router preset (measured P1-P23).
At a glance
- What is it?
- The repository bundles a runtime injector, two router presets and a graded task protocol for DeepSeek Harness. It is aimed at people already running DSH developer preview builds who want the agent to classify its own task before it starts working.
- Who is it for?
- Adopt this if you already run DSH inside the supported range and want task-aware routing without writing your own plugin. Skip it if you need a stable target, if you are not on Windows (the documented install path is PowerShell), or if you cannot accept that the harness itself is in developer preview and will break.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 11 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: DSH starts every session in the same mode
A harness that exposes one reasoning configuration treats a planning question and a one-line edit the same way. The repository's own v0.3.0 changelog entry is blunt about the consequence: before issue #13 was fixed, the README states that every session's first turn fell back to the weak mode unconditionally. The routing decision existed, but it did not fire on the request that mattered most, the first one. That is the gap this suite is built around. It targets people who run DSH daily, notice that the agent either over-plans small edits or under-plans large ones, and are willing to install a plugin to change it. It is not a general agent framework and it does not work outside DSH.
Three directories, three different jobs
The repository is flat by design. The README explains that injector/, preset/ and graded/ are ordinary directories whose contents are committed directly, and that the separate upstream repositories are kept only for independent releases and may later become mirrors. The injector supplies the dev_* tool family: injection, hot reload, unload, side-car promotion and route self-healing. The preset directory holds two router presets, router-standard and router-spec. The graded directory holds a session-level task protocol with six tools, three modes, a red-team gate and an audit endpoint. The suite also ships graded/dsh-external-dsh-graded-mode-0.0.1-rc1.tgz as a release artifact, and the README notes that graded/dsh-graded-mode-3.2.0.tgz can be added directly with dsh plugin --profile web add. The version numbers in the component table are explicitly subordinated to each component's git tags, which is worth remembering because the suite tag and the component tags do not move together.
How the router decides: persona, three bands and a per-turn nudge
Routing here is not a classifier model bolted on the side. It works by swapping the persona section of the prompt before the first request and then reinforcing that choice on every subsequent turn. The README describes three behaviour bands with an internal weak route: spec for plan-and-collect work, react for execution, mixed as a trap case to be avoided, and weak when the model classifies itself. The persona is chosen per model: Pro gets a spec sentence plus few-shot examples, which the README reports as a discrimination gain of +5.0; Flash gets neutral plus a classify instruction, reported as +5.7. The near-distance guidance is injected after each user message and the README claims 92 to 94 percent cache hit rate, 96 percent routing accuracy and 100 percent convergence, with the caveat that these are the project's own P1-P23 measurements rather than third-party results. The single-task anchors are static and cover review, convergence and anti-drift; the README states the open-task completion rate moved from 0 percent to 100 percent with them. Plan-mode boundaries are preserved because only the persona section is replaced.
The v0.3.0 fix that matters more than the routing table
Two changes in v0.3.0 are worth reading before anything else. First, first-turn routing now works: the plugin captures the first real user message via agent/inbox/claimed before assembly, so the initial request is classified instead of defaulting to weak. Second, near-distance guidance moved from wherever it was to agent/pre-step, which the changelog says injects the guidance in the same request as the user message. The stated side effect is that the previous behaviour cost an extra API call per turn, described in the README as doubling cost. That is a concrete architectural correction, not a feature addition, and it tells you the earlier releases were paying twice for the same routing signal. The same changelog lists a missing-import fix (#11), a YAML quoting fix in preset.yml (#53), a full regression after promotion (#44) and an automatic build step for git-based injector assembly (#40).
Installing it: two paths, one of which is easy to get wrong
The documented one-liner is dsh plugin --profile web add github:yjh051108/dsh-routing-suite. The longer path clones the repository, runs .\install.ps1, and the script assembles the injector, copies the presets, checks the layout and prompts for a restart. Doing it manually is where the trap is. Step one is dsh plugin --profile web add .\injector, or npx '@deepseek-ai/dsh' plugin --profile web add .\injector when dsh is not on PATH. Step two copies each preset directory flat into the user profile, for example Join-Path $env:USERPROFILE '.dsh\.agent-presets\router-standard', and the README warns explicitly that DSH only scans one level of subdirectories, so copying the whole preset folder adds an extra nesting level and the preset will not be found. Step three is a restart, after which Router Standard or Router Spec (experimental) appears as a session choice. Everything here is PowerShell, which is a real constraint if your environment is not Windows.
The version window is narrow and the harness moves under it
The declared DSH target is >=0.1.0-rc.6 <0.2.0, with the README noting follow-ups for rc.8, 0.1.1-rc.2 and 0.1.2-alpha.1. It also states plainly that DSH is in developer preview and that upstream has said breaking changes are coming. That is the single largest risk in adopting this suite: you are depending on a plugin that tracks a moving preview target, and the follow-up record lives in preset/CHANGELOG.md rather than in the top-level README. A second limitation is scope. The router presets change how the model is prompted, not what the model can do, so a task the underlying model cannot complete will not become completable because it was routed to spec mode. The measured figures are also self-reported by the project, produced on its own P1-P23 task set, and apply to the specific DSH builds it tracked. The measurement script exists precisely because those numbers may not transfer: node scripts/measure.mjs takes your session .jsonl and recomputes the metrics locally, with the README noting it only prints numbers and no session content.
What it is not: a substitute for a general agent runtime
If you need reasoning-mode routing outside DSH, the natural comparison is a general agent framework such as LangGraph, where you build the graph, the state machine and the routing condition yourself in Python or TypeScript. The difference is where the decision lives. In LangGraph the routing rule is application code you own and can unit test in isolation; here the rule is a preset persona plus a per-turn injected guidance string, applied through DSH hooks such as agent/inbox/claimed and agent/pre-step. That buys you integration you did not have to write and costs you portability: none of it transfers to another harness, and the hooks it depends on are the parts most likely to change when DSH leaves preview. A second comparison is doing nothing and switching modes by hand at the start of a session. That is free and version-proof, but it cannot classify the first message for you, which is exactly the case the v0.3.0 changelog identifies as previously broken.
Licence, maintenance and what the repository commits you to
The licence is MIT, applied at the repository level, and the README credits xiaobright/modeltest for the V4.1b evaluation and xiaobright/dsh-anchored-standard for the anchoring mechanism. MIT is permissive, but the repository is a bundle of three components that also exist as separate upstream repositories, so if you vendor a component you should confirm the licence on that component's own repository rather than assuming the top-level file covers every file. On maintenance cost, the honest reading of the material is that this is a tracking project. The DSH target range is pinned below 0.2.0, the README says breaking changes are expected upstream, and the changelog records fixes against numbered issues across routing, YAML parsing and install scripts. Budget for reading preset/CHANGELOG.md after each DSH update, and note that router-pro is listed as planned and was not part of v0.3.0, so the preset set you install today is the one you get.
Editorial conclusion
Adopt this if you already run DSH inside the supported range and want task-aware routing without writing your own plugin. Skip it if you need a stable target, if you are not on Windows (the documented install path is PowerShell), or if you cannot accept that the harness itself is in developer preview and will break. Before installing, read preset/CHANGELOG.md and the rc.8 / 0.1.1-rc.2 / 0.1.2-alpha.1 follow-up notes to check your DSH build is covered, then run node graded/scripts/measure.mjs on one of your own session .jsonl files to see whether the protocol chain actually changes behaviour in your workload.
Community notes