dsh-deepseek-model-router
No description
- Stars
- 0
- Language
- JavaScript
- Created
- Aug 24, 2026
- Updated
- Aug 24, 2026
Introduction
dsh-deepseek-model-router
Auto-switch DeepSeek models for DeepSeek Harness. No manual model picking: every model request is routed automatically, and a switch_model tool gives you a manual override when you want one.
How it works
Before every model request, the plugin inspects the conversation and replaces the frozen provider/model:
| Situation | Model used (defaults) |
|---|---|
| Conversation contains images | deepseek-v4-flash-vision-exp (vision) |
| Complex task — long text, code, math, analysis keywords (score ≥ threshold) | deepseek-v4-pro |
| Everything else — chat, short questions, routine work | deepseek-v4-flash |
It hooks the same agent/request waterfall the built-in model selection uses, installed after it, so the routed model is the final one for the call. The prompt variables (provider/model) stay in sync with what actually runs.
Manual override tool
switch_model(mode, reason?) — mode is one of:
auto— back to automatic routingfast— forcedeepseek-v4-flashpro— forcedeepseek-v4-provision— forcedeepseek-v4-flash-vision-exp
The override is per-session and takes effect from the next request.
Install
From the plugin market (once published), or locally:
dsh plugin --profile web add dsh-deepseek-model-router
The bundle patch activates the router for the whole profile after a restart. Configuration lives in the bundle patch (cordis.patch.yml → row config): provider, fast/pro/vision models, complexity threshold, tool name, enabled.
Configuration
All fields optional (defaults shown):
config:
provider: deepseek-official # only sessions on this provider are routed
fastModel: deepseek-v4-flash
proModel: deepseek-v4-pro
visionModel: deepseek-v4-flash-vision-exp
complexityThreshold: 2 # task score >= threshold -> pro
toolName: switch_model # registered tool name
enabled: true
Notes
- Only
deepseek-officialsessions are routed; other providers pass through untouched. - If images are present, the router always prefers an image-capable model (
visionModel); if that model is not image-capable in your catalog, the current model is kept. - The composer's model seat still shows the session's default selection; the actual model used per call is decided by the router and recorded in the session's request header. Use
switch_modelto pin a model explicitly.
License
MIT