DeepSeek's agent harness is public, but the sampling config isn't in the README

DeepSeek published deepseek-ai/deepseek-harness on 13 August 2026, one day after DeepSeek V4 Pro 0813 appeared on OpenRouter. The harness is called dsh, it is MIT-licensed, and the repository landed with 12,293 commits and roughly 33,000 stars against 2,500 forks. The pitch in the repository description is three words: everything is a plugin.

If you came to that repository looking for the recipe — the tool definitions, the context-window management strategy, the temperature and top-p that produced DeepSeek's agentic numbers — the README does not contain it. What it contains is an install command, a build sequence, a licence, and a pointer to a runtime called Cordis. That gap is the story, and it matters because the model it pairs with is cheap enough that a lot of teams will try to reproduce agent behaviour on it this week.

V4 Pro 0813 is listed on OpenRouter as a large-scale mixture-of-experts model, the GA release of V4 Pro, with a 1M context window at $0.435 per million input tokens and $0.87 per million output tokens. OpenRouter notes it is hosted by a single provider, so there are no routing decisions to reason about. The API is OpenAI-compatible; the only per-model change is the slug.

The verifiable surface of the release is the file tree and the run instructions. The tree carries top-level BENCHMARK.md, AGENTS.md and CLAUDE.md files, plus .agents and .claude directories, docs, examples, packages, native, python, patches and vendor directories. The tooling is a pnpm workspace with multiple tsconfig files and a spread of vitest configurations covering e2e, snapshot, web, web performance and web stress runs, alongside a pytest.ini. So it is a TypeScript monorepo with a Python component, and it has at least one benchmark document — the contents of which are not reproduced in the material published with the announcement.

Running it is two commands. From npm, npx @deepseek-ai/dsh web starts a Web UI served at http://127.0.0.1:3080 by default. From a checkout, it is the usual clone-install-build.

Before you build anything durable on top of it, read the warning DeepSeek put in the README itself.

The single inference parameter DeepSeek has described publicly for V4 Pro is reasoning effort, and it described it in terms of workload class rather than numbers.

Three levels are named. High is the one attached to agent workflows, which is the setting most readers of this post will want as a starting point. The announcement also states native OpenAI Responses API support, though the visible text is truncated before it says what that support is optimised for. The same thread claims major agent upgrades with production gains; no benchmark figure accompanies that claim in the material published with it.

Everything else on the reproduction checklist is unaddressed by the published README, the OpenRouter model page and the launch thread. That includes the shape of the tool schemas the harness emits, whether it uses parallel tool calls, how it handles tool-result truncation, what it does when a session approaches the 1M-token limit, whether it summarises or evicts history, and the sampling parameters — temperature, top-p, penalties, stop sequences — used for the numbers in BENCHMARK.md.

The practical consequence is that the harness is the specification. If you want the benchmarked behaviour through the API rather than through dsh itself, you read packages and docs in the checkout and port the prompt assembly, the tool registry and the request construction by hand. The plugin architecture helps here in one respect: if every capability is a plugin, the boundaries where tools are defined and where requests are built should be legible units rather than one monolithic agent loop. That is an inference from the stated architecture, not something the README confirms.

One thing the OpenRouter page does confirm indirectly: its FAQ carries a question on whether V4 Pro 0813 supports tool calling and structured outputs. The answer text is not in the page content available here, so treat tool-calling support as something to verify against the provider's schema response rather than something established by the listing.

DeepSeek is changing its own API pricing alongside the V4 lineup, introducing peak and off-peak rates where off-peak is 50% lower than peak. The new pricing takes effect at 16:00 UTC on 16 August 2026. The announcement frames this as enabling more flexible workload scheduling, and for batch agentic work — evaluation sweeps, offline document processing, anything where wall-clock latency does not bind — that is a real scheduling lever. The replies to the announcement include complaints from users in Asian time zones that the peak window falls on their working day; DeepSeek has not published the exact peak and off-peak boundaries in the material here.

Four things. What BENCHMARK.md contains and which harness version produced it. Whether the dsh defaults are the same defaults used for any published agentic scores. What the Responses API integration actually optimises. And how fast the plugin interfaces will churn, given DeepSeek's own warning that compatibility-breaking changes are coming.

The reasonable move for anyone building on this now is to pin a commit, treat the harness as a reference implementation to read rather than a dependency to inherit, and keep your own sampling configuration explicit in code so that when DeepSeek does publish the numbers you can diff against them. The model is cheap and the context window is large; the missing piece is the configuration, and it is sitting in a repository you can clone.