Skip to main content
All posts
Comparison

DeepSeek Harness vs Claude Code: Architecture, Plugins, MCP

DeepSeek Harness vs Claude Code on licensing, plugin architecture, MCP, hooks, and subagent delegation — is dsh a real open-source Claude Code alternative?

DeepSeek Harness (dsh) is an MIT-licensed, open-source agent harness built around a single extension mechanism — everything is a Cordis plugin. Claude Code is Anthropic's proprietary coding agent, which separates extensions into skills, commands, hooks, and MCP servers, and ships an official plugin marketplace. They aren't purely rivals, either: dsh can delegate work to Claude Code as a subagent, and it can reuse a Claude Code hooks.json file directly.

This is the fact-based comparison — no fabricated benchmark numbers, no invented pricing — pulled from dsh's own documentation and package structure, and from what's publicly known about Claude Code. That combination of full open licensing, comparable MCP tool naming, and a native subagent bridge into Claude Code itself is why dsh gets framed as an open-source Claude Code alternative rather than just another coding agent; the facts below are what actually back that framing up.

License and architecture, side by side

DimensionDeepSeek Harness (dsh)Claude Code
LicenseMIT, fully open sourceProprietary CLI distributed by Anthropic
Core architectureCordis plugin framework — everything (tools, commands, skills, hooks, MCP bridges, model adapters) is the same kind of pluginSeparate mechanisms for skills (SKILL.md), commands, hooks (hooks.json), and MCP config, plus an official plugin marketplace
Primary interfaceLocal Web UI (npx @deepseek-ai/dsh web, 127.0.0.1:3080) and a headless CLI modeTerminal-first CLI, with IDE extensions
Version statusDeveloper preview (npm 0.1.0-rc.6 as of this writing), no SemVer promise, no GitHub ReleasesEstablished, publicly documented product

The architectural split is the headline difference. In dsh, a hook, a Skill, an MCP server bridge, and a tool are all just plugins registered against the same Cordis Context — there's no separate manifest format for each. Claude Code instead treats skills, commands, hooks, and MCP servers as distinct extension types, each with its own file format, and adds a marketplace layer on top (confirmed by a CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL test flag that shows up in dsh's own Claude Code subagent test suite — a small but concrete signal that the marketplace and its auto-install behavior are real).

MCP: same tool-naming shape, narrower scope in dsh

Both tools bridge Model Context Protocol servers, and dsh's docs go out of their way to point out the resemblance: dsh names bridged tools mcp__<serverName>__<rawName> — the same server-qualified shape Claude Code and Codex use. If you've configured MCP servers for Claude Code before, the mental model transfers directly.

Where they diverge is scope. dsh's @deepseek-ai/dsh-mcp-client explicitly bridges only MCP Tools — Resources and Prompts are documented as deferred, with no harness-side consumer yet. Claude Code's MCP client is documented to also surface Resources (as @-mentions) and Prompts (as slash commands) in addition to Tools. If an MCP server you rely on leans on Resources or Prompts rather than Tools, that's a real functional gap to check before switching.

A dsh MCP server config looks like this (stdio transport, one plugin instance per server):

- id: mcp-github
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: github
    transport: stdio
    command: npx
    args: ['-y', '@modelcontextprotocol/server-github']
    env:
      GITHUB_TOKEN: !!js process.env.GITHUB_TOKEN

Editing this line triggers hot-reload — dsh disconnects and reconnects the server without restarting the process. See our MCP setup guide for streamable-http config, reconnection behavior, and timeout limits.

Hooks: dsh can run your existing Claude Code hooks.json

This is one of the more surprising facts in the comparison: dsh ships an official bridge package, dsh-hooks-claude-code, that translates an existing Claude Code hooks.json file into dsh's own extension-point listeners (agent/session-start, tools/pre-execute, and so on). If your team already invested in Claude Code hook scripts, you don't necessarily have to rewrite them to try dsh. A parallel dsh-hooks-codex bridge exists for Codex CLI hooks. See Hooks and slash commands in DeepSeek Harness for how the bridge maps events.

Subagents: dsh can delegate to Claude Code itself

The single most interesting fact for anyone framing this as "which one wins" is that dsh's subagent system natively supports Claude Code as one of its subagent providers (dsh-subagent-claude-code, which drives Claude Code through its official Agent SDK), alongside a Codex provider, an Agent Client Protocol provider, and in-process providers. Subagents can be one-shot or continuable, and one-shot delegation supports outputSchema, depthLimit, toolFilter, and persona — a provider must explicitly declare support for each; unsupported requests fail loudly rather than degrading silently.

Practically, that means dsh isn't strictly a Claude Code alternative — it can be an orchestration layer that calls Claude Code as one of its execution backends, alongside DeepSeek's own models and other subagent types. See DeepSeek Harness subagents for the full provider table.

Skills: not directly interchangeable

dsh's Skill system (ctx.skills, a provider registry merging filesystem and built-in sources) is architecturally its own thing — it isn't the same format as Claude Code's SKILL.md directory convention. A community Discussion (#88) specifically asked whether dsh could reuse "traditional" Skills, and the docs don't currently document direct compatibility. Some community plugins bridge this gap by design — for example, dsh-skillport discovers existing SKILL.md libraries across Claude Code, Codex, Cursor, and Gemini paths and loads them into dsh. That's a community workaround, not an official compatibility guarantee.

Models, sandboxing, and maturity

  • Model providers: dsh ships native DeepSeek support plus a built-in directory for Anthropic, OpenAI, Bedrock, Vertex, Azure, and Codex-native auth, on top of any OpenAI-compatible custom endpoint. Claude Code is built around Anthropic's Claude models, with publicly documented support for accessing them via Amazon Bedrock and Google Vertex AI as well.
  • Sandboxing: dsh has three explicit sandbox tiers (read-only, workspace-write, danger-full-access) with platform backends — bwrap/Landlock on Linux, Seatbelt on macOS, an ACL-restricted token approach on Windows — plus an E2B cloud sandbox option. Claude Code uses its own approval-based permission model with configurable auto-approve behavior; the specifics of its sandboxing internals aren't something we're independently verifying here.
  • Maturity: dsh is explicitly a developer preview — no SemVer commitment, no GitHub Releases page, GitHub Issues disabled in favor of Discussions. Claude Code is a shipping, documented Anthropic product.

Which one should you use?

If you're...Consider
Already deep in Claude Code, with working hooks.json scripts and Claude Code subagent workflowsTry dsh's dsh-hooks-claude-code bridge and dsh-subagent-claude-code provider — you may not need to choose, since dsh can call Claude Code for you
Building an orchestration layer that needs to call multiple coding-agent backends (Claude Code, Codex, in-process) from one placedsh's subagent provider registry is designed exactly for this
Want a single first-party product with an official marketplace and one consistent extension formatClaude Code's separated skills/commands/hooks/MCP model is more opinionated and arguably easier to reason about per extension type
Want the extension surface itself to be hackable — write a plugin once, and it can be a tool, a hook listener, or an MCP bridgedsh's "everything is a plugin" Cordis architecture is the more flexible base to build on
Need a stable, versioned tool for production workflows todayWeigh dsh's developer-preview status (breaking changes expected, no SemVer) carefully against Claude Code's shipping status

Neither replaces the other outright for every workload — the subagent bridge specifically means you can use both at once.

FAQ

Is DeepSeek Harness open source and Claude Code isn't?

Yes. dsh is MIT-licensed and its source is on GitHub. Claude Code is distributed by Anthropic as a proprietary CLI tool.

Can dsh actually run my Claude Code hooks without rewriting them?

The dsh-hooks-claude-code bridge package is designed exactly for this — it translates an existing hooks.json into dsh's own extension-point listeners. We haven't independently tested every hook type against it, so verify your specific hooks after installing.

Does dsh support the same MCP servers I already use with Claude Code?

In most cases, yes, if your MCP server exposes Tools — the naming shape (mcp__<serverName>__<rawName>) is the same. If the server relies on MCP Resources or Prompts, dsh's client doesn't bridge those yet.

Can I use Claude Code and dsh together instead of choosing one?

Yes — that's what the dsh-subagent-claude-code provider is for. dsh can delegate a task to Claude Code (via its official Agent SDK) as one of several subagent backends.

Which one has more plugins?

FindHarness currently tracks hundreds of dsh plugins across twelve categories. Claude Code has an official marketplace with its own plugin catalog; we don't track a comparable count for it here.

Next steps