DeepSeek Harness Developer Preview Released

DeepSeek Harness Turns Every Agent Component Into a Plugin

DeepSeek Harness v0.1 just landed in developer preview. The complete source code is now public under the MIT license, available as 'dsh' at 'deepseek-ai/deepseek-harness'. That changes how agent runtimes are put together. Instead of a fixed loop with a few extension points, everything from the model to the UI sits behind plugin boundaries, so the old way of thinking about extensibility simply doesn't apply anymore. But the core idea is stated plainly in the README. Everything is a plugin. That one sentence changes how developers should think about building agent systems, and it's the kind of shift that makes you question every assumption you've carried into your own projects.

The timing is notable. It was released alongside a model announcement, but the harness itself is what deserves attention. A harness sits between a model and its environment, managing tools, files, sandboxes, and the control loop that keeps an agent running. Most existing harnesses hard-code that layer. They expose a few hooks, then lock everything else down. DeepSeek Harness does the opposite. Models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI are all swappable through configuration, without touching the source code.

The Cordis Kernel Behind the Curtain

Cordis sits at the foundation. It's a meta-framework, described in the paper *A Programming Paradigm for Spatiotemporal Composability*, and its kernel handles mounting, unmounting, and dependency resolution for plugins. Capabilities live in the plugins themselves, not in a privileged core. So services and events let those plugins talk to each other, and developers pick what they need, swap components in and out, and extend functionality without forking the project. That's the whole trick.

That architectural choice has real consequences. It's a quiet revolution for platform teams. For those building internal tooling, it means they're no longer confined to whatever extension points a vendor happened to expose, and they can replace the session store, swap the sandbox provider, or even rebuild the entire UI without ever waiting on an upstream release.

So the plugin model turns the whole thing into a kit for crafting agent runtimes. Not a fixed product. But a flexible one, and that distinction changes everything about how they work.

Four Runtime Modes for Different Jobs

Four runtime modes ship with the release. Each one loads a different default plugin set. Standard mode is the full coding agent experience, offering file editing, shell access, file and web search, skills, planning, goals, subagents, and workflows all in one package. Code mode exposes those same tools through a Code Mode SDK, letting the model combine multi-step operations into a single TypeScript program, and that's a substantial difference from typical agent loops. There, each tool call is a separate round trip. So it's not just a tweak. It's a structural shift.

Minimal mode strips everything down to two tools: a persistent bash and `str_replace_editor`. It's ideal for benchmarking models in a controlled environment. Creator mode adds runtime inspection, in-memory plugin experiments, and preset-authoring guidance for developers building their own configurations, so each mode serves a distinct purpose without forcing you to change any code to switch. But none of them require code changes. That's the beauty.

Every Session Leaves a Complete Trace

The append-only session log is the standout feature. Everything the model sees gets recorded, including system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection, so there's no blind spot in the chain of actions. The Trajectory view lets developers inspect those records by source. Resume, fork, search, and replay all operate on the same event stream. Most agent frameworks log tool calls, but capturing every context injection is a sharper claim, and it's one that holds up under scrutiny. That level of traceability matters for debugging, auditing, and reproducing agent behavior. So don't underestimate it.

Most agent frameworks log tool calls; recording every context injection is the sharper claim here.

For regulated industries, that traceability is the difference between a pilot and a production deployment. It's the whole ballgame. Financial services and insurance companies need auditable agent runs, while healthcare and pharma R&D teams need to know exactly what the model saw when it made a decision. So the append-only log gives them that record, and the MIT license means they can host it entirely on their own infrastructure, which keeps everything in-house. They can't afford anything less.

Model Routing as a Plugin, Not a Lock-In

Model providers are treated like plugins. That's it. A DeepSeek API key takes effect on the next request, no server restart required, which keeps things fast and frictionless for developers who hate downtime. The installed catalog adds Anthropic and OpenAI by API key. So Bedrock, Vertex, Azure, and Codex demand native credentials: AWS needs keys plus a region, Vertex wants an ADC project, Azure requires an `api-version`, and Codex relies on OAuth, each with its own setup ritual. Custom providers accept any OpenAI-compatible base URL and protocol, and that single flexible standard covers a huge slice of the model hosting ecosystem, from local servers to major clouds. It's simple.

Keys are write-only and stored in `$DSH_HOME/.credentials.yaml`. Settings retain only a credential reference, not the key itself. That design avoids the common mistake of leaking secrets through configuration files or logs. The provider-agnostic approach means teams are not locked into a single vendor, and switching models becomes a configuration change rather than a migration project.

Running the harness is simple. `npx @deepseek-ai/dsh web` starts the Web UI, served at `http://127.0.0.1:3080` by default. From a checkout, the process is `git clone`, `pnpm install`, `pnpm run build`, then `pnpm dsh web`. A Python SDK, called 'deepseek-harness-sdk', requires Python 3.10 or newer, on Linux x64, Linux arm64, or macOS 14+ on arm64. The bundled runtime does not require a system Node.js installation.

Who Should Actually Use This?

This is developer infrastructure, not a production agent product. The v0.1 tag makes that explicit. AI-native startups and platform teams inside mid-to-large enterprises are the primary audience. Regulated enterprises can pilot it locally because it is MIT-licensed and self-hosted, which removes the data-governance objections that plague cloud-only solutions.

Use cases include internal coding agents over private repositories, model evaluation inside a controlled two-tool environment, agent observability and run replay, custom sandbox and approval policies, and packaging house tooling as reusable plugins. Cloud and semiconductor vendors can publish reference agent stacks on top of it. Academic and industrial research labs can use it for benchmarking models with reproducible settings.

The plugin architecture is the real story. A harness where the session store, sandbox, and even the control loop can be swapped out changes the economics of building agent systems. Teams can start with the default configuration, then gradually replace components as their needs evolve. They are not betting on a single vendor's roadmap. They are betting on an open foundation with a clear extension model.

The developer preview status means rough edges are expected. It’s a fair trade. The documentation may have gaps, and the plugin API could shift before a stable release, so you’re betting on patience while the codebase matures. But that’s the cost of getting early access to a genuinely different approach. For teams already building agent infrastructure, the cost of experimentation is low and the potential payoff is high, which makes the risk feel almost negligible. The code is public. The license is permissive. And the architecture rewards curiosity, so dig in before the dust settles.

DeepSeek Harness isn't trying to be the easiest agent framework to learn. It is trying to be the most adaptable one. Those are different goals, and the design choices reflect that priority. The plugin boundaries, the append-only session log, and the provider-agnostic routing all point in the same direction: a runtime that teams can shape to their own needs rather than a product they must adapt to.

Frequently Asked Questions

What is the core architectural principle behind DeepSeek Harness, as stated in the README?

The core architectural principle is that everything is a plugin. This means models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI are all swappable through configuration, without touching the source code.

How does the append-only session log enhance traceability for regulated industries?

The append-only session log records everything the model sees, including system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection. For regulated industries like financial services and healthcare, this traceability is essential for auditing and knowing exactly what the model saw when making decisions, enabling production deployments.

What are the four runtime modes available in the developer preview, and what is the purpose of each?

The four runtime modes are Standard, Code, Minimal, and Creator. Standard mode provides the full coding agent experience with file editing, shell access, search, skills, planning, goals, subagents, and workflows. Code mode exposes tools through a Code Mode SDK for multi-step operations. Minimal mode strips down to two tools for benchmarking, and Creator mode adds runtime inspection and preset-authoring guidance for developers.

How does DeepSeek Harness handle model provider integration, and what are the requirements for adding providers like Anthropic or OpenAI?

Model providers are treated as plugins, and a DeepSeek API key takes effect on the next request without a server restart. The installed catalog adds Anthropic and OpenAI by API key, while Bedrock, Vertex, Azure, and Codex require native credentials like AWS keys, ADC project, api-version, or OAuth. Custom providers can use any OpenAI-compatible base URL.

Who is the primary target audience for DeepSeek Harness, and what use cases are highlighted in the article?

The primary audience is AI-native startups and platform teams in mid-to-large enterprises, especially regulated ones that can pilot it locally due to its MIT license and self-hosting capability. Use cases include internal coding agents over private repositories, model evaluation in a controlled two-tool environment, agent observability and run replay, custom sandbox and approval policies, and packaging house tooling as reusable plugins.