DeepSeek Open-Sources Harness, an All-Plugin Agent Runtime

DeepSeek released DeepSeek Harness v0.1 on August 13, 2026 — an open-source agent runtime, MIT-licensed and in developer preview, built on a single architectural bet: there is no privileged core. Models, tools, skills, sessions, sandboxes, filesystems, the agent loop itself, and even the UI are all plugins mounted into a shared context. The framework underneath, Cordis, is not new to this project — it has been running the Koishi chatbot ecosystem for four years — and it shipped the same day as a formal paper co-authored with Peking University giving it a mathematical foundation.

Advanced

DeepSeek Harness settings panel showing a searchable plugin list of 159 entries, including include, timer, hmr, llm, session, typert-registry, typert-loader, api-gateway and session-title, each with an enabled or disabled toggle.
Image credit: DeepSeek Harness

What Shipped

The harness is distributed as dsh and runs from npm without a clone:

npx @deepseek-ai/dsh web

That starts a web UI on http://127.0.0.1:3080. Building from source is a standard pnpm workflow (pnpm install, pnpm run build, pnpm dsh web). The repository carries an explicit developer-preview warning about breaking changes, and it has drawn attention accordingly — 72.6k stars and 6.2k forks at the time of writing.

Composition happens in layers rather than in code. Bundles ship Cordis config rows plus the code they configure; profiles are named compositions stored in the harness home directory. The layers apply in order — base bundles, then profile patches, then home-level patches, then CLI overlays — and each layer can patch a row by ID, replacing a whole configuration or inserting a new one. dsh --profile web --dump-config prints the resolved tree. The core bundles are dsh-base (model adapters, tools, persistence, sandbox, credentials), dsh-web-app (the browser UI), and dsh-headless (a one-shot runner with no server).

Everything Is a Plugin

The plugin claim is literal, and the settings panel above is the evidence: 159 plugins in a default deployment, with llm, session, and the hot-module-reload plugin sitting in the same list as everything else, individually toggleable.

Capabilities are exposed as services on stable context keys, so a consumer never imports a provider directly:

Package Service Context key
core/session Append-only event log and store ctx.sessions
core/tools Scoped registry and execution ctx.tools
core/agent Agent interface and lifecycle ctx.agents
core/agent-loop Default driver implementation ctx.agentLoop
llm/llm Message vocabulary and adapter seam ctx.llm
core/system-prompt Prompt assembly ctx.systemPrompt

The documentation calls each of these a seam, with three roles: a service definition (the interface contract), a service provider (the swappable implementation), and a consumer. The payoff is that a single provider swap propagates. Replacing the filesystem provider, the architecture document notes, moves Bash, PTY, and LSP onto a remote sandbox — with no forking of any of them.

Turns, Steps, and an Append-Only Log

A turn contains zero or more steps, where a step is one model request plus the tool calls it produces. The flow, with its extension points, looks like this:

turn/start
  → agent/pre-step          (reject or rewrite messages)
    → step/start
      → assemble prompts + schemas
      → agent/request → llm/stream → assistant/message
      → tool/call → tools/execute → tool/result
    → step/end              (do tools owe another request?)
  → agent/turn-stopping     (serial, no delegation)
turn/end

Durable session events (turn/*, step/*, user/message, assistant/*, tool/*) persist to the log. The live extension points (agent/pre-step, agent/request, llm/stream, tools/*) are waterfalls, where a listener calls next() to delegate down the chain.

The session log is the source of truth, and the invariant is enforced at runtime: model-visible means logged. Anything that reaches the model — system prompts, reasoning, tool calls and results, subagent scheduling, every context injection — must be reconstructible from the log, and fork, resume, transcript, and telemetry all derive from that stream through deriveMessages(). The trajectory view is the user-facing consequence.

DeepSeek Harness trajectory view showing a timeline of input, model and tool events across turns, an expanded transcript of system, user, context, assistant and bash tool entries, and a right-hand inspector panel with payload, result, schema and timing for a single tool call.
Image credit: DeepSeek Harness

Cordis, and the Paper Underneath It

Cordis is the microkernel doing the mounting, unmounting, and dependency resolution. Its model has four pieces. A context is a repository of services on stable keys. A plugin is an object implementing Service — either a function with optional inject and apply(ctx) fields, or a Service subclass. Dependencies are declared through inject, so load order falls out of service requirements instead of manual sequencing. And events dispatch in four modes: emit (fire-and-forget), waterfall (middleware-style wrapping with return values), parallel, and serial.

The piece that makes hot reloading tractable is that registrations are reversible effects. Tool schemas, listeners, and providers install through ctx.effect() or ctx.on(), each returning a disposer, so unloading a plugin unwinds everything it installed. There is no core to patch — you extend by mounting a plugin alongside the others.

On the same day, DeepSeek and Peking University published A Programming Paradigm for Spatiotemporal Composability (draft dated August 13, 2026), which formalises exactly this. It names two dimensions: temporal composability, the ability to completely revert a component’s side effects on removal, and spatial composability, the ability to declare and reactively manage inter-component dependencies. These become revertible effects (context transformations carrying runtime-tracked inverses) and reactive coeffects (context changes that notify components per their specifications), unified into a single context type, with a calculus of dynamic composition and metatheory establishing composability guarantees across interleaved components. Koishi — four years of development and over 4,000 community plugins — serves as the case study. Koishi runs Cordis v3; the harness runs v4.

What This Means

Most agent frameworks are extensible at the edges: you can add a tool, register a model provider, maybe wrap the loop. Harness moves the extension point inward. When the agent loop and the LLM adapter are themselves plugins behind service keys, replacing the loop is a configuration row rather than a fork, and that is a materially different maintenance story for anyone who has carried patches against a fast-moving upstream.

The append-only log invariant is the other thing worth noting, and it is a research-friendly property more than a product feature. A harness where every token the model saw is reconstructible from disk is a harness you can audit, replay, and run ablations against — which is not true of most agent stacks, where the assembled prompt is an ephemeral intermediate. For anyone studying agent behaviour rather than just using an agent, that is the difference between an observation and an anecdote.

The caveats are real. This is v0.1 with a stated expectation of breaking changes, Cordis itself documents an unstable API, and a 159-plugin default deployment is a large surface to reason about when something misbehaves. The plugin-first design also arrives with a commercial edge: the harness is free and MIT-licensed, while the V4-Pro model it defaults to got considerably more expensive the same week. Caixin Global and Fortune both report API increases of up to roughly 1,100% depending on model, token type, and time of day, taking effect August 16. An open harness that speaks to any model adapter is, of course, also a harness that can be pointed somewhere else.

Related Coverage

This post was drafted with AI assistance and reviewed by RITS staff.

Sources