DeepSeek Harness Plugin: Bundles and When You Don't Need One

DeepSeek Harness plugins: ask whether you need one before you pick one

Almost every article about the DeepSeek Harness plugin ecosystem starts with a list of plugins you should install. This one starts earlier, with a question none of those lists ask: do you need a plugin at all?

DeepSeek Harness (dsh) is built on an everything-is-a-plugin architecture, and its own documentation says the fastest way to change what it can do is often not to install a plugin. The official Modellix integration page puts it in one sentence:

Modellix needs no plugin—only configuration. — Modellix DeepSeek Harness docs

That sentence is the dividing line this article is organized around. There are two ways to change what your harness can do: pure configuration (point the existing model adapter at a different endpoint) and plugins (install a bundle that adds capabilities configuration cannot express). This article explains what a DeepSeek Harness plugin actually is mechanically — bundles, manifests, patch files, and profile entries — then walks through what each path buys you, using the Modellix plugin for DeepSeek Harness as the worked example.

The installation commands themselves (dsh plugin add, verify, remove) belong to a separate article; here the focus is the mechanism and the decision. If you came here wanting the custom-provider setup walkthrough, the DeepSeek Harness custom model guide is the “swap the model source” half of this pair, and this page is the “plugin mechanism and whether you need it” half.

One disclosure up front: Modellix runs the plugin and the gateway used in the examples below, so we have a commercial interest in both working for you. The technical claims come from the official DeepSeek Harness repository and documentation, and the numbers are dated September 1, 2026.

What a DeepSeek Harness plugin actually is

DeepSeek Harness describes itself with the tagline “Everything is a Plugin”: models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and even the UI are swappable components. The harness runs on the Cordis microkernel, which manages plugin mounting, unmounting, and dependencies. That is the architecture in one line — but “plugin” covers two different shapes, and confusing them causes most of the ecosystem’s confusion:

• A plugin is a TypeScript module that exports an apply(ctx) function and registers capabilities. That is the complete definition: export function apply(ctx) { /* register capabilities here */ }, optionally declaring dependencies with inject.
• A bundle is the distributable package that carries one or more plugins into a profile. A bundle is an npm package whose package.json contains a dsh field marking it as installable:

{
  "name": "dsh-hello-plugin",
  "version": "0.1.0",
  "main": "index.js",
  "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }
}

The dsh.bundle.patch field points at a cordis.patch.yml — a YAML array that references plugins by package name, not by file path:

- insert:
    - id: hello
      name: dsh-hello-plugin

When you install a bundle with dsh plugin --profile web add <package>, the harness does two things: it adds the package to the profile’s package.json, and it appends the bundle to the profile’s dsh.profile.bundles list in installation order, starting with the built-in @deepseek-ai/dsh-base. Profiles are ordered stacks of these bundle layers — the web, headless, sdk, sdk-minimal, and acp profiles initialize automatically from built-in templates; any other profile is created through the plugin command. Configuration layers stack on top of each other (each bundle’s patch, then the profile’s cordis.patch.yml, then the home-level patch, then command-line overlays), with later layers overriding earlier rows by id.

Two details matter when you read plugin documentation:

• Bundles can have host-side and client-side entries. A simple plugin registers backend capabilities. A bundle that changes the Web UI ships a client entry too — the dsh.client field lists which client packages it injects. If a plugin’s README talks about UI changes, it almost certainly ships both sides; a bare apply() module does not.
• Verification is a command, not a feeling. The official acceptance check is dsh --profile web --dump-config, which prints the composed configuration tree without booting it. If you do not see the bundle layer and the plugin row you installed, the plugin is not active — reloading the browser alone does not load a new client bundle.

A bundle is an npm package with a dsh manifest and a cordis.patch.yml; the profile’s bundles list decides what a profile actually loads, on both host and client sides.

One more fact to keep in your head before you go hunting: DeepSeek Harness is in developer preview. The repository README says it is “iterating rapidly” and that there will be compatibility-breaking changes. Any plugin you install today is pinned to prerelease interfaces, so a plugin’s version compatibility is part of its evaluation — not an afterthought.

The ecosystem you are searching is large and young at the same time. The only first-party number worth citing: the GitHub dsh-plugin topic contains 12,409 repositories as of August 29, 2026 — and that count mixes in plenty of projects that are not plugins at all. Every other “plugin count” you will see (a catalog claiming 316 plugins, a directory claiming 11,000+) is a third-party number with no verifiable source. Treat them as marketing.

What pure configuration already gives you

Before evaluating a single plugin, know what your harness can already do with configuration alone. DeepSeek Harness’s model adapter (llm-pi-ai) accepts a custom provider for any OpenAI-compatible endpoint, and the official providers guide documents the mechanism generically. Four values define a model source:

Value	Example for Modellix
Provider ID	modellix
Base URL	https://llm.modellix.ai/v1
API protocol	openai-completions
Model IDs	openai/gpt-5.5, deepseek/deepseek-v4-flash, …

Enter those in the Web UI form or in $DSH_HOME/settings.yaml, and the harness talks to the new source on the next request — no restart, no bundle, no plugin. The Modellix LLM gateway serves the OpenAI-compatible GET /v1/models endpoint, so “Fetch available models” lists the current catalog automatically, and you can pick models by hand or by fetch. As of September 1, 2026, that catalog is 28 language models across 9 provider labels — Anthropic, DeepSeek, Google, Moonshot, OpenAI, Qwen, xAI, ZAI, and Modellix’s own — with the live list and per-million-token pricing on the Modellix LLM page. You can also choose the wire protocol: openai-completions for Chat Completions, or anthropic-messages if you prefer the Anthropic protocol (with the base URL change that protocol requires).

This is the path the official docs are pointing at: “Modellix needs no plugin—only configuration.” If your goal is a different model source — which is the most common reason people go looking for a “deepseek harness plugin” in the first place — you are already done after the form. The step-by-step walkthrough for this path, including the settings.yaml variant and the four traps that cause “model won’t connect,” is in the DeepSeek Harness custom model article linked in the opening section. One boundary note from that same documentation: the Modellix LLM gateway is a text gateway — use text-only prompts and do not attach images to model calls.

What a plugin adds that configuration cannot

Configuration can only point existing seams at new providers. A plugin can add new seams. That is the real difference, and it is why “plugin vs custom provider” is the wrong way to frame the choice: they are not competing solutions for the same job, they are different layers. The Modellix plugin for DeepSeek Harness (dsh-modellix) is a clean worked example because it packages exactly the three things configuration cannot do:

One key, two paths: pure configuration covers model sources; a plugin adds Design, Web, and live-catalog capabilities that configuration cannot express.

Capability	What you experience	What actually happens
Design	A media workspace in the harness: pick an image/video/audio model, enter a prompt, adjust parameters, review results	Reads the live media catalog and each model’s public schema; a billed generation is submitted exactly once
LLM	Modellix models appear in the harness model selector and stay current	Merges the live catalog into the llm-pi-ai Modellix provider continuously — new models show up without editing config
Web	The native web_search and web_fetch tools just work against Modellix	Registers Modellix search/fetch providers behind the existing tool names; no duplicate custom tools

Three of those behaviors deserve emphasis because they are invisible until you need them:

• The LLM module is a live catalog, not a snapshot. The pure-configuration path gives you one GET /v1/models fetch at setup time; the plugin keeps merging the current catalog into the model selector, with a settings panel that shows catalog health, model count, and last refresh time, plus a manual refresh. When Modellix adds a model, it appears in the selector without you touching config.
• The Web module takes over the native tools. web_search and web_fetch are harness-native tool names; the plugin’s patch sets the search and fetch providers to Modellix (60-second timeouts) without creating a second set of tools. This matters because a harness only shows one Web UI for search/fetch — a plugin that reuses the native seam integrates cleanly, one that builds its own tool does not.
• The Design module does not guess. Parameter fields come from each model’s live api_schema; a complex schema with a blocking unsupported constraint disables submission instead of guessing. The plugin’s “adjust by chat” assistant proposes a reviewable diff and never starts a media generation by itself — only the explicit “Confirm and generate” action issues the billed request, and that request is never retried automatically.

All three modules share one Modellix API key, and all three default to on with independent switches — you can enable only Design, only LLM, or only Web. The media generation runs on the async media API (a different host from the text gateway, with task IDs and polling), which is how the harness gets image, video, and audio output at all: every model on the Modellix text gateway outputs text only, so generation inside the harness is plugin territory.

A worked example: the Modellix bundle

The Modellix plugin for DeepSeek Harness — npm package dsh-modellix, source at Modellix/dsh-modellix, Apache-2.0 — installs into the web profile and is a good reference for what a well-built bundle looks like, and for what a young plugin honestly looks like.

The Modellix bundle wires three modules to one key: Design for media generation, LLM for the live model catalog, Web for native search and fetch.

Requirements are pinned, which is exactly what prerelease interfaces demand: DeepSeek Harness 0.1.1-rc.2 (not “latest”), and Node.js ^22.19.0 || >=24.0.0 for the published package. The README opens with the warning that applies to every bundle in this ecosystem: “Harness and this plugin currently use prerelease interfaces. Before upgrading Harness, check this package’s peer dependencies and CHANGELOG.”

Keys follow the two-source pattern: enter the key in the first-run dialog (the harness stores it write-only — after saving, the browser never displays it again, only a redacted descriptor), or provide MODELLIX_API_KEY in the harness launch environment (in which case the UI shows it as read-only and you restart the harness after changing it). The plugin does not read a modellix-cli login; the CLI keychain and the harness credential store are separate.

Two behaviors in the plugin are worth calling out because they are billing guardrails, not features:

• The billed media POST is submitted once and never auto-retried. If a submission disconnects with an unknown outcome, Design shows “Submission outcome unknown” and asks you to check results before resubmitting — a deliberate design to prevent duplicate charges.
• The LLM module sets provider retries to 0 (avoid repeating model calls at the plugin layer) and never fabricates a static model list when the catalog is unavailable. If the catalog is down, the model picker is empty rather than stale.

The engineering behind it is verifiable in the repository: a ten-step release gate (verify:env → typecheck → lint → test → build → verify:pack → verify:fresh-install → verify:node22-install → verify:release:static → verify:release). Two steps are unusual for a plugin this size: verify:pack actually decodes the twelve locale-specific WebP screenshots to confirm they are metadata-free, and verify:node22-install fails instead of silently skipping when no Node 22 binary is found. Documentation is bilingual (English and Chinese), and the client UI targets 320px viewports, 200% text zoom, forced colors, 48px pointer targets, and reduced motion.

Honesty about adoption: this is a very new plugin. Modellix/dsh-modellix was created on August 24, 2026; as of August 29, 2026, it has 1 star, 0 forks, 0 open issues, and no GitHub releases, with 27 commits concentrated in three days by a single committer, and two same-day npm versions (0.1.0, 0.1.1). Nothing here should be read as community adoption — there is none to point at yet. The same design space already has projects with hundreds of thousands of stars (the open-source open-design plugin for image generation sits at roughly 92,000), so judge the Modellix plugin on the engineering evidence above and your own --dump-config, not on its star count. If you prefer a deeper product walkthrough, the Modellix DeepSeek Harness plugin article covers the bundle’s modules and first-run flow in detail.

How to evaluate any dsh plugin before installing

The deepseek harness plugin GitHub search will return thousands of repositories, and every third-party directory claims to have already ranked them for you. None of that substitutes for a five-minute check. The checklist below applies to any bundle, including the one in the previous section:

1. Check the version contract. Prerelease interfaces mean the plugin’s peer dependencies are its compatibility statement. Does it pin a specific dsh version, and does that match the harness you run? The 0.1.1-rc.2 requirement above is the norm, not a quirk.
2. Read the README’s warning section. A plugin that documents its prerelease status, its credentials model, and its billing behavior is telling you it has thought about failure. A README that only lists features is not.
3. Look at the repository, not the star count. Activity is a better signal than stars on a two-week-old ecosystem: commit recency, issue responses, and a release or tag history. A 92,000-star project and a 1-star project can both be the right or wrong choice for your setup — stars measure attention, not compatibility.
4. Ask what permissions it needs. Browser-control plugins can inherit authenticated sessions; workflow plugins can repeat actions; UI bundles pull in many packages for one feature. The harness’s own sandbox has known sharp edges — a plugin that needs workspace-write or broader deserves extra scrutiny.
5. Verify after install. Run dsh --profile web --dump-config and confirm the bundle layer and plugin row are present. “Installed but not active” is the most common failure state in this ecosystem, and it is invisible until you check.
6. Install one plugin per problem. Every bundle adds code, dependencies, and a surface that needs updating when the harness changes. The goal is not the longest plugin list; it is an environment where every extension has a job you can explain.

Also worth stating plainly: there is no official plugin marketplace. DeepSeek has not shipped one; the community has been asking for it. Every “plugin store” or “plugin market” you find (dshbase, dshfind, the various awesome-dsh-plugin lists, category catalogs) is third-party. That does not make them useless — the curated lists are the best discovery surface the ecosystem has — but “listed on a directory” is a discovery signal, not a quality or security signal.

Plugin or not: the decision in one table

Put the two paths side by side and the choice stops being about “plugins vs configuration” and becomes “what are you trying to change?”

Your need	Path	What it costs
Use different LLM models in the harness	Pure configuration (custom provider)	Four form fields, no restart
Keep the model list current as a catalog changes	Plugin (LLM module) or periodic manual refresh	A bundle install + one key
Generate image/video/audio inside the harness	Plugin (Design module)	A bundle install + one key + billed media usage
Search and fetch the web through Modellix	Plugin (Web module)	A bundle install + one key
Anything else a harness seam can express	Plugin, but only the one that covers that seam	Varies; evaluate per the checklist

When you do not need a plugin: you only want a different model source; you want the smallest possible surface on a prerelease harness (fewer bundles = fewer things to break when interfaces change); or you are still evaluating the harness and want to minimize variables. Pure configuration is the honest answer in all three cases — and it is also the recommended first step before any plugin, because a working baseline makes a broken plugin much easier to diagnose.

When you do need a plugin: the capability genuinely does not exist in configuration — media generation inside the harness, native web tools backed by a specific provider, a live model catalog in the picker, or any of the hundreds of capability plugins (vision bridges, browser control, workflows, UI skins, memory) the ecosystem is producing. That is the point where “best deepseek harness plugins” becomes a real question, and the answer is the one that covers the missing seam you identified — not the highest-starred one.

If this is your first time touching the harness, the DeepSeek Harness overview is the whole-product context for this subsystem: what the harness is, how to run it, and where its models come from. For the config path’s execution details, the custom model article linked above has the form and the settings.yaml side by side. The install/verify/remove command flow for bundles is covered in the companion dsh plugin add article, and the Design and Web modules each get their own deep dive in the image generation and web search articles. The short version: understand the mechanism, start with configuration, add exactly one plugin for exactly one missing capability, and verify with --dump-config.

DeepSeek Harness Integration Docs

Read the official Modellix × DeepSeek Harness configuration reference — the custom provider fields, the settings.yaml block, and the troubleshooting table behind the 'no plugin—only configuration' sentence.

View Docs

Open the Modellix Console

Log in to generate your Modellix API key and check live per-model pricing for the 28-model LLM catalog.

Login

---

Facts verified against the official DeepSeek Harness repository and documentation, the Modellix DeepSeek Harness docs, and the dsh-modellix repository on September 1, 2026. DeepSeek Harness is in developer preview and compatibility-breaking changes are expected; plugin requirements, model catalogs, and prices change as providers evolve. Modellix operates the gateway and plugin described here and has a commercial interest in them. The Modellix LLM gateway is a text gateway — use text-only prompts; do not attach images.