In August 2026, DeepSeek released the source code for a project called DeepSeek Harness, or DSH. Within two days, the repository was closing in on 100,000 GitHub stars. The codebase ran to roughly 453,000 lines and was released under the permissive MIT licence.
The launch was impressive. But the more important question is not how quickly the repository went viral. It is why AI agents remain so unreliable even as the models behind them become dramatically more capable.
The emerging answer is that the model is only part of the system. The harness around it—the software that manages tools, memory, context, retries, permissions and the agent loop—can be just as consequential.
Composio tested the same DeepSeek V4 Flash model across eight agent harnesses on a set of 30 tasks. The best-performing setup completed 20 tasks, a success rate of 66.7 per cent; the weakest completed 14, or 46.7 per cent. Nothing about the model changed, yet the choice of harness produced a 20-point gap in success rate. The cost of completing a task also varied by as much as sevenfold.
OpenAI found something similar on ARC-AGI-3. With the benchmark’s standard harness, GPT-5.6 Sol scored 13.3 per cent on the public task set. When OpenAI enabled retained reasoning and context compaction—the same capabilities used in ChatGPT and Codex—the score rose to 38.3 per cent while output-token use fell by a factor of six. As OpenAI put it, benchmarks rarely measure a model in isolation; they also measure API settings, prompting and harness design.
These results point to a shift in the AI industry. For agents, the bottleneck is no longer simply intelligence. It is systems engineering.
Why capable models still make unreliable agents
There are three recurring reasons.
First, small errors compound.
An agent makes a series of probabilistic decisions. Even if each step has a 95 per cent chance of being correct, the probability of completing a ten-step task without an error is only about 60 per cent. The longer the task, the more opportunities there are for one mistaken assumption, tool call or edit to derail the entire run.
This is not merely a question of whether the model is clever enough. A production-grade agent needs an architecture that detects errors, preserves state, retries intelligently and recovers from failure.
Second, context becomes crowded.
A full agent can expose dozens of tools to the model. Every tool comes with a description, a schema, parameters and usage rules, much of which must be supplied in the context. As the toolset grows, the model receives more capability—but also more noise. It becomes easier to choose the wrong tool, misuse a parameter or overlook a relevant instruction.
That is not a conventional software bug. It is a consequence of putting a finite attention system in charge of an expanding interface.
Third, long-running tasks can enter a failure spiral.
As a task grows, so does the working context. The model may lose track of the original goal, repeat previous steps or bounce between two partial solutions without making progress. Anyone who has watched a coding agent repeatedly inspect and rewrite the same files has seen this pattern: a longer task creates a larger context, and the larger context makes the task harder to finish.
All three problems live at the boundary between the model and the surrounding system. That raises a more useful question than “Which model is smartest?” What should a harness look like if it is designed to contain uncertainty rather than merely expose more tools?
DeepSeek’s answer: everything is a plugin
DeepSeek Harness is built around a simple but unusually radical idea: everything is a plugin.
This is not marketing shorthand for an app store. In DSH, the model adapter is a plugin. So are the tool registry, session log, sandbox, storage layer, scheduler and web interface. Even the agent loop—the logic that decides when the model is called and how a task advances—is implemented as a plugin.
That last point matters. In most agent products, the loop is the privileged core. Developers may be allowed to add tools, hooks or skills, but they cannot easily replace the logic that orchestrates the agent. DSH removes that privilege. The loop is another component that can be selected, extended or swapped.
In principle, this means a team can change models without rebuilding its tools, change the interface without rewriting the loop, or create a specialised runtime with its own memory, security and retry policies. The system is less a finished coding assistant than a kit for assembling one.
DSH ships with several operating modes that illustrate the trade-offs.
- Standard mode provides the full coding-agent toolset, including file editing, shell access, search, planning, skills, goals, subagents and workflows.
- Minimal mode keeps only a persistent shell and a file editor. It is intended for benchmarking and for reproducing behaviour with as little harness assistance as possible.
- Code mode allows the model to write TypeScript that combines multiple operations. Instead of making five separate tool calls—re-reading and reconsidering the context after each one—the model can package those steps into one programme and return only the result.
- Creator mode exposes the runtime itself, allowing developers to inspect loaded capabilities, experiment with plugins and build custom agent presets.
Minimal mode addresses a problem that AI benchmarks often obscure: a reported score may reflect the model, the harness or both. Removing most of the orchestration layer does not produce a perfectly “pure” model score—no evaluation is entirely harness-free—but it makes the source of performance easier to interpret.
Code mode tackles a different problem: the token cost and instability of repeated tool round-trips. If intermediate results do not all need to enter the conversation history, a small programme can be both cheaper and less distracting than a long chain of model decisions.
DSH also makes several less visible engineering choices. Its session log is append-only, while the model can operate on compressed projections of that history. Compaction changes what the model sees without destroying the original record, so a run can be inspected or reconstructed later. Turn-ending events carry structured reasons, making it possible to distinguish a completed task from a model refusal, an error or a system limit. In restricted configurations, the project also favours fail-closed behaviour: if an expected sandbox is unavailable, the safer response is to refuse execution rather than silently continue without protection.
These choices are not glamorous, but they address the central problem of agent engineering: how to make probabilistic behaviour observable, attributable and recoverable.
How DSH differs from Claude Code and Codex
Claude Code, Codex and DeepSeek Harness are often grouped together as coding agents, but they embody different product philosophies.
Claude Code is a tightly integrated, largely closed product optimised around Anthropic’s models. Its strength is application-level curation: most architectural choices have already been made, and users receive a tool that works with relatively little assembly.
OpenAI’s Codex harness, which the company presented as an open platform in August 2026, is available under the Apache 2.0 licence. It exposes the execution layer behind the Codex app, CLI and IDE experiences, including context management, tool calls, sandboxing and multi-turn state. It is open and extensible, but its core design remains closely aligned with OpenAI’s model and product stack.
DSH takes the opposite approach. It does not treat any single model, toolset or loop as mandatory. Claude Code and Codex resemble carefully configured systems: highly usable, strongly opinionated and optimised as a whole. DSH resembles a custom-built machine: almost every part can be replaced, but the user—or the agent—must understand how those parts fit together.
This is more than a difference in maturity. It is a difference in kind. DSH is not simply trying to be another coding agent. It is trying to become infrastructure for building agents.
Cordis and the problem of clean removal
“Everything is a plugin” sounds elegant until an engineer asks the obvious question: can those plugins actually be removed cleanly?
Traditional plugin systems are notoriously untidy. Install an extension in an editor and it may register commands, cache data, modify configuration and create dependencies on other extensions. Removing it does not always reverse every side effect. A restart may be required, and orphaned state often remains.
That is inconvenient when plugins are installed occasionally by people. It could become dangerous if agents begin creating, installing and replacing plugins dynamically. A small amount of residue from each temporary component would eventually leave the runtime in an unpredictable state.
Cordis, the framework beneath DSH, is designed to address that problem. Its theoretical foundation is described in the preprint “A Programming Paradigm for Spatiotemporal Composability”, written by researchers affiliated with DeepSeek and Peking University.
The paper separates composability into two dimensions.
Spatial composability concerns dependencies between components. A component should be able to declare what it needs, discover compatible services and react when those services change. Replacing one implementation should not cause dependent components to fail silently.
Temporal composability concerns reversibility. When a component is removed, the effects it created should be undone completely and safely. Removal should not merely mark a plugin as inactive; it should reverse registrations and side effects in a controlled order.
Cordis manages each plugin inside a fibre with an explicit lifecycle: PENDING, LOADING, ACTIVE, FAILED, UNLOADING and DISPOSED.
A plugin whose dependencies are not yet available remains PENDING rather than loading into a broken state. Once a fibre reaches DISPOSED, it is finished; it cannot unexpectedly reactivate. Cleanup functions run in reverse registration order, helping preserve dependency integrity while the component is dismantled.
This may sound like an overly elaborate solution to plugin hygiene. In the context of self-modifying agents, however, it begins to look like foundational infrastructure.
Conventional software assumes that people write components and change them relatively infrequently. A future agent may generate dozens of temporary tools during a single assignment, compose them for a particular purpose and discard them minutes later. If those operations are to be safe and repeatable, the runtime needs stronger guarantees than today’s plugin ecosystems typically provide.
Cordis is therefore not primarily solving the question, “Are plugins convenient today?” It is addressing a harder question: “Can a system remain coherent when software begins continuously rewriting its own toolset?”
An architecture built for AI, not necessarily for people
The ambition is considerable. The reality is much messier.
By early September, the DSH repository had attracted more than 200,000 GitHub stars. Yet an audit by the Chinese technology publication LeiPhone found that the apparent plugin ecosystem was far thinner than the headline numbers suggested. Of 11,439 repositories carrying the dsh-plugin topic, only 2,143 followed the packaging rules well enough to be installed, and only 955 showed evidence of real use.
The ecosystem had another revealing weakness. DSH’s most distinctive feature is the ability to replace the agent loop itself, yet the audit found only two community projects attempting to do so. The part of the architecture that is most technically novel is also the part that ordinary developers seem least interested in changing.
This is a familiar open-source problem. Architectural freedom is not the same as accessible utility. Most users do not want to design an agent runtime; they want an agent that completes the task.
Security is a more immediate concern. DSH presents three file-access settings: read-only, workspace-write and danger-full-access. LeiPhone created a minimal probe plugin and ran nine tests under all three settings. According to the report, every test succeeded in every mode. Even in read-only mode, the plugin could list files under ~/.ssh, read an API key from the environment, write to /tmp and connect to the internet.
The reason is architectural. The permission settings mediate actions requested by the model through DSH’s tools. A plugin does not need to make the same request because it runs as part of DSH itself. The security gate checks the visitor; the plugin is treated as a colleague with the same operating-system privileges as the host process.
That does not make DSH uniquely careless—native plugins in many developer tools carry broad privileges—but it does make the label “read-only” easy to misunderstand. Anyone installing a third-party DSH plugin should treat it as executable code, not as a constrained model capability.
Put the numbers together and DSH can look like a project that is technically sophisticated but commercially premature: enormous attention, a much smaller usable ecosystem, minimal adoption of its most radical feature and a plugin security model that requires considerable trust.
There is, however, another way to read the same evidence.
What if the plugin system is not ultimately intended to be authored mainly by a human community?
The longer-term bet may be that models themselves will write, install, combine and replace plugins. Humans would no longer need to assemble every component manually. In that world, 955 active users would not necessarily demonstrate failure. It might simply mean that the infrastructure has arrived before the behaviour it was designed to support.
The bet behind DeepSeek Harness
The logic can now be traced end to end.
Models are becoming more capable, yet agents remain unreliable because intelligence alone does not solve compounding errors, context overload and long-horizon drift. DSH answers those problems with an architecture in which every capability can be recomposed. Cordis attempts to make that dynamism technically viable by tracking dependencies and reversing component effects. The final wager is that these mechanisms will matter most when agents, rather than people, become the primary authors and consumers of plugins.
No one yet knows whether that wager will pay off.
A plugin architecture can be elegant and still fail to produce a healthy ecosystem. A self-modifying agent can be powerful and still create unacceptable security risks. Open infrastructure can attract experimentation without displacing more polished, integrated products. DeepSeek will also have to compete with OpenAI, Anthropic and a growing field of open-source agent frameworks, all of which are moving quickly.
But DSH has made one possibility concrete: when AI systems begin building their own tools, they will need infrastructure capable of surviving constant composition and removal. Cordis’s lifecycle management, DSH’s append-only event log and its preference for traceable execution can look excessive today because few agents genuinely use them at scale. If agents begin to modify their own runtimes routinely, those mechanisms may turn out to be the foundations rather than the ornamentation.
Whether DeepSeek becomes the company that establishes this layer is still uncertain. What is already clear is that competition in AI is moving beyond the question of who has the strongest model. The next contest is over which system can turn intelligence into reliable action—and eventually allow that system to reshape itself.
That contest has only just begun.