Model Plugins
The model is the soul of an Agent, but in Harness it is a plugin too. Switch adapters in configuration to connect DeepSeek-V4 or another provider to the same tools and session logs.
DeepSeek-V4 model pluginDeepSeek Harness · Everything is a Plugin
Plugins Provide Every Agent Capability Cordis Only Manages Load and Dependencies
DeepSeek Harness turns “what can it do” into pluggable modules: model adapters, tools, skills, sessions, sandboxes, storage, loops, scheduling, and UI are all plugins. Align requirements with DeepSeek-V4 on the DeepSeek web version first, then swap the matching plugins in Harness configuration.
Kernel
Cordis
Load / unload / dependencies
Capability
All Plugins
Including model and UI
Config
Compose Freely
No source changes needed
Ecosystem
dsh-plugin
Discover via GitHub topic
Capability Surfaces Covered by Plugins
From Model to UI, DeepSeek Harness Has No Privileged Kernel Features
Official statement: every Agent capability is provided by plugins. That means DeepSeek-V4 adapters, toolsets, and even the interface can be replaced or extended.
Tools and Skills
File editing, Shell, retrieval, Skills, and more register into the tool table as plugins. Standard Mode ships the full combination; Minimal Mode can be cut down to bash + editor for evaluations.
DeepSeek Harness toolsSessions and Trajectory
Session logs are append-only: system prompts, chain of thought, tool results, sub-agent scheduling, and context injection share one source and can be replayed—so you can debug exactly what the model saw.
DeepSeek session logsSandbox and Storage
Sandboxes, filesystems, and persistence are plugins too. Swap sandbox policy without changing the Agent loop—just switch implementations at the configuration layer.
DeepSeek Harness sandboxLoops, Scheduling, and Sub-Agents
The Agent loop, task scheduling, and sub-agent orchestration are composable. PTC / Code Mode goes further by letting the model chain multi-step tools with a TypeScript program.
DeepSeek Agent loopUI is a Plugin Too
The Web UI is not an irreplaceable shell. dsh web launches the browser interface, which itself lives in the plugin tree and can overlay different packages by profile (for example web / headless).
DeepSeek Harness Web UI How the Runtime Stacks
One dsh Launch = an Ordered Plugin Tree
The official architecture describes a running dsh as a plugin tree composed from multiple configuration layers at startup. Understanding the layers helps you extend instead of fork.
01
Profile Configuration
A profile is a named combination: the bundles to overlay, out-of-tree plugins, and your own cordis.patch.yml. web and headless are provided as templates.
02
dsh-base
The first layer of almost every profile: model adapters, tools, persistence, sandbox and approval policy, settings, credentials, telemetry, and other fundamentals.
03
dsh-web-app / headless
web-app overlays the browser application; headless overlays a serverless one-shot runner. Same plugin philosophy, different delivery shapes.
04
Community Plugins
Use the dsh-plugin topic so plugins can be found. APIs will change during preview; plugin authors should follow the official developer guide and Discussions.
Why This Design Matters
Open Source to Inspect, Plugins to Reshape
The license makes the code auditable; Cordis makes the runtime recomposable. For DeepSeek Agent developers, that means a lower cost of forking.
01
Declare Dependencies with inject
Plugins declare required services (such as tools and llm) via inject; Cordis starts consumers only after those services are ready. Load order is decided by dependencies, not YAML line numbers.
02
Reversible Side Effects
Listeners, tool registrations, and timers are cleaned up automatically when a plugin unloads. Resources that need explicit release register a disposer with effect, so hot-swap does not leak.
03
Chat First, Then Change Plugins
When you are unsure whether to swap the model or the tools, ask DeepSeek-V4 on the DeepSeek web version to clarify task boundaries first, then return to Harness to change configuration—avoid swapping plugins blindly.
Align Goals on the DeepSeek Web Version before Composing Plugins
DeepSeek-V4 helps you spell out the task; Harness plugins connect capabilities into a real environment.
Plugin FAQ
What to Know before Writing a DeepSeek Harness Plugin
Aligned with official docs: plugin shape, configuration composition, and how work is split with the DeepSeek web version.
01 What does a plugin look like?
The common shape is a TypeScript module that exports apply(ctx); it can also be an object with apply, or a Service subclass that provides a service. The framework passes the shared context ctx at load time.
02 How do I attach a plugin to the runtime?
Register the module path or package name in cordis.yml / overlay / patch. Official tutorials stress that plugin paths need to be absolute in some scenarios, and that you overlay via profile instead of changing core packages.
03 Can the UI really be swapped out?
Officially, UI is listed as a plugin capability at the same level as models and tools. You can select or extend the interface at the configuration layer without modifying DeepSeek Harness source.
04 Does this conflict with using the DeepSeek web version directly?
No. The web version is for fast conversation and DeepSeek-V4 reasoning; plugins are for turning a validated flow into a tool chain. CTAs on this site take you into web-version chat first.
05 Will preview plugins break often?
Breaking changes will happen—that is an official warning in capital letters. Treat plugins as evolving experiments, watch Discussions, and do not assume the API stays stable long-term.
06 Where can I read architecture details?
The official repository docs/architecture.md, the Cordis primer, and the developer guide. This page is an introduction for search and product understanding; it does not replace upstream docs.
From Conversation to a Pluggable Agent
Enable dsh when you need local tools and a sandbox; you can enter the DeepSeek web version now.