Codex has its own harness, Claude Code has its own harness, OpenCode has its own harness, and even Kimi has its own harness. DeepSeek had been keeping quiet. On August 13, it finally released the first version of its harness, named DSH (DeepSeek Harness), with its code open-sourced on GitHub. If you look at its accompanying paper, titled A Programming Paradigm for Spatiotemporal Composability, it is packed with category theory symbols—∂Γ, twisted composition, monoid homomorphism, one after another. Seeing all this initially, it’s hard not to be skeptical: is this yet another spherical cow created by researchers in a vacuum? Beautifully stacked in theory, but completely unused when it comes to real engineering?
However, DSH is remarkably different from other harnesses—so different that it deserves a careful disassembly. I chose Codex, which is also open source, as a baseline. Claude Code and Cursor are closed source, making code inspection impossible, whereas Codex’s source code is publicly available on GitHub, allowing true line-by-line comparison. The core question I wanted to answer is: where exactly does the fundamental architectural difference lie between DSH and the existing agent harnesses we have? Who benefits from this difference, and for whom is it merely an unnecessary burden? Here is an initial clue: in DSH, even the agent loop itself is a plugin that can be dynamically replaced while the AI is running. In all other harnesses, this logic is hardcoded into the core codebase, impossible for either humans or AI to alter dynamically. This sounds simple on the surface, but its consequences ripple into every corner of the entire architecture.
Let’s start with Codex, which we are familiar with. Suppose you are using Tavily search in Codex and want to switch to Brave Search. You open the configuration file, change two lines, save and restart the harness; the old search process shuts down, and the new one spins up. In three seconds, the user barely notices. A plugin in Codex is simply a folder on disk containing declarative resources: Markdown skill files, configurations to launch MCP servers, or shell scripts that run on specific events. The plugin itself does not run code inside the harness process; it is merely a collection of files and configs that the harness reads to spawn separate processes on demand. This type of plugin is called declarative.
The benefit of declarative plugins is simplicity. The harness does not need to manage plugin lifecycles; the operating system manages process creation and termination for you. Plugins do not need to be aware of each other—they independently contribute resources, and the harness handles scheduling. But the trade-off is clear: plugins can only contribute files and configurations. They cannot register stateful services inside the harness process, listen for events, or be invoked directly via function calls by other plugins. In other words, what a plugin can do is confined to “supplying materials to the harness”—it cannot modify the behavior of the harness itself.
DSH takes a fundamentally different path. Its plugins run directly inside the harness process, maintaining their own state and sharing the lifecycle of the harness itself. When a plugin loads, it registers its capabilities in-process—such as “I provide search capability” or “I provide a database connection.” If another plugin requires a capability, it declares “I need a database,” and the framework hooks them together. Plugins interact through the framework as an intermediary, rather than remaining isolated like declarative ones. This type of plugin is called imperative: it carries state, runs inside the same process as the harness, and is called directly by other plugins.
An imperative model immediately introduces a problem that does not exist in declarative systems: if you swap out a plugin, what happens to the components currently using it? Codex doesn’t need to worry about this because its plugins provide files and configurations; once replaced, the next read simply picks up the new content. But DSH plugins are executing code running inside the harness process. Other plugins might be holding active references to them; if the old plugin shuts down, those references become dangling. The framework must be able to teardown the old object, clean up its open connections and background tasks, instantiate the new object, and re-wire all references seamlessly. Behind DSH lies a runtime framework called Cordis specifically built for this job. It remembers every modification a plugin makes upon loading and reverts them step-by-step during uninstallation. It monitors dependency relationships for plugins: notifying a plugin to start when its required service arrives, to stop when it leaves, or to reload when its provider changes. Furthermore, it enforces transactional protection during hot reloading: if new code fails to load, it rolls back to the previous stable version, preventing the system from getting stuck in a half-reloaded intermediate state.
The trade-offs of both models are straightforward. Writing a plugin in Codex simply means placing a few files in the right folder—the barrier to entry is virtually zero. However, if you want to modify the behavior of the harness itself, such as switching to a different context compression strategy, you must fork the core codebase and recompile. Writing a plugin in DSH requires registering side effects via framework interfaces, declaring dependencies, returning cleanup functions, and understanding the plugin lifecycle state machine—a significantly higher learning curve. But if you want to alter the harness’s own behavior, you only need to write a plugin without touching the core code.
Stripping away the architectural abstraction, if we put aside the agent loop issue discussed later, both sides share the exact same upper bound. What you can ultimately achieve depends entirely on the business logic you write. If you want a Codex plugin to have hot-swapping capabilities similar to DSH—for instance, a long-running MCP server process reloading its internal logic without restarting—it is technically straightforward: just add a reload API endpoint. However, the plugin author must implement this manually; the framework won’t handle it for you. The same applies to DSH: Cordis only manages scheduling, while how specific business state is cleaned up and restored still has to be explicitly written by the developer. The upper bound is dictated by code quality, having little to do with the framework choice.
The real gap lies in the lower bound. DSH forces you down a heavier
development path, but it builds out the entire infrastructure for you:
undo stack management, dependency change notifications, and
transactional rollbacks. Cordis has already navigated all these
edge-case landmines (a single fiber.ts file alone spans 750
lines). Codex grants you immense freedom, sparing you from this
complexity by default; but if you wish to achieve equivalent
capabilities within a Codex plugin, you must build all of this yourself,
and your first attempt will almost certainly hit various edge cases.
Yet in everyday development, when do we actually have to take this heavy route? I spent a good deal of time trying to construct a scenario to prove that DSH’s imperative model holds a decisive advantage over Codex’s declarative model, but honestly, I couldn’t find one.
Stripping away complex abstract terms, almost no practical problem cannot be solved by Markdown paired with a CLI. A search service involves single or short-term interactions anyway; changing its configuration and restarting the harness takes a mere two or three seconds. A skill is just a plain text file whose updates take effect automatically on the next read, requiring zero framework involvement for hot swapping. A component that truly demands runtime replacement must satisfy two conditions: it holds in-process state across turns, and this state is not persisted into the session log.
In the world of agent harnesses, such components are extremely rare. The context manager is perhaps the most classic example: it holds internal policy state regarding which contexts to retain and which to compress, state that typically isn’t recorded in the session log. But this is perhaps one of the very few exceptions.
For the vast majority of individual harness users, declarative plugins already cover every common feature. Search, skills, hooks—these mainstream needs can all be handled with files and configurations, requiring no in-process hot-swapping mechanism. The transactional HMR, undo stack, and dependency reactivity provided by DSH are genuinely solid engineering, but the problems they solve are either easily covered by a Codex restart or so rare that bearing the complexity of an entire framework for them is simply unjustified.
However, while digging through the code, there is one place where Codex can hardly catch up simply by adding more code. This stems from the most fundamental architectural choices.
In Codex, run_turn() is a hardcoded control flow: it
first performs pre-sampling compression, builds context, issues model
requests, processes tool calls, and finally enters the loop. The
contributor traits it exposes only allow you to insert hooks at
predefined interception points—such as tweaking the prompt before
sending a request, or performing post-processing after a tool call. But
you cannot dynamically alter the skeleton of the control flow at
runtime. You cannot change a single-agent loop into a multi-agent
collaborative loop, change one-shot compression into streaming on-demand
loading, or transform the sequential request → wait → execute pipeline
into a request → streaming parse → parallel tool execution pipeline.
DSH places the agent loop in packages/core/agent-loop,
where it is itself a regular plugin. It exposes the
ctx.agentLoop service while declaring dependencies on
ctx.systemPrompt and ctx.tools. If you want to
replace it with a completely different agent loop—say, a multi-agent
orchestration loop—you simply write a plugin implementing the same
ctx.agentLoop interface and swap it in the configuration
file. The framework automatically unloads the old plugin, cleanly
revokes previously registered event listeners and services, and smoothly
spins up the new loop once new dependencies are in place.
This is akin to the difference between traditional software delivery and a generative kernel. Traditional software companies deliver finished furniture—a chair with a fixed shape that you unpack and use out of the box, but whose structure you cannot modify. A generative kernel delivers core components alongside assembly instructions, allowing users or AI to freely assemble and customize according to their needs. Codex delivers finished furniture: its internal agent loop is permanently fixed, leaving you only reserved extension slots to plug things in. DSH delivers a generative kernel: the agent loop itself is a module that can be entirely unbolted.
This is what it means to be making a whole feast just for one
condiment. The entire mechanism built into Cordis—including side-effect
tracking, dependency change notification, fiber lifecycle,
and transactional HMR—is fundamentally designed to support the single
core goal of making the agent loop replaceable. All other features are
merely byproducts of this goal. The rollback mechanism cleanly
disassembles scaffolding when unloading an agent loop, dependency
notifications alert relevant plugins to reload after a loop version
swap, and transactional HMR prevents bugs in newly loaded code from
crashing the harness on the spot.
The true transformation brought by this architecture is laying down the infrastructure for self-evolving agents. If an agent generates a new tool plugin while running, the framework can hot-load it without restarting the process or interrupting the ongoing task. Cordis guarantees that newly generated plugins leave no leftovers upon uninstallation (the undo stack automatically clears the field), ensures that dependencies between new and old plugins auto-align (dependency notifications take effect), and promises that if generated code encounters errors, transactional HMR will roll back to the last stable state.
On the model capability side, conditions have also matured. Prompting an LLM to write a single-purpose tool plugin of a few dozen lines has long been routine in daily development. Generating a full agent loop spanning hundreds of lines—capable of handling turn state, context assembly, tool scheduling, and error recovery—is a bigger challenge, but it already falls comfortably within the capabilities of today’s top-tier models.
For a model to generate a viable loop, the crucial prerequisite is that the harness must supply rich and accurate context: Cordis interface specifications, the code structure of the existing agent loop, and plugin lifecycle constraints. DSH’s architecture makes this context naturally transparent because its agent loop is an external, readable, and editable TypeScript plugin, eliminating the need to decipher control flow buried inside compiled binaries. Codex’s agent loop is compiled immutably into Rust code; even if a model develops the capability to write a brand-new loop, the system lacks any physical interface to mount it. DSH provides precisely that missing physical slot.
Returning to our initial question: Is DSH merely a spherical cow engineered by researchers in a vacuum? From the codebase implementation, that is clearly not the case. The Cordis source code explicitly addresses and compromises with numerous real-world engineering pitfalls—such as race conditions during concurrent unloads, propagation termination boundaries across dependency chains, and fault-tolerance logic when a disposer fails during rollback. These do not look like pure paper-based deductions; they look like solutions hammered out in production environments running over 4,000 plugins.
However, its applicable scenarios are far narrower than implied in the paper. The paper presents it as a universal new programming paradigm, whereas in reality, it specifically serves the architectural choice of runtime hot-swapping of stateful in-process components. If runtime hot-swapping is not required, the overwhelming majority of hard problems it attempts to solve simply disappear.
For the vast majority of developers using Codex, Claude Code, or OpenCode day to day, DSH will not make your daily coding experience any better. Codex’s declarative model is simple enough with a low bar to entry, and a two-to-three-second restart is entirely acceptable. The Cordis mechanism inside DSH represents little more than gratuitous complexity for your use cases.
Yet for pioneers seeking to push the upper boundary of agent harnesses—those who want the harness to self-evolve, dynamically switch loop strategies, and generate new capabilities for itself while running—DSH stands as the only solution today that has fully built out the underlying infrastructure. It won’t directly make the AI smarter, nor will it accelerate daily coding speed. What it achieves is making the behavior of the harness itself adaptable and capable of evolution. DSH made a whole feast just for the condiment of self-evolution. Whether the feast tastes good is another matter, but for now, this condiment is truly nowhere else to be found.