Preface

When running long tasks in DeepSeek Harness (DSH), two common types of interruptions occur: one is the failure of the current model request, which halts the task directly; the other is when a task that can be split into multiple independent sub-steps is still executed sequentially within a single session, leading to long processing times and difficulty in tracking intermediate results.

The community plugin dsh-ha-orchestrator (GitHub: Saktawdi/dsh-ha-orchestrator) addresses these two issues with a combined approach: it automatically retries with a fallback chain when the model encounters errors and uses the orchestrate tool to delegate work that is suitable for parallel execution, staged processing, or requires review to sub-agents. Below, we introduce its positioning, capabilities, and installation usage.

What is This

dsh-ha-orchestrator is a Cordis dynamic plugin for DSH, maintained by Saktawdi. The current release version is v0.12.2, licensed under MIT, with 9 GitHub stars, and categorized as Workflow in the community directory.

In one sentence: it provides high-availability model fallback for long tasks in DSH and offers an orchestrate orchestration tool that supports five sub-agent orchestration modes: fanout, pipeline, supervisor, map-reduce, and router. The configuration interface and prompt text support both Chinese and English, following DSH’s language settings.

Automatic Model Failure Fallback

When a model request fails, the plugin switches to the next backup model for retry, rotating through backup models in sequence. The failed model enters a cooldown period and resumes use after the cooldown ends. The mechanism also includes:

  • Burst window failure counting
  • Provider-level circuit breaking and recovery probing
  • Optional context length degradation
  • Retry limits for each failure, stopping after exhaustion to avoid infinite loops

If a model error causes a task interruption, the plugin will restart the task once. Backup models, cooldown times, failure thresholds, error code filters, and other settings can be adjusted in Settings → “HA & Orchestration” → “Model High Availability”.

HA runtime state is persisted to dsh-ha-orchestrator.ha.json with a 500ms debounce and automatically recovers after restart. You can view isolation, failure counts, rotation cursors, and switch history via /ha and /ha status; /ha probe <provider> <model> can manually test if a specific model has recovered.

Orchestration Tool: orchestrate

The orchestrate tool is available in all sessions. The tool description and system prompts guide the model to call it automatically when tasks can be parallelized, staged, or require review; if it doesn’t trigger automatically, you can directly say “use orchestrate.”

The five orchestration modes are as follows:

Mode Function
fanout Splits into sub-tasks for parallel execution, then aggregates results
pipeline Executes stages sequentially, with the output of one stage as the input to the next
supervisor Executes sub-tasks in parallel, then a supervisor sub-agent reviews and merges results
map-reduce Executes map tasks in parallel, then a reducer sub-agent merges results
router Delegates candidate tasks to a router sub-agent, which selects or arranges subsequent work

The tool also supports: saving recipes, resuming interrupted tasks by runId (/ha-orch-resume <runId>), supervisor review rounds, multiple reviewers, single sub-agent call budgets, structured output schemas, and custom sub-agent tool whitelists/blacklists. Sub-agents are by default not allowed to initiate nested orchestration.

Orchestration run records are written to dsh-ha-orchestrator.runs.jsonl, and dsh-ha-orchestrator.run-<runId>.md is generated to store complete sub-task outputs. Orchestrate run cards (progress, sub-task status, models actually used by each sub-agent) are displayed in the conversation flow; the tool area has an HA status capsule.

Custom Sub-agents

In the configuration page “Custom Sub-agents”, you can define reusable roles: name, provider/model, model effort, description, system prompt, and optional tool whitelists/blacklists. Each role can have its own fallbacks model chain (format: provider/model@effort) configured to execute in sequence; on startup failure or model errors, only that role’s own fallback chain is switched, not reading the global HA backup models. Built-in roles include reviewer, researcher, and research-merger; “Smart Add” allows the current model to generate complete definitions with a single sentence.

Automatic Trigger and Manual Control

If the session uses minimal / minimal-v3 or other complete: true persona presets, the platform discards the plugin-injected system prompt paragraphs, and automatic triggering relies primarily on the orchestrate tool description. If it still doesn’t trigger, please directly say “use orchestrate.”

When you don’t want the model to call automatically, you can disable Context Injection in Settings → “HA & Orchestration” → “System”, then manually trigger by writing “Use the dsh-ha-orchestrator plugin for orchestration” in the prompt. Sub-agents by default do not receive this context injection; if you need to inject it synchronously, you can enable Inject into Sub-agents in the “System” card.

Installation and Enabling

Prerequisites: DeepSeek Harness (web profile). The release package requires no local build; runtime peer services are provided by DSH. Node engine requires >=20.19.0.

This package is published on npm with the name dsh-ha-orchestrator:

dsh plugin --profile web add dsh-ha-orchestrator

Because this package declares dsh.bundle.patch, dsh plugin add will automatically add dsh-ha-orchestrator to dsh.profile.bundles and apply cordis.patch.yml, without needing to manually write combination lines. The bundle patch layer supports Cordis HMR hot reloading, no need to restart the DSH process; refresh the browser page to see the configuration page.

Method 2: Local Repository (For Development)

Requires pnpm in the PATH:

dsh plugin --profile web add "file:<absolute path to this repository>"

Method 3: Manual Installation (No pnpm Required)

  1. Copy the repository to ~/.dsh/profiles/web/node_modules/dsh-ha-orchestrator
  2. Add to ~/.dsh/profiles/web/cordis.patch.yml:
- insert:
    - id: dsh-ha-orchestrator
      name: dsh-ha-orchestrator

After completing the above steps, refresh the browser to see the configuration page in Settings → “HA & Orchestration”.

Typical Usage

Daily use requires no special instructions; the model will automatically choose orchestration modes based on task structure. Examples from the README:

Parallel Research (fanout)

You:    Research these three open-source projects, compare licenses and community activity, and provide selection recommendations.
Model:  Identifies 3 independent sub-tasks → Automatically calls orchestrate (fanout) → Parallel research → Aggregates comparison → Provides recommendations

Large Codebase Reading (fanout)

You:    Read this large project, summarize the overall architecture and current progress.
Model:  Splits into multiple independent reading sub-tasks by module/documentation/code → Automatically calls orchestrate (fanout) → Parallel reading → Aggregates architecture and progress

Staged Planning (pipeline)

You:    First do requirements analysis, then write design documents, and finally write an implementation plan.
Model:  Automatically calls orchestrate (pipeline) → Each stage's output automatically becomes the next stage's input

Supervised Review (supervisor)

You:    Generate a competitive analysis report and have an experienced reviewer check it.
Model:  Automatically calls orchestrate (supervisor) → Parallel analysis → Reviewer merges → Outputs report

To view run status, use slash commands: /orchestrate runs lists the latest 24 orchestration runs, /orchestrate show <runId> views details, and /orchestrate presets lists configured orchestration recipes.

Applicable Scenarios and Notes

Best suited for: In-depth research, large codebase reading, batch review, multi-option comparison, and implementation plan orchestration.

The plugin runs with the current DSH process permissions. Before installation, you should read the source code and the MIT license, confirming trust in the maintainer and code behavior. Configuration and HA state are located based on the session workspace / DSH_HOME → sandbox workspace-write writable root; run records and Markdown artifacts may contain task prompts and model outputs, so ensure the workspace is readable only to trusted users/processes.

If the deployment environment lacks DSH’s commands service, the plugin’s core functionality remains available, but slash commands like /ha and /orchestrate are unavailable. The repository documentation also includes architecture, configuration reference, security notes, and compatibility matrix; the test matrix shows 219 passes (source: README badge).

Conclusion

dsh-ha-orchestrator combines model failure recovery and five sub-agent orchestration modes in a single DSH plugin: long tasks no longer terminate easily due to a single model error, and complex work can be advanced in parallel with recoverable runIds and run records.