TL;DR
On August 13, 2026, DeepSeek open-sourced DeepSeek Harness (dsh, repo deepseek-ai/dsh) — an agent runtime, not a model — under the MIT license, as a v0.1 developer preview. Within 24 hours it hit the top of Hacker News (~572 points, 247 comments), climbed past 50,000 GitHub stars (63K+ by Aug 14 morning), and started trending on r/LocalLLaMA.
Three things make it more than another coding CLI:
- It's the loop, not the model. Claude Code is Anthropic's loop around Anthropic's models; Codex CLI is OpenAI's loop around OpenAI's. DeepSeek open-sourced the loop itself — the layer Anthropic and OpenAI have been quietly locking down.
- "Everything is a plugin" is literal. The model adapter, tool registry, session log, sandbox, approval policy, even the UI — all plugins over a Cordis kernel. No privileged core; extensions mount as sibling plugins and unwind on unload.
- Every run is traceable. An append-only session log records everything the model saw — system prompts, reasoning, tool calls, subagent scheduling — replayable down to the failed step.
It shipped the same day as DeepSeek V4-Pro GA (agent capability up ~6x). Same-day model + framework is the message: DeepSeek is moving from shipping weights to controlling the execution layer.
What is dsh?
dsh is a TypeScript/Node agent harness in the same category as Claude Code, Codex CLI or OpenHands. It inspects repositories, edits files, runs shell commands, searches the web, keeps plans, delegates to subagents and enforces approval policy. What differs is how it's assembled:
npx @deepseek-ai/dsh web # Web UI on http://127.0.0.1:3080 That command is enough to get a working agent talking to a model. The npm package (@deepseek-ai/dsh, v0.1.0-rc.6) shipped alongside a pnpm monorepo with 12,000+ commits — a remarkably active first release.
Why TypeScript? DeepSeek's stated rationale: async-first fits agentic concurrent tool calls, interpreted iteration is fast for a quickly evolving preview, npm is the lowest-friction plugin distribution channel, and LLMs are most fluent writing TypeScript. Critics point at memory and performance — one HN thread compared it against Codex (Rust) and Reasonix (Go) and argued compiled languages suit the runtime layer better. The debate is itself a signal: agent harnesses are now competing on architecture philosophy, not just features.
Everything is a plugin
dsh is not built from scratch. It's built on Cordis, a plugin meta-framework DeepSeek adopted as a vendor, which grew out of the Koishi ecosystem (4,000+ plugins). The architecture docs state the design in one line: "no privileged core".
Five building blocks:
- Plugin = a Service. A plugin is a function with optional
injectandapply(ctx), or aServicesubclass. The model adapter, tools, session log, agent loop — all plugins. - Context = a container. Each service owns a stable
ctxkey (ctx.tools,ctx.llm,ctx.sessions). Consumers look up services by key, not by importing implementations — that's the first layer of replaceability. - Declared dependencies via
inject. A plugin declares what services it needs; the framework assembles them in dependency order. Composition is declarative, not hand-sequenced. - Typed events, four dispatch modes.
emit,waterfall(each listener can short-circuit or wrap the next),parallel, andserial.waterfallis the standout: it implements the interceptor pattern natively — a decision-maker can short-circuit, an observer must delegate. - Reversible registration. Everything installed via
ctx.effect()/ctx.on()unwinds on reload or teardown. That's why composition replaces forking: to get a "remote-sandboxed bash", you loadfs-e2b+subprocess-e2bplugins — you don't patch dsh source.
Configuration is layered: profiles (named assemblies like web or headless) → bundles (distributable config + mount code) → patches (target a config entry by id and replace it). Run dsh --profile web --dump-config to see your actual tree, then patch anything without forking.
Traceable by design
The second tagline — Every run is traceable — rests on one hard invariant: model-visible means logged. Anything that reaches the model must be reconstructible from the log.
A Session is an append-only log of typed SessionEvents — the single source of truth. LLM message history is derived from the log, never stored separately; replay regenerates it from the same events. The event vocabulary is extensible via declaration merging: turn/start, step/start, user/message, assistant/chunk (raw streaming chunks, token-level replay fidelity), tool/call, tool/result…
The lifecycle model is clean: a step is one model request plus the tools it calls; a turn is zero or more steps, opened before the first input and closed when no work is owed. Fork, resume, search and replay all operate on the same event stream.
This is the opposite of a memory/summary agent. dsh doesn't store summaries or vector indexes; it stores the event stream. Summaries are a derived artifact produced by a compaction plugin under strict conditions (context overflow). The practical payoff: any failure replays to the exact failed step/end, not "around step N". For debugging agent workflows, that's a qualitative difference.
53 built-in tools
dsh's tool catalog is generated by actually booting each tool plugin and reading ctx.tools.schemas() — not hand-written docs, with a completeness guard that fails the build if a tool-* package is missing. Highlights:
| Category | Tools |
|---|---|
| Shell & filesystem | bash, pwsh, edit, read, write, glob, grep (bundled ripgrep) |
| Terminal | terminal_open/read/send/signal/list/close (persistent sessions) |
| Language server | lsp (Language Server Protocol) |
| Subagents | subagent, subagent_fork, interrupt_agent, list_agents, send_message |
| Planning & workflow | create_goal/update_goal, schedule_*, ralph (fixed workflows), skill |
| Web & sessions | web_fetch, session_event_read/search/trace, session_search |
Every extension point has a documented home: new model provider → register an adapter on ctx.llm; new capability → ctx.tools; shell execution → ctx.shell backend; filesystem policy → ctx.fs provider or fs/* events; process limits → ctx.sandbox backend.
vs Claude Code & Codex
| Dimension | dsh | Claude Code | Codex CLI |
|---|---|---|---|
| License | MIT (open source) | Closed source | Open source (Apache-2.0) |
| Core architecture | Plugin meta-framework (Cordis) | Closed vertical | Closed vertical (Rust core) |
| Model freedom | Bring any model provider | Anthropic models | GPT-5.6 family + select models |
| Extensibility | Everything replaceable via plugins | Plugins/skills, harness fixed | Agent Plugins (0.147+) |
| Traceability | Append-only event log, token-level replay | Session history | Session history |
| Subagents | Yes (subagent* tools) | Yes (since 2.1.x, cross-session) | Yes (multi-agent V2) |
| Runtime modes | Standard / Code / Minimal / Creator | CLI + desktop | CLI + IDE + cloud |
| Maturity | v0.1 developer preview | Stable, production | Stable, production |
The honest read: dsh is not a drop-in production replacement this month. It's a v0.1 preview that explicitly warns of breaking changes. Its significance is strategic — a frontier lab open-sourcing the execution layer, MIT-licensed, in the same week as a 6x-agent upgrade. If it matures, the "which vendor owns the agent runtime" question changes shape: with dsh, the loop is commodity infrastructure, and labs compete on models and plugins.
The same-day V4-Pro GA matters too: DeepSeek quoted it at roughly 1/90th of Claude Opus 4.8's output price. Model + harness + price, shipped as one move — that combination is the story, more than any single component.
Runtime modes
dsh ships four runtime profiles on one base:
- Standard — day-to-day development, full tooling.
- Code — coding-focused; the PTC mode orchestrates tool calls in TypeScript so intermediate data never enters context, cutting token spend.
- Minimal — runs benchmarks with no server.
- Creator — the demo crowd-pleaser: the agent can inspect its own runtime, experiment with plugins, and even build UI it doesn't officially have (e.g. a custom "three-column mode").
Plus dsh-headless (one-shot runner, no server) and dsh-web-app (browser UI on port 3080).
Plugin ideas: build the agent you actually want
Because everything is a plugin, dsh is less a product and more a kit. A few high-value builds, in order of difficulty:
- Vision & image recognition — drop in an image-understanding plugin (the community standard is
open-design) so the agent can read UI screenshots, mockups and error dialogs, not just text. Huge for frontend and design-adjacent work. - Remote sandbox — wire
fs-e2b+subprocess-e2bto run bash, PTY and LSP against a remote sandbox instead of your machine. Because filesystem and process providers share one execution world, moving the provider moves everything. - Cheap-by-default model routing — register DeepSeek V4-Flash / Gemini Flash as the default adapter and a frontier model for hard steps. The
waterfallevent lets you write a policy that short-circuits routine work onto the cheap model. - Custom tool catalog — the 53 built-ins cover the common cases, but adding a domain tool (internal API client, deployment hook, database runner) is just one plugin with an
injectdeclaration and actx.toolsregistration. - Audit-friendly runs — keep the append-only log as-is and add a compaction policy; for compliance-sensitive work, dsh's model-visible-means-logged invariant is the strongest replay story of the three harnesses.
Who should use it
Evaluate it now if:
- You want to escape vendor lock-in on the agent loop — swap model providers, sandboxes, and UI without changing the harness.
- You're building an agent product and want a composable base instead of forking Claude Code or wrapping Codex.
- You need auditable agent runs (enterprise/compliance) — the append-only log with token-level replay is the strongest audit story of the three.
- You're a researcher or power user who likes the plugin model and doesn't mind preview instability.
Hold off if:
- You need production stability this month — v0.1 explicitly warns of compatibility-breaking changes.
- You want a turnkey product with first-party support — Claude Code and Codex are products; dsh is a framework you assemble.
- Performance is your binding constraint and you distrust the TypeScript choice — benchmark it against Codex (Rust) on your own workloads first.
Watch the star trajectory: 50K+ in day one, 63K+ by the next morning, on a v0.1 preview with no marketing push. That's developers voting for "open loop" as a category. Whether it holds up past the preview is the second-half story.
How we wrote this
This piece was compiled on August 14, 2026, one day after the release. We cross-referenced:
- The official deepseek-ai/dsh GitHub repo, architecture docs, and npm registry (
@deepseek-ai/dshv0.1.0-rc.6). - Independent deep-dives from Rohit Raj (tools catalog, config defaults) and the Cordis documentation on plugin semantics.
- Hacker News and r/LocalLLaMA discussion for the TypeScript debate and the V4-Pro day-one context.
We have not independently installed or tested dsh. Star counts, HN points, and tool catalogs are as reported across sources on August 14, 2026 and will shift — it's a developer preview with breaking changes expected. Everything here is a snapshot, not a review.
Corrections or counter-evidence welcome in the comments or via our about page contact.