DeepSeek Harness (dsh) in 2026: Architecture, Modes, Releases, and Safe Evaluation

Updated September 13, 2026. This guide is based on dsh-v0.1.5-rc.2.

DeepSeek Harness (dsh) is useful to evaluate as an agent runtime, but the current answer to “is it stable enough for production?” is no. DeepSeek labels it developer-preview software, warns that compatibility-breaking changes will occur, and says it has not undergone a security audit or earned a production-ready designation. That does not make dsh uninteresting. It tells you how to use it: pin what you evaluate, isolate what it can reach, and measure your own workload before you trust it with valuable files or credentials.

This guide explains the architecture, separates dsh’s user-facing modes from its CLI profiles, and shows a reproducible evaluation path. It reflects the dsh-v0.1.5-rc.2 repository tag and release page checked on September 13, 2026. Documentation on a moving branch may contain work that is not in the release you install.

What DeepSeek Harness is

The official repository describes dsh as an open-source agent harness developed by DeepSeek AI. A model supplies reasoning; the harness supplies the runtime around it: model adapters, tools, sessions, filesystem and subprocess access, approval policy, settings, and the agent loop.

The design is built on Cordis and its “everything is a plugin” model. In the architecture documentation for this tag, plugins contribute services, typed events, and reversible effects to a shared context. The model adapter, tool registry, session log, and agent loop are all replaceable pieces. A profile then composes bundles and patch files in a defined order.

That distinction is practical. You can change a provider or add a capability through the profile and its patches instead of forking the whole runtime. It does not mean that every component can be swapped safely during any task, or that a plugin failure is isolated from all data the process can access. The safety notice for this tag says model-generated commands and third-party plugins may reach the files, processes, network, and credentials made available to them.

Why the session log matters

dsh records durable session events in an append-only log. The architecture docs identify the session log as the source from which model history is derived, and state that model-visible input must be reconstructable from that log. The official DeepSeek page also describes replay, resume, search, and forking as operations over the same event stream.

This gives a developer something more useful than a vague “memory” feature: a record of what the model was shown and which tool events were committed. It still does not guarantee a deterministic outcome. The model, provider response, tool environment, plugin set, and external systems can all affect the next run. Treat the log as an audit and debugging aid, then validate the behavior you need.

Session format changes also affect upgrade planning. The v0.1.5-rc.1 release notes describe a migration to session format V3. Supported older logs are migrated into a new version while the original is retained, but the notes say an upgraded session cannot be read by a downgraded version. In other words, rolling back the executable is not the same as rolling back session data. Copy the Harness home and test migration on disposable sessions before upgrading a valuable workspace.

The four user-facing modes

DeepSeek’s official Harness page names four modes. They describe how the agent is presented to a user:

Mode	What the official description says	Good evaluation question
Standard	A full coding agent with file editing, Shell, file and web retrieval, Skills, plans, goals, subagents, and workflows.	Can the approval and tool policy contain the tasks you intend to run?
PTC	The Standard capabilities exposed through the Code Mode SDK, so the model can compose multiple tool operations in a TypeScript program.	Does batching operations improve your workflow without making review harder?
Minimal	The official product overview describes persistent bash and str_replace_editor.	Can a small, explicit tool surface complete the task you want to benchmark?
Creator	A mode for inspecting the runtime, experimenting with Cordis plugins in memory, and creating custom Agent presets.	Can you prototype a preset without treating it as a production policy?

The old “Code Mode” label is easy to misread. The official product description calls the mode PTC and explains that it uses the Code Mode SDK. It is not a separate, broadly documented runtime profile called code.

The product overview and the shipped rc.2 profiles use “Minimal” at different levels. In the rc.2 CLI behavior reference, the Web minimal preset composes only the platform’s persistent shell; the other model-facing plugins are absent. The str_replace_editor therefore requires explicit enablement in that Web profile. The rc.1 release notes state the same default for Web minimal and Python sdk-minimal. The Python guide’s existing note below covers its separate sdk-minimal tree and its opt-in editor. Do not infer the editor from the four-mode overview alone.

Modes and CLI profiles are different layers

The command line has its own profile model. The @deepseek-ai/dsh CLI reference for rc.2 says dsh is the supported Node application launcher and lists these shipped profiles:

CLI entry	Role
dsh web	Web UI; an alias for dsh --profile web.
dsh --profile headless "job"	One fresh persisted session that prints its final answer and exits.
dsh --profile sdk	JSON-RPC server for SDK clients over stdio.
dsh --profile sdk-minimal	SDK server with the standalone minimal agent tree.
dsh --profile acp	Automation clients over ACP stdio.

The profiles are ordered plugin-bundle layers. The Web profile can use live patch reload; headless, SDK, SDK-minimal, and ACP apply their layers at startup because replacing dependencies after a one-shot or stdio application owns work would invalidate its lifecycle. A profile name therefore tells you how dsh starts and composes its runtime. It does not map one-to-one to the four product modes.

The rc.2 Python SDK guide makes the distinction even more important. Its sdk-minimal example uses a standalone tree with a persistent shell, no runtime context or compaction, and uncompressed JSONL session logs. The str_replace_editor is opt-in for that profile. The guide also describes the profile as danger-full-access for the visible paths, which is why it calls for an isolated workspace or container. A smaller tool list is not automatically a stronger security boundary.

What changed in the latest release records

On the checked release page, the candidate is v0.1.5-rc.2, tagged dsh-v0.1.5-rc.2 and marked Pre-release. GitHub shows it as released on September 10 at 15:09. The rc.2 notes contain feedback-submission and delivered-file-card UI improvements.

The preceding v0.1.5-rc.1 candidate, released on September 10 at 03:09, contains the larger change set. Its notes include a new DeepSeek model adapter entry, arbitrary file uploads, continuable subagent controls, dynamic system-prompt updates where the model declares support, model discovery improvements, proxy environment handling, session format V3, session locking, default-tool changes, and many fixes including streamed tool-call continuation and Web reconnect behavior.

Those notes tell you what changed. They do not provide an uptime percentage, failure rate, mean time to recovery, or a production reliability result. A long fix list is a reason to read the notes and run regression tasks, not a stability statistic. Also keep three things separate when documenting your test: the GitHub release and tag you selected, the master commit you may have inspected, and the version actually installed in your environment.

A safe, reproducible first evaluation

Use one pinned source path for the evaluation. The commands below follow the rc.2 README and rc.2 CLI reference. They are documented entry points, not commands run for this article.

Create the checkout, a one-time workspace, and a new Harness home before the first launch. The example uses POSIX shell syntax and assumes Git, Node.js, and pnpm are already available as required by the rc.2 README; it does not prescribe unverified runtime versions:

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
git checkout dsh-v0.1.5-rc.2
pnpm install
pnpm run build
export DSH_HOME="$(mktemp -d)"
EVAL_WORKSPACE="$(mktemp -d)"
printf '%s\n' 'Disposable dsh evaluation workspace.' > "$EVAL_WORKSPACE/README.md"
printf 'DSH_HOME=%s\nEVAL_WORKSPACE=%s\n' "$DSH_HOME" "$EVAL_WORKSPACE"

Save the two printed absolute paths in your run notes. Use the displayed EVAL_WORKSPACE path in the Web UI file chooser, and paste the displayed DSH_HOME path into any second shell rather than expecting that shell to inherit the variable. Keep DSH_HOME for this evaluation only. It is where rc.2 creates profile files, settings, credentials references, and sessions. The temporary workspace is separate from the source checkout. Do not put credentials in it, and remove sensitive files from anything the process can see before starting. If the task needs OS-level isolation, put this checkout, home, and workspace inside a disposable VM or container; a dsh workspace picker and approval prompt do not provide that OS boundary.

Start the Web UI from the source root, using the source entry point throughout:

pnpm dsh web --no-open

The rc.2 README documents http://127.0.0.1:3080 as the default local address. In the browser, open Choose workspace and select the exact workspace path printed above. Do not leave the source checkout as the task workspace merely because it was the invoking directory. Then open Settings → Models, configure a model, and run a harmless task that does not touch secrets or production files.

There is a second boundary to understand during this first trial. In rc.2, new sessions in base-backed profiles default to workspace-write: Bash and filesystem mutations are restricted to the session workspace and platform temporary roots, while reads and network access are not confined by that preset. Enabled public HTTP fetches run without a per-call approval prompt. Saved General permission settings apply to later Web sessions, not one that is already open. Verify the setting in a new session after changing it. These are dsh policy details, not OS isolation; keep sensitive resources out of reach before launch.

Before booting another profile or comparing a patch, inspect the same composition with the same source checkout and home:

pnpm dsh --profile web --dump-config

The Web process occupies the first terminal. Stop the service and any active session before copying the home or inspecting a final state; if you open another shell instead, explicitly export the recorded $DSH_HOME path and return to the source checkout before running the command. The rc.2 CLI reference says this initializes missing profile files, prints the composed tree, and does not boot the Web app. Record the tag, source checkout, profile, patch files, model identifier, $EVAL_WORKSPACE, $DSH_HOME, and the task result. The CLI/help and release notes describe behavior; they are not evidence that your local command succeeded.

Configure a model or gateway carefully

The Web UI’s Models page supports built-in providers and custom providers. The rc.2 provider guide requires a custom provider ID, base URL, API protocol, credential, and at least one model. The supported protocol names are openai-completions, openai-responses, and anthropic-messages. Model discovery is only a convenience: if an endpoint does not expose a supported listing shape, enter the model ID manually.

An OpenAI-compatible gateway can still reject a request if its request shape differs from what dsh sends. The provider guide calls out system-prompt role and output-token field compatibility, and says that image or reasoning declarations describe your endpoint rather than testing it. Treat a successful key save as configuration progress, not proof that a real task works.

If you are evaluating Tokenhot as the provider route, its saved Quick Start documents https://api.tokenhot.ai/v1 and Bearer Token/API key authentication for its API setup. In the Web UI, use Settings → Models → Add a custom provider, enter that documented base URL, choose the protocol your selected Tokenhot route actually exposes, and add a model ID you have verified. The provider settings belong to this evaluation’s $DSH_HOME/settings.yaml; the Web UI stores the credential in $DSH_HOME/.credentials.yaml and keeps only its reference in settings. Enter the key through the UI or the documented environment mechanism, never in the disposable workspace or in source control.

Use openai-completions only when the selected Tokenhot route documents or confirms that protocol. Verify the model ID and request shape with your account and workload. The Tokenhot materials available for this article do not establish current model availability, pricing, latency, uptime, or a successful dsh request, so this example makes no such promise.

Upgrade and rollback checks

Before moving from one candidate to another, stop the Web process and any active session, then copy the exact $DSH_HOME used above and the disposable workspace, keeping the copies beside the version record. That home contains the profile, settings, credential references, and sessions that make the comparison reproducible. Read the release notes for changes to session format, default tools, provider adapters, and plugin APIs. Run the same small task on the old and new environments, then compare:

1. Can the Web UI or headless profile start with the intended workspace and model?
2. Are tool approvals shown at the points where your policy expects them?
3. Can the task resume, and does the session log contain the model-visible inputs and tool results you need to inspect?
4. Do your plugins and patches load without configuration errors?
5. Can you restore the copied home and continue using the old session files if the new run fails?

Do not overwrite the only copy of a session while testing a migration. If the new release writes a newer session format, preserve the original alongside it and test downgrade behavior on a copy. Restore the copied $DSH_HOME and workspace together if the new source checkout fails; rolling back only the executable can leave session data in a format the older version cannot read. Promote a version to a valuable environment only after these checks pass for your own files, providers, tools, and approval policy.

Frequently asked questions

Is DeepSeek Harness official software?

The project is published in the deepseek-ai/deepseek-harness organization, is linked from DeepSeek’s official Harness page, and is released under the MIT license. The repository and official page are the appropriate sources for current behavior and release status.

Is dsh an LLM?

No. It is the runtime around a model: providers, tools, sessions, agent loops, policies, and application profiles. You still need a compatible model endpoint and credential.

Which entry should I use for CI?

Start with the documented headless profile for a one-shot command. Give it a disposable workspace and explicit Harness home, pin the version, and test the exact provider and task you plan to automate. Headless execution is an entry point, not a guarantee of deterministic or production-safe behavior.

Does a release fix list prove stability?

No. Release notes describe changed behavior and fixes. They do not measure reliability across a population or workload. Use them to select regression cases, then collect your own results.

Can I route dsh through Tokenhot?

Potentially, if your selected Tokenhot endpoint exposes one of dsh’s supported protocols and the model ID and request shape are compatible. Tokenhot’s documented API setup provides the base URL and Bearer Token pattern; a real compatibility result requires a credentialed request and is outside this guide.

Where should I start?

Read the rc.2 repository README, choose an isolated workspace, and run the Web UI or headless profile against a harmless task. If you need the documented Tokenhot API fields for a provider experiment, follow the Quick Start and verify the model and protocol before drawing a conclusion.