dsh-shift-router

English · 简体中文

Routine turns shouldn't cost flagship money. The turns that matter shouldn't be left to a cheap model.

Before every turn of a top-level agent, a small LLM Judge (running on your Fast-tier model chain by default — see routing.judge.mode) classifies the user's message as fast (routine) or smart (consequential). The chosen tier then drives the whole turn — thinking, tool calls, code edits — through the harness's own agent/request pipeline. The Judge only classifies; it never does the work.

🦾 [deepseek-flash]     → fix the failing test
🧭 judging…
🧠 [deepseek-v4-pro]    ← "design the auth flow" → upgraded instantly
⚠️ deepseek-flash 429 → cooldown, same-tier failover — retry in 1m
🦾 [deepseek-v4-flash]  ← next healthy model in the Fast chain

Features

• Expected-cost routing — the turn runs Smart iff pSmart ≥ θ, with θ = 1/reworkPenalty: the bar is price-independent, so the one knob is how badly a wrong downgrade hurts. Upgrades are instant; coming back down needs downgradeMemory consecutive decisive fast turns. An unsure verdict is a hold — the router keeps its position instead of guessing.
• Pluggable Judge — the verdict comes from the Fast chain by default; routing.judge.mode can point it at a dedicated Judge chain (custom) or at a decision model (decision — the TypeSafe Jev / System One class, Beta), which answers with a typed choice and a probability instead of prose, so there is no reply-parsing step and no malformed-reply failure class. Measured against the live endpoint on this deployment: correct, 1.4–5.7 s per verdict (the 15 s floor is real — the 5 s default would have aborted it), and the tier came back fully decided on 4 of 4 prompts, so treat it as a hard classifier rather than a graded one; only the orchestration signal is graded (0.10–0.83). Every configured source falls back to the Fast chain when it is unusable, and with no Judge at all the router stops routing: the turn runs on your own selected model, orchestration is cleared, and the session is told once.
• Cache-aware routing — when Fast and Smart share a provider, the decision bar is divided by sameFamilyPenalty (default 1.5) and downgrades are held off while the prompt cache is warm, so switching to a cheaper model never costs more than staying put.
• Runtime failover — 429 / 402 / 5xx / quota / usage-limit / unsupported-model failures put the model into exponential-backoff cooldown (1m → 4m → 16m → 1h04m → 4h16m → 6h cap; client-side limits start at 16m) and re-resolve the same tier to the next healthy model — same-turn retry, never cross-tier.
• Task-level orchestration — complex tasks run the Smart tier as a CTO that plans, delegates implementation to Fast engineer subagents via the harness's subagent tool, reviews each result, and iterates. The hard caps are enforced by the plugin, not just prompted: each delegation counts a round, consecutive worker failures count an escalation, and once a cap is hit the subagent tool is denied outright and the system prompt switches to a "wrap up now" notice.
• Cost telemetry — per-tier token tracking and an optional USD pricing table (/router status shows "what this session would have cost on the Smart model").
• Visible when it acts — a tier or model switch is written into the transcript as a [shift-router] Fast → Smart · … notice (the harness has no status-bar seat for plugins), so an enabled router is never silently invisible. Set ux.routerLogVerbose to get one notice per judged turn, not just per switch.
• Zero-config startup — a no-op until you configure tiers; then routing just works. Configuration is editable live via the GUI settings panel and /router config commands (persisted, no restart).

Install

This package is a DSH bundle: its cordis.patch.yml inserts the plugin row into any profile that lists it. Every channel below ends in the same dsh plugin --profile <name> add …, which forwards to pnpm inside the profile directory.

From npm (recommended)

dsh plugin --profile web add dsh-shift-router

Installs the prebuilt artifact — no build script runs on your machine, so there is nothing to authorize.

From a tarball

npm pack      # or download the release tarball
dsh plugin --profile web add ./dsh-shift-router-0.7.0.tgz

Prebuilt as well, and the option to reach for when a registry is not available.

From git

dsh plugin --profile web add github:green-dalii/dsh-shift-router#v0.7.0

A git install fetches source, not artifacts, so the package's prepare script builds dist/. pnpm ≥ 10 refuses a git dependency's prepare until you allow it — if the first add fails, copy the exact key pnpm prints into the profile's pnpm-workspace.yaml and re-run:

allowBuilds:
  dsh-shift-router: true

This authorizes the package's code to execute on your machine at install time, outside the agent sandbox. Pin a tag or commit (…#v0.7.0, …#<sha>) so a later push cannot change what you actually run.

From a local checkout (development)

git clone https://github.com/green-dalii/dsh-shift-router.git
cd dsh-shift-router && npm install && npm run build
dsh plugin --profile web add /path/to/dsh-shift-router

Verify the layer landed

dsh --profile web --dump-config | grep -A3 'id: shift-router'

The plugin loads with no configuration at all (every default is safe); tier models come from the settings card (SPEC §12) or from the profile's patch row. Later layers win, and a patch replaces the target row's whole config value — a row that overrides this one must restate every key it needs (SPEC §10).

Hot reload

DeepSeek Harness supports hot reload through @deepseek-ai/cordis-plugin-hmr, but two things are worth knowing:

1. The official Web bundle ships the shared HMR row disabled (packages/bundle/web-app/cordis.patch.yml has - id: hmr, disabled: true, upstream TODO: "Re-enable shared HMR for Web after its reload lifecycle is tested"). Re-enable it in your profile patch — this is the documented override mechanism:

   # ~/.dsh/profiles/<name>/cordis.patch.yml
   - id: hmr
     disabled: false
   

2. What hot-reloads and what doesn't (verified against the current implementation):

   • ✅ Configuration changes — editing this profile patch (or the home patch) re-runs the affected plugin's apply() with the new config, no restart. The plugin's own config is also hot through the settings namespace (/router config set and the GUI card apply live without HMR at all).
   • ❌ Module (code) changes — the HMR accepted-dependency graph currently covers the harness's own modules only; editing an external plugin's compiled files (e.g. dist/index.js) does not trigger a reload in the current release, so code changes still require a restart. This is the untested "reload lifecycle" the upstream TODO refers to, not a limitation of this plugin.
   • ❌ Client package metadata — the dsh.client manifest and exports["./client"] are cached in-process; adding/fixing them requires a profile restart (only dist/client.js content changes ride the client HMR rebuild chain).

   In practice: configure with /router config / the settings panel (always live), switch models by editing the patch (live once HMR is on), and restart only when you change plugin code.

Configuration

Configuration lives in the shift-router settings namespace: edit it in the GUI (sidebar Plugins → dsh-shift-router → the shift-router row → configure), with /router config commands, or via the profile patch row. All fields have safe defaults.

Tier models are the only thing you must choose: docs/MODELS.md covers how to pick a Fast and a Smart model (the Fast chain also serves the Judge by default), what makes a good fallback, and which models can take images.

All numeric fields are range-validated by the schema (e.g. window.minConfidence must be in [0,1], window.size a positive integer); invalid values are rejected at load / on set, never silently accepted.

Upgrading from v0.5.0: routing decisions change immediately with no config edit — the decision rule went from counting window votes to weighing expected cost, and two legacy knobs changed meaning. See SPEC.md §15 and the [0.7.0] section of CHANGELOG.md.

GUI configuration card

The package ships a browser-side (client) module that registers a "Shift-Router" card in the GUI settings page:

• Where (DSH 0.2.0-rc.2+): the sidebar Plugins page → the dsh-shift-router card → the shift-router row → its configure control. The full form also sits on the bundle's own page, so either route reaches it. The card registers into plugins.row.config (keyed dsh-shift-router#shift-router) and plugins.bundle.config (keyed dsh-shift-router), both declared by the official dsh-client-ui-plugin-manager (unchanged through 0.2.1-rc.2); the settings transport is ctx.configForms.
• Where (up to 0.1.5-rc.x): Settings → Built-in plugins → the configurable tab, where the card occupies the keyed settings.plugin.item cell (key: 'shift-router') and the transport is ctx.settingsScope. Each generation declares exactly one of the three slots, so the registrations for the other generation stay inert.
• Supported DSH range: engines.dsh = ">=0.2.0-rc.2 <0.3.0-rc.0". Since 0.2.1 that field alone decides compatibility (engines.dsh wins and peerDependencies no longer gate); the unit gate runs the upstream evaluator itself, see tests/engines-dsh-compat.test.ts.
• What: a form over every scalar leaf field (booleans, numbers, enums) plus the model chains (both tiers, and a dedicated Judge chain), grouped into seven sections (General / Models / Routing / Orchestration / Failover / Telemetry / Logs & UX) with sub-groups for the routing section (Judge / Judge source / Decision window / Cache-aware). A control appears only while it is relevant — choosing a Judge source reveals that source's own settings and hides the rest — and no dropdown shows a raw config token. Scalar fields use the compact settings-row pattern — label + hint on the left, control right-aligned on the same line — so each field is one tight row instead of three stacked lines. Controls use the host-plane design tokens: toggle switches (contrast-safe in light and dark themes), a styled select for enums, unit suffixes inside numeric inputs (ms, tokens, 0–1, …), and an ordered row editor for model chains — the row order is the in-tier fallback order, so the first available model wins and the rest are its fallbacks. The provider/model dropdowns are auto-loaded from DSH's runtime model catalog (llm.models — the same catalog the DSH settings surface reads): only providers with a currently advertised model list appear, no dormant-directory noise, and nothing is hardcoded, so the card works with any deployment's configured models. A "Custom…" escape covers values outside the catalog. Staged saving, per-field reset to default, and override markers work exactly like the official cards.
• Boundary: only pricing (the optional USD cost table) stays with /router config and the profile patch; the model chains — both tiers and the Judge's — are editable in the card.
• Build: npm run build emits both the host artifact (dist/index.js) and the client bundle (dist/client.js). The client module is discovered through the dsh.client manifest by dsh-client-modules, which requires the plugin to be mounted by package name (dsh-shift-router) — a source-checkout patch (name: '/path/dist/index.js') does not serve the card.

Legacy harnesses only: the Web settings whitelist (≤ 0.1.0-rc.x)

Harness builds up to 0.1.0-rc.x filtered a third-party settings namespace out of the browser's settings.describe response unless it appeared in WEB_SETTINGS_NAMESPACES — which is why scripts/expose-gui-settings.mjs exists: it patches the profile's installed dsh-host-apiproxy (idempotent; re-run after a dependency upgrade). From 0.1.5-rc.2, this project's baseline, that package and its whitelist are gone and the namespace is exposed natively, so the script reports "not needed" and exits 0. It is not part of the published package (files), so it is only reachable from a source checkout.

Commands

How it works (DSH integration)

The mechanism-by-mechanism mapping is normative and lives in SPEC.md §1.1. Two things are worth stating here because they are not in that table:

• Throughput is deliberately absent. DSH renders tok/s natively (chat footer, trajectory panel) from decode time; the router owns routing decisions and spend, not rate display.
• Subagents are never routed. Workers spawned by the subagent tool carry session.header.origin === 'subagent' and keep their pinned model; the router drives top-level agent turns only.

Task-level orchestration

Turn-level routing decides which model runs a turn; task-level orchestration decides how a complex task is executed. When the Judge says smart and orchestration.mode is auto (the default), the router hands the turn to the Smart tier as a CTO: it plans, delegates implementation to Fast workers through the harness's subagent tool, reviews each result and iterates — then an independent acceptance audit checks the claim. A fast verdict never triggers any of this.

How an orchestrated turn runs

1. Enter — the decision tier is Smart, the subagent tool is present and the mode is auto; the orchestrator instruction is injected as a system-prompt section (SPEC §7.2).
2. Delegate — the CTO calls subagent; each call is one round, counted at dispatch (a dispatched delegation has already spent budget, so this keeps maxRounds a true ceiling).
3. Review and iterate — a failed worker advances the failure streak, and the convergence protocol requires every re-delegation to carry a structured ## Failure report (what failed, where, which acceptance test re-checks it); repeating the same feedback triggers takeover (SPEC §7.2.1).
4. Stop — at the cap the subagent tool is denied at tools/pre-execute and the prompt section becomes a wrap-up notice; agent/turn-stopping releases the state. Orchestration is single-turn: nothing spans turns, and a leaked run is swep