dshbase

Blog · Guide

The five layers under your dsh config: field notes on the patch stack, PTC savings and the skills wart

August 31, 2026 · dshbase · rewritten field note

Rewritten guide based on facts and observations in the WeChat article DeepSeek Harness 上手记 (account: 龙门小站), cross-checked against dshbase's own plugin testing. The Composio cross-evaluation figures are attributed second-hand and not independently reproduced.

Source clue (WeChat via Sogou; not a verbatim reprint) — Rewritten guide based on facts and observations in the WeChat article DeepSeek Harness 上手记 (account: 龙门小站), cross-checked against dshbase's own plugin testing. The Composio cross-evaluation figures are attributed second-hand and not independently reproduced.

A two-week field report circulating in the Chinese community got one thing right that most architecture deep-dives miss: DeepSeek Harness is easy to install and easy to mis-configure, and the failure modes live in the config layer. We reconstructed the parts that matter for installers, added what our own testing shows, and flagged one claim we cannot verify.

Same model, different shell: the 47 vs 67 figure

The report opens with a Composio cross-evaluation from August 10: the identical DeepSeek V4-Flash model, 30 real multi-step tasks, pass rate swinging between 47% and 67% depending on which harness wrapped it, with per-task cost varying up to 7x. We cannot independently verify Composio's numbers, but the direction matches what dshbase sees constantly: the runtime around a model moves outcomes more than small model swaps do. Choosing dsh is choosing the shell, not the brain.

Your config is five sheets of paper, not one file

Most tools keep settings in one file you edit until they break. dsh stacks layers, bottom to top: the factory cordis.yml (an empty array, officially marked do-not-touch), then each bundle's patch — dsh-base brings core abilities, dsh-web-app brings the interface — then your profile's cordis.patch.yml, then any CLI --patch flags, which can repeat and win over everything. The practical consequence: your customizations all live in one transparent sheet on top, so an upstream bundle upgrade reflows everything beneath it without touching your edits. When debugging, stop guessing which layer set a value and read the composed tree with dsh --profile web --dump-config.

Two keys, one drawer

When wiring a model provider, prefer the apiKeyEnv form — the config stores only the name of an environment variable, and the secret itself stays out of a file you might paste into an issue or commit by accident. The apiKey form writes the literal secret into YAML. Community experience shows configs getting shared far more often than intended. Treat anything inside the workspace folder as readable by the model too: no .env files, no SSH keys in there.

MCP tools get a prefix, and a startup cost

Native MCP servers appear to the model as names like mcp__github__create_issue, one client instance per server, stdio being the simplest transport. Two operational notes from our testing: every tool schema ships in the request prefix, so an oversized MCP set inflates cost and can bust KV cache on any change; and connection failures currently surface as a generic error — a wrong path cost one community author half an hour. Pin versions and start with one server.

What PTC actually changes

Of the four modes — Standard, PTC, Minimal, Creator — only PTC confuses people, because it changes not the capability list but the calling style. Normally every tool round-trip goes through the model. PTC exposes a single run_code tool, wraps the rest as a programming interface, and lets the model write one program that chains ten file reads locally and returns only the summary. Intermediate content never enters the context window, which is where the reported roughly-half token saving on batch jobs comes from. Permission checks, audit and timeouts still apply per call. Minimal mode, for completeness, is DeepSeek's own evaluation rig shipped open: shell plus text editor only, useful for benchmarking models or learning what an agent loop really is.

The wart: skills only load from one hardcoded path

Everything-is-a-plugin ends where skills discovery begins: dsh scans the global claude skills directory only, so project-local skill folders need manual symlinks to be seen. For a runtime whose whole thesis is reconfigurable composition, a hardcoded scan path is the sharpest inconsistency we have seen, and it is the top papercut reported across community write-ups. Until it changes, keep a small sync script for repo skills.

Realistic expectations

The runtime sits between release candidates and alpha versions; breaking changes are documented, not hypothetical. The TUI profile has launch reports that fail on some machines — the web profile is the maintained path. None of this argues against installing: pin your version, keep your edits in the patch layer only, and the upgrade churn stays survivable.

On dshbase

Before installing random GitHub plugins, check the verified directory and audit notes.

All articles →