dsh-multi-model-orchestrator
Manifest valid★ 3Multi-model orchestrator: the main brain decomposes complex tasks and dispatches subtasks to GLM / Kimi / Qwen sub-agents by each model's strengths, with per-model token usage.
dsh-multi-model-orchestrator
A DeepSeek Harness (dsh) plugin that turns your primary AI into a multi-model "main brain". When a task is complex, it decomposes the task into subtasks and dispatches each to the sub-agent model best suited for it (GLM / Kimi / Qwen / any OpenAI-compatible route you configure), while tracking per-model token usage.
Features
- Multi-model orchestration guidance — a system-prompt section coaches the main brain to decompose complex tasks, inspect available routes with
list_subagent_models, and dispatch each subtask viasubagentwith an explicitprovider/model. - Model-aware dispatch — you describe each route's strengths/weaknesses once (see config); the main brain assigns work accordingly (strong models for hard reasoning, fast/cheap ones for high-volume work).
- Per-model token usage — a
model_token_usagetool reports input / output / cache read / cache write tokens and request counts perprovider/model, accumulated since the process started.
The plugin does not touch any harness internals. All model routes and the sub-agent allow-list are ordinary harness settings — see examples/settings.yaml.
Install
Install into a dsh profile (usually web):
dsh plugin --profile web add dsh-multi-model-orchestrator
or, from a git checkout:
dsh plugin --profile web add github:YOU/dsh-multi-model-orchestrator
Restart the harness (or reload the profile) afterwards. The plugin loads itself as a profile layer via its cordis.patch.yml.
Quick start
-
Add your third-party model routes to
$DSH_HOME/settings.yaml(default~/.dsh/settings.yaml). GLM / Kimi / Qwen presets ready to paste: see examples/settings.yaml. Each route needs only an API key behindapiKeyEnv(env var,$DSH_HOME/.credentials.yaml, or the web Models page). -
Enable sub-agent model selection so the main brain can pick the model for each child:
subagent-model-selection: enabled: true allowedModels: - { provider: glm, model: glm-4.6 } # ... your other routes -
(Optional) Add model notes the main brain reads when assigning work:
multi-model-orchestrator: modelNotes: glm/glm-4.6: description: Zhipu flagship, strong reasoning. strengths: complex reasoning, coding, agentic tool use weaknesses: slower and pricier -
Restart the harness and ask, e.g.:
Break this into parallel subtasks and dispatch each to the best model.
Credentials
Keys are resolved per request through each route's apiKeyEnv. Provide them any of these ways:
- Environment variables:
GLM_API_KEY/KIMI_API_KEY/DASHSCOPE_API_KEY(per your route names). - Credential store
$DSH_HOME/.credentials.yaml:GLM_API_KEY: sk-xxxx KIMI_API_KEY: sk-xxxx DASHSCOPE_API_KEY: sk-xxxx - Web "Models" page: paste the key directly (stored in the managed credential document).
Routes without a key fail at request time with MISSING_CREDENTIAL and do not affect configured ones.
How the main brain works
Ask for a complex task in the main conversation. The main brain will:
- use
todo_writeto record the decomposed subtasks; - call
list_subagent_modelsto see available routes; - dispatch each subtask through
subagent(withprovider/model) to the best-fit model — launching independent delegations in one message, running them in the background by default; - gather results and synthesize the final deliverable.
Route names are whatever your profile actually registers — the GLM / Kimi / Qwen names in the examples are illustrative. If you registered routes under other providers (e.g. a
zaigateway), reference those exactprovider/modelids insubagent-model-selectionandmodelNotes. Asklist_subagent_modelsfor the live list.
To see usage, ask the main brain to call model_token_usage (or just ask "how many tokens has each model used?").
Configuration reference
Everything is configured in $DSH_HOME/settings.yaml:
| Section | Purpose |
|---|---|
llm-pi-ai.providers | OpenAI-compatible third-party model routes (any vendor). |
subagent-model-selection | Allow-list of {provider, model} the sub-agent tool may dispatch to. |
multi-model-orchestrator.modelNotes | Per-route strengths/weaknesses that guide assignment. |
To add your own vendor, extend llm-pi-ai.providers with { api, baseURL, apiKeyEnv, models } (any OpenAI-compatible api: openai-completions gateway works), then add matching entries to subagent-model-selection.allowedModels and multi-model-orchestrator.modelNotes.
Notes & limitations
- Token usage is per-process (cleared when the harness restarts); per-session usage still shows in the built-in token meter.
model_token_usageneeds at least one model call that returned ausagechunk before it reports anything.- The orchestration guidance is injected globally, so sub-agents read it too; its wording keeps sub-agents from recursively re-decomposing their single focused subtask.
- Third-party routes are registered as non-reasoning models by default; reasoning flags (
reasoningEfforts/compat.thinkingFormat) can be added per model on the web Models page. - Some reasoning models reject a call without an explicit reasoning tier. Zhipu's GLM-5.3 line, for example, fails with default parameters and only responds when the sub-agent is dispatched with an explicit
reasoning_effort(e.g.low). If a dispatched child errors on a model you expect to work, add an explicitreasoning_effortto the dispatch. A route that returns no tokens despite requests succeeding at the API level is usually a provider-side issue, not an orchestrator bug.
Troubleshooting
ERR_MODULE_NOT_FOUND: Cannot find package '@deepseek-ai/...'— the plugin was linked manually (rawlink:+ a hand-madenode_modulesjunction) instead of installed throughdsh plugin ... add. Install it as a real dependency of the profile and remove the junction.model_token_usagereturns "No records yet" — no model call has completed with usage since load; make a request and ask again.- Children cannot be dispatched to a route /
list_subagent_modelsis empty — check thatsubagent-model-selectionisenabled: truewith a non-emptyallowedModels, and that the routes exist underllm-pi-ai.providers.
License
MIT
Compatibility
Versions
| Latest version | Published | Size |
|---|---|---|
| 0.2.0 | — | — |
| 0.2.1 | — | — |
| 0.2.2 | — | — |
Comments
Loading…
Similar plugins
by jiruidai
A model-native meta-agent plugin for DeepSeek Harness that uses the underlying model’s reasoning and planning capabilities to synthesize task-specific workflows at runtime and coordinate tools and sub
★ 7
↓ 85/wk
MIT
TypeScript
Aug 14, 2026
dsh plugin --profile web add dsh-meta-orchestratorby zibo2025
【编排模式】为 DeepSeek Harness 提供多智能体编排模式:主智能体分解分派、worker 全网格互通,支持逐 worker 指定模型与思考强度
★ 8
MIT
TypeScript
Sep 1, 2026
dsh plugin --profile web add dsh-orchestratorby Hu9956
切换供应商、模型与思考强度,每个模型各自记住档位。
★ 1
MIT
JavaScript
Oct 28, 2026
dsh plugin --profile web add @kewen/dsh-model-controlsAutomatically orchestrates complex DeepSeek Harness requests. It detects when delegation is useful, builds a dependency-aware plan, assigns bounded researcher, architect, backend, frontend, tester, an
★ 0
dsh plugin --profile web add dsh-task-orchestratorDeepSeek Harness plugin: on task send, pick a different model for subagents and an independent reviewer that validates each subagent's work before it reaches the main agent
★ 0
MIT
TypeScript
dsh plugin --profile web add dsh-orquestratorLong-task orchestration loop: Codex plans/scores/reviews, DeepSeek executes, Kimi supplements (vision acceptance, summarization, cross-check).
★ 0
dsh plugin --profile web add dsh-longtask-orchestrator