Introduction¶

The core philosophy of DeepSeek Harness (DSH) is “everything is a plugin.” When developing multi-agent systems or handling complex tasks, a single model (typically DeepSeek R1) may not be able to efficiently process all subtasks. Introducing third-party models (such as GLM, Kimi, and Qwen) can help distribute the workload, but manually managing the invocation chain is relatively expensive.

The dsh-multi-model-orchestrator plugin solves this problem. It turns the main model into a “master brain” that breaks down complex tasks and dispatches subtasks to the most suitable model for execution based on the characteristics of each submodel (such as reasoning capability, speed, and cost).

Plugin Overview¶

This is a DeepSeek Harness (dsh) plugin maintained by user Bazley13 and licensed under the MIT License. Its core function is to upgrade the main AI model into a multi-model orchestration center, enabling model-aware task dispatch and per-model Token usage statistics through system prompt injection and tool calls.

Installation¶

Installing this plugin requires adding it to the designated DSH configuration file. The web profile is commonly used.

dsh plugin --profile web add dsh-multi-model-orchestrator

After installation, restart Harness or reload the configuration file. The plugin is loaded as a configuration layer through cordis.patch.yml.

Core Features¶

This plugin mainly provides the following capabilities:

Multi-model orchestration guidance: The plugin injects system prompts into the main model, guiding it on how to decompose tasks. It prompts the main model to use the subagent tool and explicitly specify the provider and model parameters.
Model-aware scheduling: You can define strengths and weaknesses for each route. The main model reads these notes and selects appropriate models based on task difficulty (for example, using a strong reasoning model for complex logic and fast/low-cost models for high-throughput work).
Per-model Token statistics: It provides a model_token_usage tool to report the input, output, cache read/write Tokens, and request count for each provider/model combination within the current process.

Configuration and Usage¶

To enable these features, you need to configure $DSH_HOME/settings.yaml (the default path is ~/.dsh/settings.yaml).

1. Add Third-party Model Routes¶

First, you need to configure routes for third-party models. Presets for GLM, Kimi, Qwen, and others can be directly referenced from the example files. Each route only requires configuring apiKeyEnv.

llm-pi-ai.providers:
  - api: openai-completions
    baseURL: https://open.bigmodel.cn/api/paas/v4
    apiKeyEnv: GLM_API_KEY
    models: ["glm-4.6"]

2. Enable Subagent Model Selection¶

Allow the main model to select models when dispatching subtasks. You need to set enabled: true and list the allowed models in allowedModels.

subagent-model-selection:
  enabled: true
  allowedModels:
    - { provider: glm, model: glm-4.6 }
    # 可以添加更多路由，如 kimi, qwen 等

3. Add Model Notes¶

Provide the main model with context about model capabilities to help it make scheduling decisions.

multi-model-orchestrator:
  modelNotes:
    glm/glm-4.6:
      description: Zhipu flagship, strong reasoning.
      strengths: complex reasoning, coding, agentic tool use
      weaknesses: slower and pricier

4. Execute Tasks¶

After restarting Harness, directly propose complex tasks in the main conversation, for example: “Break this task into parallel subtasks and dispatch them to the most suitable models.”

The main model will automatically track subtasks, call list_subagent_models to view available routes, and dispatch tasks through the subagent tool.

Notes¶

When using this plugin, there are several important details to keep in mind:

Token statistics mechanism: The data returned by model_token_usage is accumulated per process, and is cleared every time Harness restarts. If the query returns empty results, ensure that at least one model call returned a usage data block.
Global scope of orchestration prompts: Orchestration guidance is injected globally, so subagents also read these prompts. The prompt wording is designed to prevent subagents from falling into a loop of recursively decomposing their single task.
Route type: Third-party routes are registered by default as non-reasoning models. If you need to use reasoning models (such as GLM-5.3), you may need to add reasoningEfforts or compat.thinkingFormat for specific routes on the “Models” page of the web interface.
Reasoning model compatibility: Some reasoning models (for example, the GLM-5.3 series) refuse to be invoked when the reasoning_effort parameter is not explicitly specified. If dispatch fails, try explicitly specifying the reasoning level in the configuration (such as low).
Credential check: If a route has an API Key configured but the environment variable or credentials file does not provide it, the request will throw a MISSING_CREDENTIAL error at runtime.
Module loading error: If you encounter ERR_MODULE_NOT_FOUND: Cannot find package '@deepseek-ai/...', it is usually because the plugin was manually linked (raw link: + manually created node_modules) instead of installed through dsh plugin. Please install it using the standard command.

Summary¶

dsh-multi-model-orchestrator provides DSH users with a standardized way to leverage multiple models. By configuring settings.yaml, you can turn the main model into an intelligent scheduling center, enabling automatic task decomposition and on-demand dispatch while monitoring Token consumption per model.

For more details and source code, please visit GitHub.

dsh-multi-model-orchestrator: Turn the Main Model into a Multi-Model Scheduler