@andrepontesmelo/dsh-model-router
DSH 插件：声明绑定可插拔路由算法（优先级、轮询）的 VIRTUAL 模型 ID，用于在真实提供商/模型候选项之间进行路由；使用虚拟 ID 时，会透明地将请求分发到算法选定的真实提供商，并支持故障转移。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:andrepontesmelo/dsh-model-router#f083b6e93017d3f7ad97a076755b502633e06b80Model Router 以 @andrepontesmelo/dsh-model-router 发布，当前版本为 0.2.1。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →A DeepSeek Harness (DSH) plugin that turns model selection into intelligent routing: declare a virtual model id in config, bind it to a routing algorithm over a list of real provider/model candidates, and use the virtual id anywhere — agent options, model picker. Every call is transparently dispatched to a real model chosen by the algorithm, with automatic failover.
routed-chat behaves like any real model in the
picker, but is a facade over a candidate pool you define.priority — always try the first candidate; skip it only on failure. Failed
candidates get exponential backoff, giving a struggling model time to recover
before it is tried again.round-robin — distribute calls across the pool.reasoning effort that
is applied when that candidate serves the request; a model without a matching level
simply keeps its provider default.RoutingAlgorithm is a factory contract (select, onFailure,
optional onDispatch/onSuccess) — implement one and register it.Failover for a single turn — a candidate fails, the next one serves, and the provenance records who answered:
flowchart LR
V["request: routed-chat"] --> P["algorithm selects<br>the first live candidate"]
P --> C1["candidate 1<br>alpha/alpha-model"]
C1 -- "stream error" --> F["mark failed +<br>backoff cooldown"]
F --> R["retry: select the<br>next live candidate"]
R --> C2["candidate 2<br>beta/beta-model"]
C2 -- "stop" --> OK["success — provenance<br>records beta as the model that served"]
Model pools are the reality: a cheap fast model, a strong one, a spare. Hardcoding one id means a provider outage becomes your outage. Routing at the plugin layer means the rest of the harness never learns about failure — and never has to.
Requires Node ≥ 22 and a DSH profile to install into.
npm pack
dsh plugin --profile <your-profile> add file:/path/to/dsh-model-router-<version>.tgz
Or straight from GitHub:
dsh plugin --profile <your-profile> add github:andrepontesmelo/dsh-model-router
[!WARNING] Routing is config-driven and bypasses nothing you did not declare — but every candidate you list is a real provider that your prompts and completions will be sent to. Audit the
candidateslist before installing a route config you did not write, and pin the install (tag or local tarball) rather than floating on a branch.
Verify the build before installing:
npm pack --dry-run # inspect exactly what ships
sha256sum dsh-model-router-<version>.tgz
Compare the checksum with the one published with the release you are installing. A
github: install resolves the default branch at install time — pin a tag for
reproducibility.
Useful commands once installed:
npm test # 76-test unit suite (node --test)
npm run smoke # 5 failover drills, in-memory, zero network
dsh plugin --profile <your-profile> list
Add a route to your profile's cordis.patch.yml:
{
"routes": [
{
"id": "routed-chat",
"algorithm": "priority", // "priority" | "round-robin"
"candidates": [
{ "provider": "deepseek-official", "model": "deepseek-v4-flash", "reasoning": "high" },
{ "provider": "pi-ai", "model": "..." }
]
}
]
}
Pick routed-chat in the model picker (or set it as an agent's model) and route. On
failover, the response provenance shows the real model that answered and any candidates
sleeping in their backoff window.
A candidate's optional reasoning is an effort id from that provider's model. When the
candidate serves a request, the shim dispatches with that reasoning effort; if the model
has no reasoning concept (or no such effort), the level is ignored and the provider's own
default applies — the request never fails because of it.
The config-to-picker stack — a declared route becomes a real model-picker entry backed by the candidate pool:
flowchart TD
C["cordis.patch.yml<br>route routed-chat, algorithm priority,<br>candidates: deepseek-official/deepseek-v4-flash, pi-ai/…"] --> A["apply(): validate config,<br>group routes by provider"]
A --> S["RouterShim registers the<br>virtual provider routed-chat"]
S --> L["llm runtime"]
L --> M["model picker advertises<br>routed-chat"]
M --> D["picking routed-chat dispatches through<br>the algorithm with transparent failover"]
An algorithm is a factory (ctx, routes) => algorithm:
{
select(route, callCtx) // -> candidate | undefined (pure — no state advance)
onFailure(route, candidate) // record the failure so select skips it
onDispatch?(route, candidate) // first dispatch of a request
onSuccess?(route, candidate) // optional
}
The shim probes select for boolean checks, so it must stay pure; state advances happen
in the on* callbacks. The test suite in test/ pins these seam mechanics.
Start at the docs index:
PRs welcome — see CONTRIBUTING.md for the workflow and the local gate. Security issues: SECURITY.md (do not open a public issue).
prepareCall(provider, model, signal) seam, which carries no session id (the loop's optional sessionId on request
options only surfaces later, at stream time, after the pick), so a plugin cannot pin
per conversation. Unblocks if DSH passes a session id through candidate selection.npm test # unit suite
npm run smoke # in-memory failover drills (LOCAL mode)
MIT — see LICENSE.