DeepSeek Harness vs OpenCode: Architecture Compared

Published Sep 22, 2026 · dshpacks Research · ~8 min read

Both are open-source agent harnesses you run yourself. They are built on opposite assumptions about extensibility, and that difference shows up in every other decision — how you install them, what a plugin is, and how much the agent can do before it asks. Everything about OpenCode here comes from its own documentation; everything about dsh from its own repository.

The short version

DeepSeek Harness (dsh) is a harness where everything is a plugin — including the parts most projects treat as the product. OpenCode is a coding agent with a fixed core and a hook system: it ships a terminal UI, agents and tools, and lets plugins react to events around them. If you want to reshape the agent loop itself, dsh is built for that. If you want a coding agent that behaves the same way for everyone plus a clean extension surface, OpenCode is built for that.

What each one is

DeepSeek Harness is an open-source agent harness published by DeepSeek AI under the MIT licence, built on the Cordis plugin framework. Its own repository describes it in four words — Everything is a Plugin — and that is literal: the Web UI, the tools, memory backends and model providers all arrive as plugins rather than built-ins. It is in developer preview, and its README warns in capitals that compatibility-breaking changes are coming.

OpenCode describes itself as the open source AI coding agent, available as a terminal interface, a desktop app (beta) and an IDE extension. It ships with two built-in agents you switch between with Tab — build (full access, the default for development work) and plan (read-only, denies file edits by default and asks permission before running bash commands) — plus a general subagent for multi-step searches, invoked as @general.

How you install and run them

The fastest dsh path needs no clone. With Node.js installed:

npx @deepseek-ai/dsh web

That serves the Web UI on http://127.0.0.1:3080 and opens it locally. Source builds go through pnpm and the repo's build script.

OpenCode's own quickstart is a single install script, with package managers documented alongside it:

curl -fsSL https://opencode.ai/install | bash

After that you run opencode inside a project and initialise it. Both projects expect a model provider to be configured before the agent is useful — dsh through Settings → Models, OpenCode through its /connect command or a config file.

How you extend them: plugins vs hooks

This is the real fork in the road. A dsh plugin is a capability. Capabilities are added per profile — an ordered stack of plugin bundles plus your own patch layer, stored under $DSH_HOME/profiles/<name> — and plugin management forwards to pnpm inside that profile directory:

dsh plugin --profile web add <package-name>

Because the core is itself plugins, a dsh plugin can replace or extend almost anything, and the shipped profiles (web, headless, sdk, sdk-minimal, acp) are just different stacks of them. The cost is that the whole stack is your responsibility: dsh's own safety notice says sandboxing, approval prompts and permission controls reduce risk but do not guarantee isolation, and that dsh should not be your only security control for untrusted workloads.

An OpenCode plugin is a JavaScript or TypeScript module that returns hooks. It is loaded automatically from a project plugin directory or a global one, or declared as an npm package in the config file; npm plugins are installed with Bun at startup and cached locally. Hooks fire around things that already happen — tool.execute.before and tool.execute.after, file events, permission events, session and message events, LSP diagnostics and TUI events. In OpenCode's own example, a plugin rewrites a bash command before it runs, or blocks a read of .env. The core stays the core.

Where project context lives

OpenCode writes a project instruction file for you: running /init analyses the repository and creates an AGENTS.md in the project root, which its docs recommend committing to Git. dsh's equivalent surface is the workspace you select in the Web UI — the session composer stays unavailable until one is chosen, which the upstream guide calls the most common first-run confusion.

Permissions: what the agent may do without asking

Both projects treat approvals as a feature rather than friction, and both put the decision in front of you. OpenCode makes it a mode: the plan agent denies file edits by default and asks before bash commands, while the build agent has full access. dsh asks before operations that require approval under the active permission policy, and its safety documentation is explicit that the guarantees are limited — run with the least privilege you can, prefer a disposable VM or container, keep backups, and review third-party plugins before loading them.

Model providers

OpenCode's docs say you can use any LLM provider by configuring its API keys, and it offers a curated tested-model list through OpenCode Zen for people who would rather not choose a provider first. dsh's Web UI guide uses a DeepSeek API key and the repository documents other providers and custom OpenAI-compatible endpoints on the same settings page. Neither harness locks you to the vendor whose name is on it.

How open each one is

dsh is MIT-licensed and its extension model is unbounded in scope — the harness, the UI and the agent loop are all replaceable plugins. OpenCode's extension model is deliberately bounded by hooks around a core it maintains. Neither answer is "more open" in the abstract; they disagree about whether the shape of the agent should be part of the product or part of your configuration.

Which one fits which workflow

Where each ecosystem stands today

This comparison is published by dshpacks, a directory that tracks the dsh plugin ecosystem. At build time it lists 2,961 English-visible dsh plugins across 27 categories, of which 1,651 carry a completed review; 1,583 of those publish a verified install command, 1,349 in the harness-managed dsh plugin form and 1,188 naming the web profile. Those numbers are measured from the directory's own data on every build, not typed by hand — the September 2026 ecosystem report breaks them down by category, and the tutorial walks through running dsh and adding your first plugin.

We publish no equivalent numbers for OpenCode: we have not measured its plugin ecosystem, and inventing a figure to balance the paragraph would be worse than leaving it out.

Sources

Where to go next

deepseek harness vs opencodedsh vs opencodeopencode alternative

Browse the directory by category

Coding & Development 321 · Infrastructure & Deployment 196 · Development & Runtime 87 · Vision & Multimodal 32 · Models & Providers 18 · All 27 categories · All 1,651 reviewed plugins