In August 2026 DeepSeek made DeepSeek Harness (dsh) available as a developer preview. The project is open source under the MIT licence and is not merely another terminal coding agent. DeepSeek presents it as an agent harness, the layer that connects a model to tools, session memory, sandboxing, approval policy, subagents, web search, skills, workflows and the user interface.[1][2]
Its defining design principle is:
Everything is a plugin.
Models, tools, skills, sessions, sandboxes, storage, the agent loop, scheduling, subagents and even the UI are composed as plugins on top of Cordis.[1][3][11]
That is a materially different design from a conventional product shaped like:
model
+
fixed agent loop
+
fixed tool surface
+
one product interface
In dsh, even the agent loop is replaceable through composition.[3]
This does not mean DeepSeek Harness is currently more mature than Claude Code, Codex or Muse Code. Its official safety document says explicitly that it is experimental developer-preview software, has not undergone a security audit, and must not be treated as secure or production-ready.[6]
The public @deepseek-ai/dsh npm package checked on 31 August is 0.1.1-rc.2.[10]
Short version: DeepSeek Harness is currently more compelling as open, replaceable infrastructure for building your own agents than as a universal drop-in replacement for Claude Code or Codex. It can also delegate real work to Claude Code and Codex as subagents, so it may operate above those products rather than only against them.[8][9]
Information status: 31 August 2026.
TL;DR
| Question | Verified answer |
|---|---|
| What is DeepSeek Harness? | Open-source agent harness and agent runtime |
| Licence | MIT |
| Status | Developer preview |
| Current npm version | 0.1.1-rc.2 |
| Production-ready? | No, according to official SAFETY.md |
| Security audited? | The project says no |
| Core architecture | Everything is a plugin |
| Underlying framework | Cordis |
| DeepSeek-model-only? | No |
| Other providers | Including Anthropic, OpenAI, Bedrock, Vertex, Azure and custom endpoints |
| Can you add your own model? | Yes, through a provider/adapter |
| Interfaces | Web UI, headless runtime, SDK and profiles |
| Subagents? | Yes |
| Can it run Claude Code as a subagent? | Yes |
| Can it run Codex as a subagent? | Yes |
| Is Codex CLI open source? | Yes, Apache-2.0 |
| Is Claude Code open source on similar terms? | No, its repo points to Anthropic Commercial Terms |
| Is Muse Code beta? | Yes |
| Is there a fair common benchmark of these harnesses? | We found no public harness-identical benchmark |
| Biggest DSH advantage | Composability and replaceability across the runtime |
| Biggest risk | Developer-preview maturity and broad local-agent privileges |
What is an agent harness?
A language model by itself is not a complete agent.
A model can produce:
text
code
plans
tool calls
but another layer must decide:
- which tools exist,
- how commands run,
- where the agent can write,
- when approval is required,
- where history is stored,
- how work resumes,
- how tasks are delegated,
- how multiple agents are coordinated,
- how external models are connected,
- how the user sees and controls the run.
DeepSeek expresses the relationship as:
Agent = Model + Harness
The harness is the operating layer that lets the model act in a real environment.
Why not just build another coding CLI?
DeepSeek Harness does include a CLI, Web UI and headless mode, but its architecture aims beyond one coding assistant.[1][3][5]
The central idea is:
do not hard-code capabilities into the loop;
mount them as replaceable components
Plugin-driven capabilities include:
- model adapters,
- tools,
- filesystem,
- shell,
- sandbox,
- skills,
- web access,
- session persistence,
- compaction,
- subagents,
- jobs,
- scheduling,
- approvals,
- UI.[1][3]
That makes the project closer to an agent framework/runtime than to a single assistant product.
“Everything is a plugin” includes the agent loop
The architecture documentation says that even the model adapter, tool registry, session log and agent loop are plugins.[3]
This goes further than a conventional extension marketplace.
In many products, you can add tools but the internal loop:
prompt
→ model
→ tool
→ model
→ finish
remains owned by the product.
In DeepSeek Harness, the loop itself is a replaceable capability.
The docs describe no privileged core that developers must patch in order to extend behaviour; plugins are mounted beside existing components.[3]
Cordis is the architectural foundation
DeepSeek Harness is built on Cordis.[1][3]
On 26 August 2026, researchers affiliated with Peking University and DeepSeek-AI published:
A Programming Paradigm for Spatiotemporal Composability.[11]
The Cordis design focuses on two forms of composability.
Temporal composability
A component should be removable together with its runtime side effects.
Spatial composability
A component declares dependencies and can react to changes in its environment.
The Cordis implementation provides concepts such as:
- effect tracking,
- dependency resolution,
- declarative loading,
- configuration reconciliation,
- hot module replacement.[11]
So the plugin model is backed by a dedicated runtime and formal design work rather than being only a branding term.
Profiles and bundles
A running dsh is a plugin tree composed at boot.[3]
Profiles
A profile is a named runtime composition.
The documentation includes templates such as:
web
headless
Bundles
A bundle distributes Cordis configuration rows together with the code they mount.
Every profile begins with dsh-base, which contributes components including:
- model adapters,
- tools,
- persistence,
- sandbox,
- approval policy,
- settings,
- credentials,
- telemetry.[3]
dsh-web-app adds the browser application.
dsh-headless adds a one-shot runner without a server.
Configuration is layered
Configuration is applied in ordered layers.[3]
Conceptually:
bundles
↓
profile cordis.patch.yml
↓
home-level cordis.patch.yml
↓
--patch overlays
The effective tree can be inspected with:
dsh --profile web --dump-config
For teams building a custom harness this is a major difference from modifying the upstream source.
Web UI: DSH is not terminal-only
The quick start is:
npx @deepseek-ai/dsh web
The Web UI is served locally at:
http://127.0.0.1:3080
by default.[2]
The user then configures a model, chooses a workspace and starts a session.
The agent can:
- read files,
- edit files,
- run commands,
- delegate work,
- maintain a plan.[5]
Actions covered by approval policy are paused for review.
DeepSeek Harness is not tied to DeepSeek models
This is one of its most important properties.
Settings → Models supports more than DeepSeek.[4]
Official documentation describes catalog providers including:
- Anthropic,
- OpenAI,
and native credential paths for:
- Amazon Bedrock,
- Google Vertex,
- Azure,
- Codex.[4]
It also supports a custom provider for:
company gateways
self-hosted services
custom OpenAI-compatible endpoints
So:
DeepSeek Harness
≠
DeepSeek-model-only harness
Custom models can be added through an LLM adapter
The ctx.llm layer is an adapter registry.[3][4]
The documentation uses a pattern similar to:
class MyAdapter extends LlmAdapter {
async *stream(options) {
// provider implementation
}
}
The adapter translates:
Harness request
↔
provider-specific API
This supports one agent runtime over multiple model backends.
Model configuration can change without restarting the Web UI
The official provider guide says model configuration becomes usable on the next request without restarting the server.[4]
Selecting a model also updates the default for new sessions.
A session that has already sent a request retains the model recorded in its own log.[4]
That is valuable for auditability and reproducibility.
Four runtime modes
DeepSeek documents four principal modes.[1]
Standard mode
A full coding agent with:
- file editing,
- shell,
- file search,
- web search,
- skills,
- planning,
- goals,
- subagents,
- workflows.
Code mode
Standard capabilities remain available, while tools are exposed through a Code Mode SDK so the model can combine multiple operations in one TypeScript program.[1]
Minimal mode
A deliberately small environment:
persistent bash
str_replace_editor
DeepSeek positions it partly for model benchmarking in a minimal tool environment.[1]
Creator mode
Designed for:
- runtime inspection,
- plugin experiments,
- custom agent presets.[1]
Append-only session log
One of the strongest DSH concepts is its event-sourced session history.
DeepSeek says:
Everything the model sees is recorded in an append-only session log.[1]
That includes:
Resume, fork, search and replay work over the same event stream.[1][3]
That is useful for agent auditing.
“Model-visible means logged”
The architecture docs state a strict principle:
Model-visible means logged.
Anything that reaches a model request should be reconstructable from the session log.
This helps answer questions such as:
- what context was present,
- which tool result the model saw,
- when a subagent report arrived,
- why a later turn differed.
Exact behavioural reproducibility still depends on non-deterministic models and external systems, but the log creates a much stronger evidence trail.
Subagents are a capability, not a hard-coded loop feature
ctx.subagents is a provider registry.[8]
Official documentation lists provider implementations including:
spawn-in-process
fork
ACP
Codex
Claude Code
dsh-sdk
A parent agent can therefore delegate work without owning the implementation details of the child runtime.
DSH can start a real Codex product process
This is not merely a direct HTTP call to an OpenAI model.
The implementation note documents:
@deepseek-ai/dsh-subagent-codex
which starts the actual Codex product as a managed process.[9]
The documented implementation pins:
@openai/[email protected]
and talks to app-server --stdio.[9]
Each call creates:
- a fresh product process,
- an ephemeral thread,
- a one-shot task.[9]
So DeepSeek Harness can be an orchestrator above Codex, not merely its competitor.
It can delegate to Claude Code too
A sibling first-party provider integrates the real Claude Code product.[8][9]
From the parent agent’s perspective, the pattern is:
task
→ subagent provider
→ external coding product
→ final result
The provider passes a self-contained task and workspace rather than copying the entire parent conversation.[9]
This keeps ownership of the parent session in DSH.
That changes the comparison with Claude Code and Codex
A simple:
DeepSeek Harness
VS
Claude Code
VS
Codex
is incomplete.
A better mental model is:
DeepSeek Harness
├── own agent runtime
├── own model providers
├── Claude Code as child
└── Codex as child
This does not automatically make DSH better.
It adds:
- dependencies,
- processes,
- configuration,
- a broader attack surface.
But it also enables a vendor-neutral orchestration layer.
Agent Teams are experimental
The repository includes an evolving Agent Teams mechanism with:
- a durable roster,
- shared task board,
- mailbox,
- child sessions.[3]
However, the architecture docs label it an experimental private opt-in coordination seam.[3]
It should therefore not be described as a stable public feature with the same maturity as the main runtime.
DeepSeek Harness vs Claude Code
Claude Code is a finished coding-agent product focused on software-engineering workflows.
It can:
- explore a codebase,
- edit files,
- run commands,
- execute tests,
- work with Git,
- use MCP,
- operate interactively or programmatically.[12]
Philosophical difference
Claude Code:
coding product
with extensive configuration and extensions
DeepSeek Harness:
framework/runtime
where even the agent loop is a plugin
Licence
The Claude Code repository states:
© Anthropic PBC. All rights reserved.
Use is subject to Anthropic's Commercial Terms of Service.
DeepSeek Harness is:
MIT
That distinction matters to teams that want to fork or redesign the runtime itself.
DeepSeek Harness vs OpenAI Codex
A common claim needs correction:
Codex CLI is open source too.
The openai/codex repository is licensed under:
Apache-2.0
Therefore it is inaccurate to call DSH an open-source alternative to a closed Codex CLI.
Both expose source, but their scopes differ.
Codex
Codex is primarily a coding-agent product/platform spanning:
- CLI,
- IDE,
- desktop app,
- cloud execution,
- sandboxing,
- approvals,
- network policies,
- telemetry and audit controls.[13]
DeepSeek Harness
DSH is more explicitly a composition framework for building custom agent runtimes.
Its Codex subagent provider can even start Codex as a child process.[9]
DeepSeek Harness vs Muse Code
Meta launched Muse Code on 5 August 2026 as a beta terminal coding agent powered by Muse Spark 1.2.[14]
Muse Code was co-trained with its model around:
- planning,
- tool use,
- context compaction,
- subagents,
- long software-engineering tasks.[14]
It also uses persistent asynchronous background agents.
Core difference
Muse Code optimises:
Muse Spark 1.2
+
Muse Code
DeepSeek Harness optimises for:
model swappability
+
capability swappability
+
plugin composition
These are different architectural bets.
One co-optimises model and harness.
The other tries to separate model from runtime as much as possible.
Comparison table
| Feature | DeepSeek Harness | Claude Code | OpenAI Codex | Muse Code |
|---|---|---|---|---|
| Primary nature | agent framework/runtime | coding agent | coding agent/platform | coding agent |
| Status 31 Aug 2026 | developer preview | production product | production product | beta |
| Harness source licence | MIT | commercial terms | Apache-2.0 | not presented as comparable open framework in launch materials |
| Multi-model by design | Yes | mainly Claude | mainly OpenAI models | Muse Spark |
| Custom provider | Yes | supported integrations/gateways | OpenAI ecosystem | no equivalent plugin-first provider layer described at launch |
| Web UI | Yes | primarily terminal/IDE | CLI, IDE, desktop, cloud | terminal |
| Headless | Yes | Yes | Yes | CLI agent |
| Plugin-first core | Yes | Not to the same extent | Not to the same extent | Not to the same extent |
| Replaceable agent loop | Yes | Not a main product contract | Not a main product contract | Not a main product contract |
| Subagents | Yes | Yes / agentic workflows | Yes | Yes |
| Can run Claude Code child | Yes | N/A | Not a primary goal | No |
| Can run Codex child | Yes | Not a primary goal | N/A | No |
| Official “not production-ready” warning | Yes | No | No | Beta |
| Sandbox support | Capability | Yes | Yes | Yes |
This table compares product surfaces, not intelligence quality.
Why there is no honest “DSH beats Claude Code by X%” benchmark
We found no public benchmark that holds all of these constant:
same model
same prompt
same repository
same tools
same sandbox
same budget
same time
same grading
If we compare:
Claude Opus + Claude Code
to:
DeepSeek model + DeepSeek Harness
we are simultaneously measuring:
- the model,
- harness,
- system prompt,
- tools,
- context management,
- policy,
- retry behaviour.
A single percentage cannot isolate the harness.
How to benchmark an agent harness fairly
Use two layers.
Test A: same model
For example:
same model through API
+
DeepSeek Harness
vs
same model
+
minimal internal harness
This measures infrastructure impact.
Test B: end-to-end product
Claude + Claude Code
OpenAI model + Codex
Muse Spark + Muse Code
chosen model + DeepSeek Harness
This measures what a team actually experiences.
Metrics
- task completion rate,
- project-test pass rate,
- cost,
- wall-clock time,
- tool calls,
- human interventions,
- regressions,
- out-of-scope edits,
- security violations,
- restart recovery.
Security is the most important section
The official SAFETY.md is unusually direct.[6]
DeepSeek Harness can:
- execute model-generated code,
- run commands,
- load third-party plugins,
- access networks,
- processes,
- credentials,
- files.
The project warns that model mistakes, defects, misconfiguration, malicious input or untrusted plugins may:
- modify or delete files,
- disclose data,
- expose credentials,
- damage the host.[6]
Sandbox does not guarantee isolation
The official warning says:
Sandboxing, approval prompts, and permission controls can reduce risk, but they do not guarantee isolation or prevent damage.[6]
DeepSeek recommends:
- least privilege,
- disposable VM/container,
- backups,
- limiting secrets,
- reviewing plugins and proposed commands.[6]
The harness should not be your only security boundary for untrusted workloads.
Local-first does not mean “no data ever leaves”
DeepSeek calls Harness local-first.[7]
Data stored locally by default includes:
- user inputs,
- model outputs,
- session context,
- tool-call records,
- attachments,
- file paths,
- runtime logs,
- configured credentials.[7]
But when users configure:
- an external model,
- web tool,
- MCP server,
- plugin,
- external service,
those providers may receive data according to their own policies.[7]
Therefore:
local-first harness
≠
local-only AI system
Telemetry is more nuanced than simply “on” or “off”
The repository changed telemetry behaviour during August.[16]
Current implementation notes say FULL requires explicit configuration and fresh profiles do not send full session logs without an active choice. Feedback can trigger a narrower reporting route depending on mode.[16]
The Data Processing Statement also says anonymised configuration information and project lists may be reported, and that users can disable reporting or change the endpoint.[7]
So neither of these blanket claims is safe:
DeepSeek Harness uploads everything
or:
DeepSeek Harness never sends anything
A deployment should inspect the exact version and configuration it runs.
Developer preview means real compatibility breaks
The README warns:
THERE WILL BE COMPATIBILITY-BREAKING CHANGES.
That is not cosmetic.
The packages moved through several release candidates during August, with the current CLI at 0.1.1-rc.2 on our check date.[10]
Public GitHub Discussions also contain community reports about inconsistent npm dist-tags across plugin packages around 0.1.1-rc.2.[15]
Those are community reports, not an official statement that every installation is affected.
They do, however, reinforce the upstream warning not to treat the preview as a stable API.
Is it worth writing plugins today?
Yes, if you accept churn.
Official extension points exist for:
- tools,
- LLM adapters,
- settings cards,
- capabilities,
- conversation nodes,
- storage,
- filesystem,
- sandbox,
- subagent providers.[3][4]
That is attractive for R&D.
It is less attractive for a team that needs a two-year compatibility promise today.
Who should use DeepSeek Harness?
Agent platform teams
Teams building an internal agent platform that must not depend on one model vendor.
AI infrastructure R&D
Teams researching:
- agent loops,
- context policies,
- model routing,
- subagent strategies,
- sandbox providers.
Multi-model organisations
Companies that want one control plane over:
- DeepSeek,
- Anthropic,
- OpenAI,
- internal gateways,
- self-hosted models.
Agent benchmarking
Minimal mode can reduce the tool surface when evaluating model behaviour.[1]
When are Claude Code, Codex or Muse Code a better choice?
Claude Code
When the goal is a polished coding agent and the team is already invested in Claude, MCP and Anthropic workflows.
Codex
When the organisation is in the OpenAI ecosystem and wants a finished platform spanning CLI, IDE, desktop and cloud with mature sandbox and governance controls.[13]
Muse Code
When you want a harness co-trained with Muse Spark 1.2 and persistent background agents optimised as one model-agent system.[14]
DeepSeek Harness
When the main goal is:
building your own harness
rather than merely using a ready-made coding agent
Production checklist before running dsh
Version and supply chain
- Pin a specific
@deepseek-ai/dshversion. - Confirm the package is under the
@deepseek-aiscope. - Confirm the upstream repository is
deepseek-ai/deepseek-harness. - Do not substitute random desktop wrappers for upstream.
- Pin third-party plugin versions.
- Verify plugin versions align with the CLI release train.
Runtime
- Run under a dedicated user account.
- Limit the workspace.
- Keep secrets outside the workspace.
- Maintain backups.
- Require approval for destructive commands.
- Restrict network access.
- Test sandbox denial paths.
- Never assume sandboxing is a perfect boundary.
Models
- Know which provider receives source code.
- Review provider retention policy.
- Protect custom gateways with TLS and auth.
- Scope API keys minimally.
- Log model routing.
- Test more than one model.
Plugins
- Review every third-party plugin.
- Grant only required capabilities.
- Trust MCP servers explicitly.
- Review Skills like code.
- Do not auto-upgrade plugins without review.
Agent quality
- Tasks have acceptance tests.
- The agent runs tests.
- Final diffs receive review.
- Regressions are measured.
- Cost per successful task is measured.
- Long sessions are tested across restart.
- Subagents have clear boundaries.
POLPROG verdict
DeepSeek Harness is one of the most interesting agent projects of August 2026, not because “DeepSeek built its own Claude Code”.
That framing misses the point.
The interesting part is the architecture:
model
is a plugin
tools
are plugins
sandbox
is a plugin
session log
is a plugin
subagent provider
is a plugin
agent loop
is a plugin
UI
is a plugin
And the parent agent can delegate to real Codex and Claude Code products.[8][9]
That changes the question.
Not:
Will DeepSeek Harness kill Claude Code?
But:
Will companies separate models from harnesses and build their own control plane over multiple agents?
That direction is plausible.
Frontier models change quickly. A harness can outlive several generations of models.
DeepSeek is trying to build a layer where:
the model can be replaced
the provider can be replaced
the sandbox can be replaced
the tool can be replaced
the agent loop can be replaced
the UI can be replaced
That is a strong architectural idea.
But on 31 August 2026 the project remains a developer preview. Upstream says it has not undergone a security audit and must not be treated as production-ready.[6]
Our verdict therefore has two parts.
For R&D and controlled experiments
Definitely worth evaluating.
As the direct foundation of critical production
Not yet without your own hardening, sandboxing, version pinning, plugin review and full POC.
The biggest advantage of DeepSeek Harness today is not a “better model”.
Its biggest advantage is that it tries to make the model stop being the architectural centre of the entire agent.

