DeepSeek Harness: The Plugin-First Agent Stack

DeepSeek Harness is a new open-source agent runtime from DeepSeek AI built around one deliberately ambitious rule: everything is a plugin. Models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the user interface are composable parts rather than immovable pieces of one coding product.

The project entered developer preview on August 13, 2026, under the MIT license. You can launch its local Web UI with npx @deepseek-ai/dsh web, or clone the repository and build it yourself. The important caveat is equally explicit: DeepSeek warns that compatibility-breaking changes are expected during the preview.

This makes DeepSeek Harness more interesting as a substrate for agent builders than as an immediate replacement for Claude Code, Codex, or OpenCode. Its value is the separation of the model from the execution environment. Developers can experiment with a different model provider, tool registry, session store, sandbox, loop, or UI without rewriting the entire harness.

The short answer

DeepSeek Harness is an MIT-licensed, open-source agent harness in developer preview. It uses DeepSeek’s Cordis plugin system to compose agent capabilities, and its official documentation describes four runtime modes:

• Standard mode: a full coding agent with file editing, shell access, search, planning, goals, subagents, and workflows.
• Code mode: Standard capabilities plus a Code Mode SDK that lets the model coordinate multiple tool calls in a TypeScript program.
• Minimal mode: a deliberately small environment with a shell tool and file editor, useful for benchmarking or studying model behavior.
• Creator mode: runtime inspection and plugin experimentation for building custom agent presets.

It is not a stable production platform yet. Treat it as an unusually hackable laboratory for agent infrastructure, pin versions, isolate credentials, and expect configuration APIs to move.

What DeepSeek actually released

DeepSeek’s official announcement positions Harness as an agent framework for developers building and modifying harnesses, not just another hosted coding assistant. The repository describes dsh as an open-source agent harness powered by Cordis, with the core idea that “everything is a plugin.”

The phrase covers more than model adapters. The official site lists plugins for models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and UI. In practical terms, the runtime can replace the component that decides how a model is called, how a command is authorized, where session events are stored, how a filesystem is exposed, or how a conversation is rendered.

That is a different design center from a conventional coding agent. A product such as Claude Code optimizes for a polished, opinionated developer workflow. DeepSeek Harness exposes more of the machinery so a developer can change the workflow itself.

The project is MIT-licensed, but the license does not make the preview stable or safe by default. The repository’s warning—“THERE WILL BE COMPATIBILITY-BREAKING CHANGES”—should be part of every evaluation plan.

Architecture: a plugin tree around the agent loop

The core architecture is easiest to understand as a set of replaceable services mounted into a runtime context:

The architecture is related to the broader principles of harness engineering for AI coding agents: the model is only one part of a reliable system. The surrounding environment determines what context the agent can see, which tools it can call, how work is checked, and whether a failed run can be resumed or audited.

Cordis: why the plugin system matters

DeepSeek Harness is built on Cordis, which DeepSeek describes as a plugin system and meta-framework for composable services. The useful concepts for an agent builder are straightforward:

1. A plugin mounts services or behavior into a context.
2. The context exposes services through stable keys such as model, tools, and sessions.
3. Plugins declare dependencies so required services are available before activation.
4. Typed events let plugins observe or participate in execution.
5. Registration is reversible, so unloading a plugin can remove its listeners, tools, and providers instead of leaving stale runtime effects behind.

The last point is important. “Hot-swappable” systems become unreliable when an unloaded extension leaves timers, event listeners, or tool registrations behind. Reversible registration turns cleanup into part of the extension contract.

This also creates a more useful boundary for testing. Instead of testing only a final answer, a team can test whether a plugin mounts the correct tool policy, whether a session store records the required events, or whether replacing a sandbox leaves the approval rules intact.

Every run is designed to be traceable

DeepSeek’s official Harness site says that everything the model sees is recorded in an append-only session log. That includes system prompts, reasoning, tool calls and results, subagent scheduling, and context injection.

The Trajectory view can inspect those records by source. Resume, fork, search, and replay operate on the same event stream. This is more significant than a nicer conversation transcript: it makes the agent’s execution history a durable system artifact.

For production-minded builders, the useful questions are:

• Can a reviewer reconstruct why a tool was called?
• Can a failed run resume without silently duplicating a side effect?
• Can a fork preserve the original evidence while exploring a new path?
• Can the system distinguish model output from tool output and human approval?
• Can sensitive values be redacted before logs leave the local environment?

The preview does not answer every operational question, but the event-stream design points in the right direction. It aligns with the verification-first approach described in OpenAI Agents SDK 0.20’s MCP migration guide: durable state and explicit tool boundaries are safer than treating an approval phrase in chat as authorization.

How to run DeepSeek Harness safely

The shortest official path requires Node.js:

1npx @deepseek-ai/dsh web

The local Web UI is served at http://127.0.0.1:3080 by default. A safer first task is read-only repository mapping rather than a request that edits files or installs dependencies:

1Map this repository, identify its test commands, and propose one
2read-only verification task. Do not edit files or install dependencies.

From source, the repository documents this path:

1git clone https://github.com/deepseek-ai/deepseek-harness.git
2cd deepseek-harness
3pnpm install
4pnpm run build
5pnpm dsh web

Use a disposable workspace for the first run. Do not expose production credentials, SSH agents, cloud metadata endpoints, or unrestricted home-directory access. The preview warning is a compatibility warning, but the same isolation is necessary for security: a coding harness can read files, run commands, and potentially invoke tools with meaningful side effects.

Before allowing write operations, verify:

• the selected workspace is not a production checkout;
• the model provider key is scoped and rotatable;
• shell and filesystem permissions are visible to the operator;
• network access is restricted where possible;
• session logs do not retain secrets or unnecessary private data;
• a failed run has a clear stop and reset procedure.

These controls are consistent with the safety principles in the site’s MCP tool-server threat model, even when the Harness tool is local rather than an MCP server.

Choosing a runtime mode

The four modes are not merely UI themes. They represent different evaluation boundaries.

A useful progression is Minimal first, Standard for ordinary evaluation, and Creator only after the session and permission model are understood. Code mode deserves separate testing because it changes how several tool operations can be coordinated inside one generated program.

Is it locked to DeepSeek models?

No. DeepSeek Harness comes from DeepSeek, but the official project is positioned as a provider-extensible runtime. Its documentation covers DeepSeek, Anthropic, OpenAI, and custom OpenAI-compatible providers, subject to the capabilities and configuration supported by the current preview.

That separation is strategically important. A harness can be evaluated independently from a model by keeping the task set, tools, permissions, session store, and acceptance checks constant while changing the model adapter.

Do not assume provider compatibility means behavioral equivalence. Different models can vary in tool-call formatting, context use, latency, refusal behavior, and reliability under long loops. Keep model selection explicit in benchmark records and compare the same tasks under the same harness configuration.

DeepSeek Harness versus other agent runtimes

DeepSeek Harness overlaps with several projects but is not interchangeable with them:

The comparison is not about declaring one universal winner. DeepSeek Harness is most compelling when the question is “Which parts of this agent should I be able to replace?” OpenCode and Pi are useful comparisons for open implementations, while Hermes Agent 0.20 shows a different path: expand the workbench around a persistent agent rather than make every runtime component replaceable.

Performance, cost, and operational trade-offs

DeepSeek Harness does not remove model cost. It adds a runtime whose overhead depends on the chosen provider, tool count, logging volume, sandbox, and number of model turns.

Measure at least:

• time to first model response;
• time spent in tool execution and sandbox startup;
• tokens and cost per completed task;
• number of retries and failed tool calls;
• log volume and storage retention cost;
• success rate under a fixed acceptance test;
• recovery behavior after process or network interruption.

A more modular runtime can improve experimentation but also introduces more configuration paths. A plugin that makes the system easier to customize can make it harder to reason about unless the effective configuration is inspectable and versioned. The Creator mode and configuration-dump workflow are therefore useful design directions, but teams should capture the exact profile, package versions, model settings, and permissions with every benchmark.

Do not publish benchmark scores from one preview profile as general model rankings. If the harness, mode, tools, or prompt changes, the result is a system measurement—not a pure model measurement.

Common mistakes during evaluation

Treating the preview as production-ready

The official repository explicitly warns about compatibility-breaking changes. Pin the package or commit, keep a rollback path, and avoid building an irreversible dependency on undocumented service keys.

Granting broad permissions too early

Start read-only. Approve one bounded write task only after inspecting the tool and filesystem policy. A plugin architecture increases flexibility; it does not make a dangerous tool safe.

Confusing append-only logs with automatic privacy

Traceability helps debugging and review, but logs can contain prompts, source code, credentials accidentally printed by tools, and private data. Define redaction and retention rules before connecting sensitive repositories.

Comparing products by feature checklist alone

DeepSeek Harness may list tools, planning, subagents, and workflows alongside mature products, but feature presence is not the same as reliability, integration depth, or operational support. Compare task completion under controlled tests.

Running unpinned remote code

npx is convenient for exploration, not a sufficient production release process. Inspect the repository, pin a reviewed version, use a lockfile, and prefer a controlled build for repeatable environments.

A practical evaluation plan

Use a small, evidence-producing test plan:

1. Install in isolation. Use a disposable workspace and a restricted provider key.
2. Run Minimal mode. Measure startup, tool latency, logging, and failure behavior.
3. Run Standard mode read-only. Ask for repository mapping and test discovery.
4. Inspect the trajectory. Confirm that model inputs, tool calls, results, and approvals are distinguishable.
5. Test one reversible edit. Require a diff and run deterministic checks.
6. Test interruption and resume. Stop the process during a safe task and record what survives.
7. Swap one plugin. Change the model or storage component and repeat the same task.
8. Record the effective configuration. Keep versions, profile, permissions, model, and acceptance evidence together.

This turns a promising architecture into a measurable engineering evaluation rather than a demo-driven conclusion.

FAQ

Is DeepSeek Harness a Claude Code replacement?

Not today. It is a developer-preview agent harness and plugin substrate. It can perform overlapping coding-agent tasks, but it should not be treated as a mature drop-in replacement for commercial products with established integrations and support.

Can it run locally?

Yes. The official quick start launches a local Web UI with npx @deepseek-ai/dsh web, and the repository documents running from source.

Is DeepSeek Harness open source?

The repository is published under the MIT license. Its preview status still means APIs and behavior can change.

Does it require a DeepSeek model?

No. The project documents multiple provider paths, including custom OpenAI-compatible endpoints. Verify the current provider guide before relying on a specific adapter.

Should I use it for production agents?

Only after a controlled review of version stability, permissions, sandboxing, logging, provider behavior, and failure recovery. For most teams, the sensible first use is a local evaluation or a non-sensitive internal prototype.

Conclusion

DeepSeek Harness is notable because DeepSeek is publishing the layer around the model as an open, replaceable system. The “everything is a plugin” principle reaches into the model adapter, tool registry, session state, sandbox, loop, scheduler, and UI. Its append-only trajectory design also makes the execution process more inspectable than a plain chat transcript.

The trade-off is maturity. This is a developer preview with compatibility-breaking changes expected, not a finished enterprise platform. Builders should evaluate it for composability, traceability, and the ability to swap runtime pieces—not assume that an impressive feature list equals production reliability.

For teams already practicing harness engineering, DeepSeek Harness is a useful concrete experiment: it makes the execution environment itself a first-class artifact. That is the part worth watching, regardless of which model eventually runs inside it.

Sources and visual credit

• DeepSeek Harness official developer-preview announcement
• DeepSeek Harness source repository
• DeepSeek Harness README
• VentureBeat independent launch coverage
• Cordis architecture reference in the repository

The architecture diagram is original Mermaid artwork created for this article. No external image is used.

Visual: Security control path

This original threat-to-control diagram turns the security guidance in this article into a concrete sequence of gates.

Visual reading: security is layered. Blocking unsafe actions before execution is important, but allowed actions still need sandboxing, logging, and output validation.