DeepSeek Harness: The unbundled agent runtime

dsh is an open-source, local-first agent runtime built on one rule: everything is a plugin. Swap models, tools, and sub-agents without touching code.

Most AI coding agents ship as a sealed box. You get one model, one tool loop, one way of managing session state, and if you want to change any of it you are forking the whole project. DeepSeek Harness, shortened to dsh, was built against that assumption directly.

It is an open-source, local-first agent runtime organized around a single architectural rule: everything is a plugin. Not "everything is configurable." Not "most things are extensible." Everything, including the parts most runtimes treat as fixed infrastructure, is a swappable component.

**A micro-kernel, not a monolith**

Traditional agent stacks are monoliths. The agent loop, the tool pipeline, the session state manager, and the execution sandbox are all fused into one codebase, so changing any single piece risks breaking the rest. dsh is built on top of Cordis, a meta-framework designed for exactly this kind of decomposition, and it uses that foundation to pull each of those pieces apart into independent, hot-swappable layers. The agent loop is a plugin. The tool pipeline is a plugin. Session state and execution environments are plugins too. You can replace any one of them without touching the others.

**Any model, no code changes**

While dsh is tuned for DeepSeek V4 models, it does not lock you into them. Model selection lives entirely in declarative YAML configuration. Point it at a local model, a remote provider endpoint, or a self-hosted server, and the runtime behaves identically. Switching targets is a config edit, not a code change, which matters a lot if you are testing a new model or moving a workload from a laptop to a server without rewriting your integration.

**Sub-agents, not just tools**

Because everything is a plugin, that includes other agents. External harnesses and specialized tools, Claude Code and Codex among them, can be wired in as sub-agents rather than flat tool calls. That turns dsh from a single-agent runtime into a multi-agent orchestration layer, where a top-level orchestrator dispatches work to whichever sub-agent is best suited for it and merges the results back.

**Telemetry that isn't an afterthought**

Runtime performance metrics are exposed natively rather than bolted on. Prompt cache hit rate, real-time token throughput, step durations, and API cost attribution per turn are all available live, which makes it possible to actually see where time and money are going in a long agentic session instead of guessing after the fact.

**Turns, steps, and where plugins hook in**

dsh draws a hard line between two units of work. A Turn is a full conversational exchange. A Step is one execution unit inside that turn: a model request, a tool call, and the resulting output. That distinction matters because it is also where extensibility lives. Plugins can intercept a step before it runs, rewrite it, or abort it outright, giving you a precise point of control instead of only being able to act before or after the entire turn.

**Sessions you can replay and fork**

Every system message, prompt state, and tool response gets written to an append-only event stream. Nothing is mutated in place. That gives you full session replay, the ability to fork a session's state at any point and explore a different path from there, and deterministic debugging, since the exact sequence of events that produced a given outcome is always recoverable.

**Four ways to run it**

dsh ships with distinct execution profiles rather than forcing one interaction model on every use case. Web mode gives you a local UI. Headless mode is built for automated CI/CD pipelines. Minimal mode is a bare CLI shell. SDK mode is for programmatic integration into a larger application. Same runtime, four different front doors depending on what you're building.

**Permission boundaries that are actually granular**

Autonomy and safety are handled through sandboxing policies and permission hooks rather than a single blanket setting. Routine, low-risk operations run inside restricted containers without interruption. Anything flagged as critical, a destructive filesystem operation being the obvious example, requires explicit approval before it executes. The security boundary sits at the level of individual operations, not the level of the whole session.

**An operating system, not an assistant**

Put together, these pieces add up to something different from the usual coding assistant. DeepSeek Harness is not trying to be the best single-purpose tool. It is trying to be the substrate other tools, models, and agents plug into. That is a meaningfully different bet, and it is the one that open, composable infrastructure tends to win over time.