DeepSeek Harness releases experimental Claude Mods compatibility layer, lead says it validates subset claim

The starting point of this discussion is that Anthropic pushed a brand-new extension mechanism called Mods for Claude Code, allowing developers to deeply customize the interface and intercept tools through in-process Function Hooks. Then, less than 24 hours later, DeepSeek pushed the DeepSeek Harness (dsh) v0.2.1-alpha.1 version update to its GitHub repository.

What really pushed this update into the spotlight was a sentence in the changelog: it added an experimental Claude Code Mods compatibility layer, and the main purpose at this stage is to verify that Claude Code Mods API functionality is roughly a subset of DeepSeek Harness plugins, rather than to provide users with actual full compatibility. The commit log clearly notes that this compatibility layer was personally authored and signed by team lead Cui Tianyi (@tianyicui).

Therefore, understanding this move as "DeepSeek wants full compatibility with Claude Code Mods" is not accurate. According to the changelog's wording, it is more like an architectural comparison experiment: using code to test which of the two extension systems' capability boundaries contains the other.

From a systems engineering perspective, the technical essence of this compatibility layer is a cross-runtime API semantic bridge layer (API Shim). DeepSeek Harness is built on the open-source microkernel framework Cordis; the kernel itself has no privileges, and all modules run through service publication, dependency injection, and event subscription.

What Cui Tianyi did within those less than 24 hours was essentially write an adapter plugin on top of Cordis: mapping the TypeScript Hook functions defined by Claude Code Mods onto DSH's event bus and lifecycle.

This also explains why the "subset" judgment can be verified through engineering means—if all of Claude Code Mods' extension primitives can find corresponding positions in DSH's event and lifecycle model, then the "subset" relationship holds at least at the level of extension primitives.

To verify the "subset" claim, the DSH team directly used the three upstream benchmark examples officially provided by Anthropic for acceptance testing: Token Weather verifies interface rendering capability, drawing token consumption status losslessly onto the terminal; Blast Radius verifies high-risk operation interception, suspending before the shell executes destructive commands and requiring confirmation; Replay Theater verifies event recording and playback of operation history and file Diff changes.

Reports say all three official use cases ran successfully, proving that Claude Mods' existing extension primitives can all find corresponding mappings within the DSH system. It should be noted that this "all ran successfully" currently comes from the reporting party's statement and lacks independent first-party verification, so it can only be treated as a source claim.

Even if this claim holds, what it proves is only mappability at the level of extension primitives, not full compatibility at the user level. The gap between these two things is exactly the hard limitation discussed in the next section.

The DSH documentation is quite candid: several of Claude Code's most prominent official built-in capabilities, such as the /diff panel and agents.md cross-agent specification parsing, explicitly cannot run within the DSH compatibility layer.

The reason given by the report is that this is not because the bridge layer was written too slowly, but because the two systems have objective architectural differences in their terminal rendering engines and main state machine definitions. In other words, what can be bridged are extension primitives; what cannot be bridged are built-in capabilities deeply rooted in their respective rendering and state machines.

This also constitutes an important qualification to the "subset" claim: the scope in which the subset relationship holds is the extension capabilities available to plugin authors, not all of Claude Code's functionality. Treating the former as the latter would overestimate the actual coverage of this compatibility layer.

Facing intense discussion, Cui Tianyi gave a systematic response in the Zhihu community, confirming that he is the author of the compatibility layer and stating that it is an experimental feature in the alpha version, still has many imperfections, and cannot guarantee 100% compatibility.

He explicitly stated that it currently cannot make all Claude Code Mods run seamlessly in DeepSeek Harness; if this is considered a goal worth investing in, it is technically possible to achieve in the future. This means that "whether to pursue full compatibility" remains an open question, depending on whether the team considers it worth investing in, and there is no clear plan yet.

Regarding the philosophy of "everything is a plugin," Cui Tianyi said it was established from the very beginning of the project, before the first line of code was written, and that open source was also a direction established at the founding of DeepSeek, not something forced or imitated from others. This statement is his personal account and can serve as a clue for understanding the team's motivation, but it is not equivalent to independently verifiable fact.

Cui Tianyi places another layer of potential in the plugin architecture further out: letting the Agent change itself during operation, exploring the co-evolution of the model and the Harness. He said that DSH's "Creation Mode" already allows the Agent to write and install plugins according to user needs, extending the Harness's capabilities and interface, which is a small step in the direction of "words become law."

But he also pointed out that advancing "Agent self-evolution" requires more complete engineering implementation of plugin hot-swapping and hot-reloading, and on the model side requires training large language models in new ways so that models learn to self-iterate by changing their own Harness; the related work has only just begun.

Here it is necessary to distinguish two levels: Creation Mode can already let the Agent write plugins, which is the current capability; while letting the Agent achieve self-iteration by rewriting its own Harness is a goal for which specific training methods and experimental progress have not yet been publicly disclosed. Treating the former as the latter would misread the current progress.

Regarding enterprise deployment, Cui Tianyi revealed that developers have already used DSH plugins to build "AI workbenches" for specific industries. These industry plugins are generally not publicly open-sourced, but they comply with the MIT open-source license, and the team explicitly supports and recognizes them.

This actually draws a boundary: what is open-sourced is the foundational framework and extensibility, which does not mean enterprises must disclose their own industry plugins. However, how to further develop the public plugin community and achieve cross-framework compatibility has not yet been given a specific plan in this response.

There is another detail from the report's paraphrase: the first version of dsh already had a built-in plugin that can call Claude Code and Codex as subagents, disabled by default, and a design record from about two months ago shows that DSH has two built-in Subagent Providers. This detail has not been corroborated by first-party documentation and can only be treated as a source claim.