DeepSeek Harness Is Not DeepInfer: The Layer Above Inference

If you read the DeepInfer release note, you know what DeepSeek open-sourced in October: an inference engine for one model, DeepSeek-V4.1-Flash, with optimized kernels and a deliberate gap where the serving layer should be. DeepSeek Harness is a different project from a different month. It is an agent harness, not an inference engine. The distinction matters because teams keep evaluating them as if they were alternatives.

They are not. DeepInfer answers “how do I turn a prompt into tokens efficiently?” DeepSeek Harness answers “how does an agent keep working after the model returns?” A production agent needs both answers, plus a third one: which tools can the agent actually call?

Four layers, not two

The fastest way to stop comparing the wrong things is to draw the stack. DeepSeek's 2026 releases sit at different layers, and each layer has its own failure modes.

DeepInfer is an offline engine. It does not host an API, does not run an agent loop, and supports one model. DeepSeek Harness is a local-first runtime. It does not ship weights, does not train a model, and does not serve tokens by itself; it calls whichever model provider you configure. Calling one “better” than the other is a category error, like comparing a database to an ORM.

The useful question is where your bottleneck is. If you are tuning prefill/decode on SM100 or Ascend 950, you are in DeepInfer's layer. If your agent starts, plans, calls a tool, gets a result, and then has to decide what to do next, you are in dsh's layer. Most teams eventually need both, and the boundary between them is a provider configuration.

What dsh actually ships

DeepSeek Harness, usually shortened to dsh, is an MIT-licensed agent harness. Its repository went public on 13 August 2026, two months before DeepInfer. It is in developer preview, and the README warns in capitals that compatibility-breaking changes are coming. That warning is not decoration; pin versions before you build a workflow on it.

The architecture is the interesting part. dsh is built on Cordis, and its organizing idea is “everything is a plugin.” The model adapter, tool registry, session log, sandbox, storage, agent loop, and even the Web UI are plugins. A running instance is a tree composed from profiles and bundles, and a patch can replace one row without forking the core. If you have ever maintained a fork of an agent framework just to change its tool policy, this is the design that avoids it.

Out of the box, the Web profile gives you a local UI:

npx @deepseek-ai/dsh web

The server starts at http://127.0.0.1:3080. You add a model provider in Settings, choose a workspace, and start a session. The harness records what the model sees in an append-only session log, which is what makes trajectory inspection, resume, fork, and replay possible. The same log is the audit trail when an agent does something surprising.

dsh also ships the unglamorous parts that make an agent usable: a scoped tool registry with a guarded execution pipeline, approval policy, and sandbox modes that range from read-only to full access. Those are not features you notice when everything works. They are the features you notice when a tool call goes wrong.

What it doesn't ship

The list is short, and none of it is a criticism. It is a boundary statement.

• No model. dsh does not include weights, does not train, and does not host inference. You bring a provider.
• No hosted service. The Web UI binds to localhost by default. This is a tool you run, not a managed platform with an SLA.
• No guaranteed API stability. Developer preview means what it says. Core plugins and configuration can change between releases.
• No long tail of SaaS connectors. The tool registry is a seam, not a catalog. Ad platforms, CRMs, storefronts, and inboxes arrive as plugins or MCP servers, each with its own auth, schema, rate limits, and billing.

That last point is where most agent projects slow down. The harness is good at giving the model a loop. The loop is only as useful as the actions it can take. A coding agent needs repository tools; a go-to-market agent needs keyword data, ad accounts, social platforms, a CRM, and a storefront. Those integrations are not one problem. They are dozens of small problems with different credentials and different failure modes.

The tool gap is the real integration project

“MCP support” is often treated as the finish line. It is closer to the starting line. An MCP server gives the agent a protocol; it does not give you a catalog, a shared credential model, per-call pricing, or a single bill. If you connect ten providers directly, you own ten OAuth flows, ten schemas, ten retry policies, and ten invoices. The agent works in the demo and becomes an operations project in production.

There are two honest ways to close that gap. The first is to build and maintain the connectors yourself. That is the right call if you have one workflow, tight security requirements, and engineers who want full control. The second is to connect through a layer that already aggregates the long tail, accepting a dependency and a per-call cost in exchange for not rebuilding every integration.

SpringBrand is one example of the second approach. It publishes an OAuth MCP client plugin for dsh, springbrand-lab/dsh-oauth-mcp-client, with browser sign-in, persistent credentials, automatic reconnects, and a bundled SpringBrand MCP connection. The marketplace behind it exposes 10,000+ APIs and plugins across ads and SEO, social platforms, e-commerce, sales and CRM, and customer support, with one account and one bill.

If you want to see how the connection is wired, SpringBrand's DeepSeek Harness setup guide walks through the install prompt and the browser OAuth step. Treat the plugin like any third-party code: it is not part of the DeepSeek repository, and you should read it before granting it access to a workspace that can reach your files or accounts.

A checklist before you connect anything

Whether you use SpringBrand or build your own layer, the failure modes are similar. This is the checklist I would use before giving an agent a new capability.

1. Pin the dsh version. Record the exact release and profile. Developer preview changes can invalidate a working configuration.
2. Choose the sandbox per task. Read-only for research, workspace-write for coding, full access only when you can explain why. Do not give an unvetted plugin more access than the task needs.
3. Separate the four layers in your metrics. Model latency, inference throughput, harness overhead, and tool latency are different numbers. A slow agent is not always a slow model.
4. Audit the plugin and its scopes. Prefer OAuth with narrow scopes over long-lived static keys. Read the source before it can reach your filesystem.
5. Keep the session log. The append-only log is the only reliable way to reconstruct what the model saw and which tool returned what.
6. Start with one real workflow. “10,000 APIs” is a catalog, not a strategy. Connect the two or three tools a real task needs, measure the result, then expand.

FAQ

Sources

• DeepSeek Harness repository — README, license, developer-preview notice, run command.
• DeepSeek Harness architecture — Cordis, profiles, bundles, plugin tree.
• DeepSeek Harness safety notice — sandbox and approval guidance.
• dsh on npm — package and release history.
• DeepInfer repository — the inference layer this site covers.
• SpringBrand DeepSeek Harness guide — the plugin and marketplace referenced above.
• DeepInfer Limits — why the inference engine is not a full serving stack.

Next: how DeepInfer is put together, or the comparison hub.