dsh-compaction-route
在 DeepSeek Harness Web 设置页面中选择对话压缩摘要模型，并为主模型无法处理重放历史记录时指定备用模型。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:643048695/dsh-compaction-route#e05c339f6a91eeb4aefc7b7d52625204add584e5Compaction Route 以 dsh-compaction-route 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →Pick the conversation-compaction summarizer from the Web settings page, and give it a fallback model.
A DeepSeek Harness plugin.
DSH's compaction engine resolves one summarizer from its own composition config and has no failover. When the summarization call is rejected it throws, /compact reports "Compaction could not produce a useful summary", and nothing else is ever tried.
That matters because the replayed history is sized by DSH's fixed chars/4 estimate, while every provider tokenizes the same bytes differently and enforces its own input ceiling. A history that comfortably fits the model you are chatting with can be too large for the summarizer you picked — and the whole compaction fails with nothing to catch it.
Measured on a real 950k-window session:
| DSH estimate for the replay | 743,536 tokens |
| What the chat model actually read | 744,184 tokens |
| What the chosen summarizer needed | over its input ceiling → HTTP 400 |
The meter was calibrated on the chat model's tokenizer (0.1% off), so it reported "fits" while the summarizer was already over. Three routes measured against one identical payload:
| Route | Tokens for the same bytes |
|---|---|
| gemini-3.8-flash | 1,027,843 |
| opencode-go/deepseek-v4.1-flash | 939,469 |
| surplan/deepseek-v4.1-flash | 939,003 |
The tokenizers differ by ~10%; the ceilings are the same (1,048,576). So "just pick a different model" is not enough on its own: a fallback only rescues an oversized replay when its window is larger than the primary's. The settings card says so when your pick cannot help.
Listens on the llm/stream waterfall — the single seam every model call passes through — and for purpose === "compaction" requests only:
Every other request — chat turns, subagents, session titles, web search — falls straight through untouched.
Web UI: Settings → Plugins → Add plugin, and enter the spec:
github:643048695/dsh-compaction-route
CLI (ordinary profiles; the desktop profile is managed by the Electron app and refuses the CLI):
dsh plugin --profile <profile> add github:643048695/dsh-compaction-route
Then enable the bundle when the installer asks. There is no build step, and the plugin mounts without restarting the app. The row it inserts is id compaction-route, which is also the settings namespace.
Settings → Plugins → dsh-compaction-route → Configuration.
| Field | Meaning |
|---|---|
| Enable routing | Off leaves the engine exactly as it was. |
| Primary model | The summarizer used first. |
| Fallback model | Tried when the primary ends in an error. Empty disables the fallback. |
| Reasoning effort | Effort for compaction calls; empty keeps the provider's default. |
Both dropdowns are built from the models actually installed in your profile — read from the llm-pi-ai settings namespace, so whatever you have is what you can pick — and each option shows its context window.
A fresh install ships with both models empty and changes nothing. Nothing is guessed: until you pick a primary, compaction behaves exactly as it did before. Naming a route in shipping code would be a guess that silently redirects someone else's profile at a provider it may not have — and a fallback without a primary is meaningless, so it does not start routing on its own.
Every field is volatile, so a change applies to the next compaction with no restart.
A fallback rescues an oversized replay only when its window is larger than the primary's. Two same-size routes just repeat the same rejection.
The card raises a warning when the fallback's window is ≤ the primary's, and when both are the same model.
compaction call ──▶ llm/stream waterfall
│
├─ purpose !== "compaction"? ──▶ pass through untouched
│
├─ primary ──success──▶ yield its chunks
│ └──terminal error──▶ fallback ──▶ yield whatever it returns
└─ (a call this plugin created is never re-intercepted)
Why it re-enters ctx.llm.stream() instead of calling next(newOptions). cordis builds a waterfall's next as a closure over the original argument array:
const next = () => (cbs.shift() ?? inner)(...args)
so next(modifiedOptions) silently ignores its argument and dispatches the original options again. Changing provider/model therefore has to re-enter ctx.llm.stream() from the top of the chain; a WeakSet of the call objects this plugin created keeps that re-entry from intercepting itself.
purpose is the discriminator, so nothing else is rerouted.compaction/summary reports the engine's summarizationProvider / summarizationModel, not this plugin's override; a fallback win shows up as this plugin's log line instead. Point the engine's own row at the same primary if you want the session log to agree.Works on @deepseek-ai/dsh 0.1.7-rc.2 (verified against it) and the same-node 0.1.7 line.
Neither half needs a build step.
lib/index.js host half — the llm/stream route + the settings schema
client/client.js browser half — the configuration card
cordis.patch.yml the bundle patch: one row, id "compaction-route"
MIT — see LICENSE.