Over the past two days, the AI developer community has been almost entirely flooded by the same name—DeepSeek Harness, which the community more commonly calls dsh. It has only been open source for a mere 2 days, yet it has already racked up nearly 100k Stars. At this rate, it might genuinely have a shot at catching up to OpenClaw's Star count. But what I care about more isn't the numbers—it's a question: why would DeepSeek build its own Harness? What essential difference does it have from the Claude Code and Codex I'm used to? To answer this question, I went all-in and tested it for an entire day, from installation, configuring the Key, selecting directories, and adjusting permissions, to staring at the task trajectory as it worked step by step. I noted down all the pitfalls and the highlights. This tutorial is aimed at application developers who are just getting started. I'll break down the design philosophy of "everything is a plugin," walk through the complete onboarding path for dsh web step by step, and also tell you which few spots are most likely to scare people off. After reading, you'll at least be able to get dsh running independently and know what's actually moving behind each switch.
Starting from "the model is the brain": why DeepSeek built its own Harness
To understand the significance of DeepSeek Harness, we first need to clarify the word "Harness." Many beginners are baffled the first time they see this word, because it's neither like a framework nor like an SDK. Actually, a very straightforward analogy works: the model is the brain, and the Harness is the model's body. No matter how smart the brain is, without hands to type commands, without eyes to read files, and without memory to remember what happened earlier, it's just a thinking machine that can chat. What the Harness needs to do is equip this body completely: give it hands that can call tools, eyes that can read files and directories, a memory system that can manage context, and a set of guardrails that constrain its behavior.
Building on this analogy, if we re-dissect the already familiar concept of an Agent, we get a very clean formula: Agent = LLM + Harness. Here the LLM is responsible for "thinking," and the Harness is responsible for "doing." The thinking part is a matter of model weights, while the doing part is a matter of engineering—how tools are registered, how results are fed back, how context is compressed when it overflows, and whether dangerous operations should be intercepted. In the past, when we did AI application development, the vast majority of our energy actually went into the "doing" half, that is, writing our own Harness. This also explains why everyone was so excited when the dsh framework came out: it directly open-sourced the Harness layer, while leaving a sufficiently large opening for modification.
Now let's talk about DeepSeek's role shift this time. Previously, when we used DeepSeek models, the path was basically plugging it into an Agent that someone else had already built—whether an open-source Agent framework or some Coding Agent, DeepSeek only played the role of "the brain being called," and the body was provided by others. The situation for model vendors was actually somewhat passive: no matter how strong their own model's capabilities were, the final results were still constrained by the host Harness's tool design and context strategy. When users complained about lag, the blame might not lie with the model at all. This time, DeepSeek entered the arena itself and built an Agent framework specifically for its own models, which amounts to taking the power to adapt the "brain" and the "body" back into its own hands. The official entry point is at https://www.deepseek.com/harness/, where you can find installation instructions and documentation.
And its coolest aspect can be summed up in five words: everything is a plugin. This is not a marketing slogan, but a very concrete architectural decision. In dsh, models, tools, strategies, storage, sandboxes, context management, and even the UI are all abstracted into plugins that can be assembled and disassembled like building blocks. You can swap only the tools without touching the model, or swap only the context strategy without touching the UI. The value of this freedom lies in this: it turns "reassembling an Agent" into a configurable matter, rather than a project rewrite. For beginner developers, you can even start without writing code, and through configuration and composition understand how the various components of an Agent interlock.
To make "everything is a plugin" more concrete, I've broken it down into several replaceable component dimensions, comparing the traditional approach with dsh's philosophy:
| Component Dimension | Traditional Self-Built Harness Approach | dsh's "Everything is a Plugin" Philosophy |
|---|---|---|
| Model | Hard-code a specific vendor's API and parameters in the code | As a replaceable plugin, swapping models doesn't affect other parts |
| Tool | Hand-write function registries and JSON Schema | 100+ built-in plugins, enable or replace as needed |
| Policy | Permission checks scattered across tool implementations | Centralized as policy plugins, unified permission tier management |
| Storage | Connect to a database or local files yourself | Abstracted as storage plugins, implementations are swappable |
| Sandbox | Set up containers or VM isolation yourself | Sandbox capabilities are plugin-based, isolation strength is adjustable |
| Context Management | Write your own truncation or summarization logic | Context management is plugin-based, compression strategies are swappable |
| UI | Build your own frontend or only provide a CLI | UI is also a plugin layer, with an official Web UI provided out of the box |
This table actually answers a common question: why dsh is worth learning separately rather than just continuing to use an off-the-shelf Agent. Because what you learn isn't just "how to use a tool," but "what components an Agent is assembled from." This mental model works with any framework.
dsh web is not a CLI: the installation path to open a Web UI with one command
Now let's get hands-on. First, installation. This time I used a rather "AI Native" approach: if AI can do it, let AI do it. I didn't read the installation docs line by line; instead, I opened my usual Agent and sent it this natural language prompt:
Help me install DeepSeek Harness https://www.deepseek.com/harness/The key to this prompt is including the official link, so the Agent reads the installation instructions on the page itself and then decides what commands to run. The whole process took me about 5 minutes to install, with basically no intervention in between. This experience itself is quite symbolic: dsh's installation can be completed by another Agent, which shows that its exposed interfaces are clear enough and programmatically understandable.
After installation, run this command:
dsh webThen the browser automatically opens a web page. To be honest, I was a bit confused at first. Because in my expectations, dsh would either be a CLI Coding Agent like Claude Code, or a desktop application like Codex, but what it opened was a Web UI. This was indeed a bit unexpected, and counts as another round of innovation from DeepSeek in terms of interaction form.
It's worth clarifying the differences between the three forms, because the form directly determines how you can use it and who it suits:
| Form | Representative | Interaction Entry Point | Barrier to Entry and Target Users |
|---|---|---|---|
| CLI Command Line | Claude Code | Type commands in the terminal | Relatively high barrier; handy for heavy developers |
| Desktop | Codex | Standalone App window | Medium barrier; suited to developers used to graphical interfaces |
| Web UI | DeepSeek Harness (dsh web) | Local page opened in the browser | Relatively low barrier; the page is the workbench, but the settings are somewhat hardcore |
Choosing the Web UI has an easily overlooked benefit: it's naturally suited to laying out information like "conversation history," the "task area," and the "task trajectory" all on the same screen, giving a much higher information density than scrolling output in a terminal. But it's also a double-edged sword—once there are many elements on the page, beginners can find it hard to know where to start. So in the next section I'll first get the most critical thing—connectivity—working.
One more small engineering reminder: dsh web essentially starts a local service, and the browser is just a frontend shell. This means whether the page works depends on whether the dsh process behind it is still alive. I'll cover a specific pitfall about this later, but for now just note: when a task gets stuck, your first reaction should be to check the process in the terminal, not to stare blankly at the timer on the web page.
After You Have the API Key: Enter the Key, Top Up the Balance, and Get the First Conversation Running
The web page is open, but at this point it still can't do any work. To get dsh actually running, you must complete the following three steps in order; missing any one of them means it won't work:
- Go to the official DeepSeek API platform and create an API Key.This is the credential dsh uses to call the DeepSeek model; without it, it's like the brain isn't connected.
- Copy and paste the Key into the dsh web page.The page will provide an entry field; after pasting and saving, dsh has the credentials to call the model.
- Top up your DeepSeek account in advance.Tokens consumed by calling the model are billable, and requests will fail when the balance is insufficient.
Let me describe these key spots on the page in words so you can find them by comparison: after entering the dsh page, on the left is the familiar conversation history area; in the middle is the task area, where you can choose the working directory and run mode; the entry for filling in the API Key is in the settings-related area of the page. Once the Key is filled in, dsh can be used normally.
Of these three steps, the third is the easiest to overlook. Many people think everything is ready once the Key is filled in, only to get an error as soon as they send a task, then spend ages troubleshooting and assuming it's a network problem when in fact the account balance is zero. So my advice is: finish the top-up first, then click the first conversation, which saves a lot of pointless self-doubt.
One more reminder: the API Key is a sensitive credential, so it's advisable to set its permission scope and quota limit on the official platform, and not to casually paste it somewhere public. dsh stores the Key in the local configuration, and you should develop the habit of not committing the configuration file to a Git repository—this is the same as with any project that integrates a third-party model API.
Choose the Working Directory Before You Speak: The dsh Task Area Trio
The first time you open DeepSeek Harness, I suggest you look at two places first and memorize the spatial structure of the page: the left side is the conversation history, and the middle is the task area. In the task area you can do the two most important things—choose a working directory and choose a run mode. These three things (history, directory, mode) form the basic operating framework of dsh, and I call them the "task area trio."
There is a hard prerequisite that must be emphasized here: dsh must first select a working folder before it can hold a conversation. In other words, unlike an ordinary chatbot, it cannot be asked questions the moment you open it. This design is actually determined by the essence of Harness: an Agent needs a "body," and a body needs a range of activity. The working directory is the patch of ground its hands and feet can reach. If you do not specify a range for it, it will not know where to read files or where to write files.
The correct order is as follows:
- First create a working directory on your computer, for example a separate folder just for this task, to avoid polluting the main project;
- Then, in the dsh task area, have dsh open this directory;
- Only after the directory has finished loading should you begin normal conversation and start tasks.
If you come from a command-line environment, it will be more convenient to prepare a clean working directory with the following commands:
mkdir -p ~/workspace/dsh-demo && cd ~/workspace/dsh-demo
git init
echo "# dsh demo workspace" > README.md
git add . && git commit -m "chore: init dsh demo workspace"The reasons for doing this are very practical: first, it isolates the experimental environment from the real project, so even if the Agent accidentally modifies files, the damage is controllable; second, after running git init in advance, any changes can be traced back with git diff, which is equivalent to putting a rollback safety cushion under the Agent's operations. Once you are familiar enough with dsh's behavior and trust it enough, it will not be too late to let it open your main project directly.
By the way, after a task is executed, dsh will list the Token consumption, cache hits, and other information for that task. This feedback loop is very important: it lets you intuitively see "how much this idea was worth," and it also helps you judge whether the context has expanded too much, causing cache hits to drop and costs to rise. Developing the habit of glancing at these numbers after every task is far more useful than reviewing the bill afterward. Moreover, it does not just provide a summary; it also displays the complete trajectory of the task, so you can review exactly how it did the work step by step—what prompts the model received, which tools it called, which files it changed, and how it compressed the context are all kept there. For people who want to learn about the Agent's execution process, this is basically equivalent to request tracing in browser developer tools, except that the object being traced is replaced by the Agent's thinking and actions.
How to Choose Among the Three Permission Levels: Read Only / Workspace Write / Full Access
After choosing the working directory, you immediately face the permission control at the lower left of the dialog box. These three permission levels determine whether dsh can actually touch your files, and this is the most critical switch for safety, so be sure to understand it before you act.
Let me break down the boundaries of the three levels one by one:
| Permission Level | What It Can Do | What Happens When It Crosses the Line | Recommended Use Cases |
|---|---|---|---|
| Read Only | By default it can only read files, not modify them | Any write operation is blocked | When you only want it to look at code, do code review, or answer questions |
| Workspace Write | It can modify files in the current working directory | When it encounters an operation beyond the scope of the working directory, it will ask you first | The most commonly used level in daily work, the first choice for modifying projects |
| Full Access | It can modify files both inside and outside the working directory | It no longer pops up confirmation and executes directly | Use only when you fully understand what it is going to do next |
The comparison makes it clear: Read Only is suited for exploratory tasks where you want to "look before you leap"—for example, having it read through a codebase or help you locate a particular function. Workspace Write is the tier you'll use most often day to day; it can directly modify project files while keeping the out-of-bounds confirmation gate in place, so it feels quite safe. Full Access is essentially removing the guardrails—it can modify files both inside and outside the working directory, and it won't prompt for confirmation anymore.
Regarding Full Access, my stance is clear: don't casually enable this permission. Only consider switching to this tier when you can clearly predict what it's about to do and you've already put backups or version control protection in place. The reason is simple—dsh's strength is autonomous execution, and once autonomous execution is combined with "no confirmation + full write access," you won't even get a chance to intervene when something goes wrong. For beginners, staying at Workspace Write is sufficient for the vast majority of tasks; when you need to read files outside the directory, adjust temporarily rather than opening everything up from the start.
Besides permissions, the bottom-right corner of the dialog also lets you select the DeepSeek model and reasoning level. The default options I saw on the page include DeepSeek V4 Pro and DeepSeek V4 Flash. At the same time, the task area has an additional set of run mode choices. These mode names sound intimidating, but the differences among the four modes aren't actually that complex. Let me first clarify their relationship with permissions so you can build an overall understanding:
- Standard mode: This tier is enough for everyday use. It can handle common operations like viewing files, modifying code, running commands, looking up information, invoking Skills, and arranging sub-Agents.
- PTC mode: Suited for tasks with many steps and long workflows. It has all the capabilities of standard mode, with the difference being that it writes multiple tool operations into a TypeScript program and then executes them in sequence.
- Minimal mode: Leaves the model with only two basic tools—one for executing Bash commands and one for modifying files—with all other capabilities removed.
- Creative mode: Prepared for those who want to customize their own Agent. You can inspect the current runtime environment, experiment with different plugins, and then combine the needed tools and capabilities into a new Agent mode.
The one most worth elaborating on here is PTC mode, because it embodies a clever design in dsh's context management. In normal mode, every time the model calls a tool, the result must be fed back to the model as a new round of input. With many back-and-forth exchanges, the context easily gets bloated, which both wastes Tokens and tends to lose focus. PTC mode's approach is: write multiple tool operations into a TypeScript program and then execute them in sequence, so intermediate data doesn't need to be fed back to the model round after round, and only the final result is sent back to the context. For tasks with especially many tool calls, it both reduces the number of back-and-forth exchanges and avoids bloating the context. For example, batch processing files, continuously querying data, or running a whole set of operation workflows—this mode is more suitable.
Let's use a concrete comparison to get a feel for the difference between the two modes. Suppose the task is to uniformly process a batch of files in a directory. Under standard mode, the path is roughly "call a tool → result back to model → call again → back to model," looping back and forth; whereas PTC mode is closer to the form below, stringing multiple steps into a single program:
// PTC mode conceptual sketch: string multiple tool operations into one program for unified execution
// Intermediate results stay inside the program; only the final result is written back to context
type Step = { name: string; run: () => Promise<unknown> };
async function runPipeline(steps: Step[]) {
const results: Record<string, unknown> = {};
for (const step of steps) {
// Each step completes inside the program, without feeding back to the model context one by one
results[step.name] = await step.run();
}
// Only the aggregated result is sent back to context
return results;
}
// Usage example
export async function main() {
const steps: Step[] = [
{ name: "scan", run: async () => "Scan the target directory file list" },
{ name: "filter", run: async () => "Filter out the files that need processing" },
{ name: "transform", run: async () => "Batch execute transformation operations" },
{ name: "summary", run: async () => "Generate a summary of processing results" },
];
const out = await runPipeline(steps);
console.log(out);
}
main();This code isn't dsh's internal implementation—it's a mental model to help you understand PTC's idea of "collapsing multi-step tool operations into a single program." The key point is where intermediate results are handled: they flow inside the program rather than being shuttled back and forth between the model and the tools. Once you grasp this, you can judge which tasks should be switched to PTC and which are fine left in standard mode.
As for Minimal Mode, it's more like a "bare-metal test" for the model—relying only on two tools, the command line and file editing, to see just how far the model can go. You don't need to pick it deliberately for everyday use, but if you want to observe the model's "base stamina," this mode is quite interesting. Creation Mode, meanwhile, is reserved for the tinkerers: the first three modes are for getting work done, while this one is for "building modes." If you want to configure plugins, you can find them on the settings page—there are already over 100 official built-in plugins, and the number will keep growing.
Finally, let's return to that pitfall I actually hit in testing, because like permissions and modes, it's the kind of thing that "gets you if you don't look." If you find dsh stuck on a task for a long time, don't just sit there waiting—it's best to open a terminal and check whether dsh web is actually still running. I fell into this trap myself: even though I'd already killed the dsh web process, the "Deep diving" timer on the page kept counting, making it look like DeepSeek was still thinking furiously in the background—extremely misleading. In other words, seeing the timer on the page keep increasing doesn't necessarily mean the task is still alive. That experience feels pretty disjointed. The fix is simple—make "checking the terminal process status" your first troubleshooting step, rather than staring at the web timer.
Once you've got permissions straight, modes figured out, and process status down, you can actually get dsh running and complete a real round of tasks. But what truly sets this framework apart from other Agents is the observable information it leaves behind after a round of tasks: the complete execution trajectory, the Token consumption distribution, and the context compression process. How to read this information, what problems it can solve, and whether the actual results I got running dsh + DeepSeek V4 Pro were "absolutely crushing it or totally flopping"—we'll break that down in the next part.
In the previous section, we walked through dsh from installation to API Key configuration, working directory selection, and the three permission tiers (Read Only / Workspace Write / Full Access), so you should already be able to launch tasks normally in the browser. But what really determines "why the same model runs fast and cheap for some people while others keep burning Tokens" are the next two sets of switches: model and reasoning level, and run mode. In this section, we'll take them apart one by one.
Model and Reasoning Level: How to Choose Between DeepSeek V4 Pro and V4 Flash
In the bottom-right corner of dsh's chat box, there are two linked dropdowns: one for model selection and one for reasoning level. The source material explicitly mentions that the model options visible by default on the page are DeepSeek V4 Pro and DeepSeek V4 Flash. These two names aren't arbitrary—their positioning differs enormously, and choosing wrong has a very direct cost: either slow, or expensive, or inaccurate.
Let's clarify one premise first: the model is the brain, and the Harness is the body. dsh can't change the parameter scale or training method of these two "brains," V4 Pro and V4 Flash; what it does is build the body so the brain can use tools. So the model you choose is the ceiling on this task's intelligence; the mode you choose is the ceiling on how much action the body can take for this task. These two dimensions are multiplicative, not substitutes for each other.
So how exactly do you choose? Let me break it down by the most common scenarios:
- DeepSeek V4 Pro: More capable, suited to tasks that require multi-step reasoning, cross-file understanding, complex refactoring, and tracking down tricky bugs. In my testing, all the "deep water" tests ran on V4 Pro — because it can connect multiple threads of clues in the context and doesn't easily drift off course midway.
- DeepSeek V4 Flash: Faster to respond, suited to tasks where "I know what I want, I just need it done quickly." For example, batch-renaming a set of files, applying a fixed format to a piece of settled logic, running a command you've already thought through, or organizing data whose structure you already know.
As for the reasoning level, it controls how long the model "thinks" before giving an answer. The higher the level, the more reasoning steps the model unfolds internally, which suits hard problems; the lower the level, the faster it spits out an answer, which suits simple tasks. The most common engineering mistake is using Pro + a high reasoning level to do something that Flash + a low level could finish in seconds — the result is spending several times the money and still being half a beat slower.
I've put together a selection reference table you can follow directly:
| Task characteristics | Recommended model | Recommended reasoning level | Rationale |
|---|---|---|---|
| Small single-file changes, rename substitutions, formatting | V4 Flash | Low | The task is settled and the steps are short; no long reasoning needed |
| Batch file processing, continuous data queries | V4 Flash or V4 Pro | Medium | Pair with PTC mode to compress multi-step tool operations into a single program |
| Cross-file refactoring, architecture-level changes | V4 Pro | Medium to high | Requires understanding global dependencies; Flash tends to see only the local picture |
| Locating tricky bugs, reverse-engineering root causes from logs | V4 Pro | High | Clues are scattered across many places and require long-chain reasoning |
| Observing the lower bound of the model's "raw capability" | V4 Pro | As needed | Pair with minimal mode for controlled experiments |
One extra reminder here: model selection is not a one-time setting. Within the same session, you can absolutely use V4 Pro first to read the code and clarify your thinking, then switch to V4 Flash for the follow-up repetitive work. That's more economical than using one model from start to finish. Conversely, if you start with Flash and find it repeatedly editing the wrong files and going in circles, don't force it — switch to Pro and start over. The time wasted costs more than the Tokens you saved.
By the way, dsh lists Token consumption and cache hit information after a task finishes. This data is crucial — it's the only objective basis for judging "did I pick the right model this time." If you find that a task's cache hit rate is absurdly low while Token consumption is high, it usually means your conversation context is being frequently rewritten; in that case, either switch modes or break the task into smaller pieces.
Standard mode: the default setting for viewing files, editing code, running commands, and invoking Skills
Permissions solve "can it touch your files"; modes solve "in what posture does it work." dsh offers more than one run mode, but if you only want to remember one, make it standard mode.
The set of operations covered by Standard Mode can be summarized into the following categories based on the description in the source material:
- Reading files: Reading source code, configuration, and documentation in the working directory to build an understanding of the project.
- Editing code: Directly editing file contents to implement specific changes.
- Running commands: Executing shell commands, such as running tests, running builds, installing dependencies, and checking process status.
- Looking up information: Retrieving external information to supplement context.
- Calling Skills: Using preset skills as tools to extend its capability boundaries.
- Arranging sub-Agents: That is, sub-Agent orchestration, breaking a large task into several smaller tasks and dispatching them.
The criterion is very straightforward: If you just want dsh to complete a normal development task, choose Standard Mode directly. Reading code, fixing bugs, running commands to verify, installing dependencies, invoking skills, and splitting subtasks—these common actions are all within its capability range, and you don't need any additional configuration.
Why can Standard Mode become the default tier? The key is that it is the tier with "full capability coverage and predictable behavior." Unlike Minimal Mode, it doesn't deliberately cut tools, and unlike PTC Mode, it doesn't rewrite execution into a program. Its interaction rhythm is the most intuitive one: the model thinks one step, calls a tool once, looks at the result, and then thinks about the next step.
The cost of this rhythm is: the intermediate result of every step must be fed back into the model context. As the number of task steps increases, the context will grow like a snowball, which not only raises Token consumption but also makes context compression more likely to be triggered, and key information may be lost during compression. Therefore, the most comfortable range for Standard Mode is tasks with "moderate steps that require the model to adjust its strategy at any time based on intermediate results."
Here is an example you can paste and run directly, to see the typical workflow of dsh in Standard Mode—it will read files, run commands, and then modify files in the working directory you specify. First create a working directory and write a script with a bug:
mkdir -p ~/dsh-demo && cd ~/dsh-demo
cat > stats.py << 'EOF'
def average(nums):
total = 0
for n in nums:
total += n
return total / len(nums)
if __name__ == "__main__":
print(average([10, 20, 30]))
print(average([]))
EOF
python3 stats.pyAfter running it, you'll find that the second line directly throws a ZeroDivisionError, because an empty list is used in division. At this point, in dsh, point the working directory to ~/dsh-demo, select Workspace Write for permissions, select Standard Mode for the mode, and then give it a sufficiently clear instruction:
Please read stats.py, run it once to confirm the cause of the error,
provide a fix and directly modify the file: return 0 when the input is an empty list,
and finally run it again to confirm that both outputs are normal.You will see it go through the complete process in the order of "read file → run command to reproduce the error → modify file → run command again to verify." After the task ends, the Token consumption and cache hit information for this run will be listed in the lower right corner. This kind of task is the sweet spot for Standard Mode: not many steps, but each step requires seeing the result before deciding the next step.
There is one engineering detail worth noting: in standard mode, writing your acceptance criteria into the prompt can significantly reduce back-and-forth. The line above, "finally re-run once to confirm both outputs are normal," is an acceptance criterion. Once dsh has a clear standard, it will complete the self-check loop on its own, rather than stopping after making changes and waiting for your feedback.
PTC mode: write multiple tool calls as a single TypeScript program and then execute it
PTC mode is the one section in this entire article most worth spending time to understand. First, the conclusion: it has all the capabilities of standard mode. There is no gap between the two in terms of "what they can do"; the gap is in "how they do it."
The execution loop of standard mode is: model thinks → calls tool A → result is fed back to the model → model thinks → calls tool B → result is fed back to the model... The intermediate result of every step has to be stuffed back into the context. PTC mode takes a different path: it writes multiple tool operations as a single TypeScript program, then executes them in sequence. Intermediate data does not need to be fed back to the model round by round; after the program finishes running, only the final result is sent back to the context.
The benefits brought by this difference are very concrete:
- Fewer back-and-forth exchanges: the N rounds of "model—tool—model" round trips originally required are compressed into a single program execution.
- The context is less likely to be bloated: the intermediate process stays inside the program and does not enter the model context, so it is less likely to trigger compression and less likely to lose information.
- Execution is more stable: batch operations are written into code, and the order and conditions are deterministic, so it will not drift because of the model's random judgment in some round.
The typical scenarios named in the source material are batch processing files, continuously querying data, or running an entire operation workflow. What these three types of tasks have in common is: there are many tool calls, but the logic of each step itself does not require the model to make repeated decisions. Hand them to standard mode, and the model will be disturbed because intermediate results keep entering the context; hand them to PTC mode, and the model only needs to write the program well at the beginning, leaving the rest to deterministic execution.
Here is a comparison table to lay out the mechanistic differences between the two:
| Dimension | Standard mode | PTC mode |
|---|---|---|
| Capability set | View files, modify code, run commands, look up information, call Skills, sub-Agent | Exactly the same as standard mode |
| Execution form | One round trip per tool call | Compile multiple steps into a single TypeScript program for serial execution |
| Where intermediate results go | Fed back into the model context round by round | Stay inside the program, not fed back; only the final result is returned |
| Context pressure | Grows with the number of tool calls | Significantly lower |
| Suitable tasks | Requires adjusting strategy while viewing results | Batch file processing, continuous queries, execution of an entire workflow |
Below is an example you can paste and run directly. Suppose you have a directory stuffed with hundreds of log files, and you want to clean them uniformly and categorize them by date. With standard mode, this would generate hundreds of rounds of tool-call back-and-forth; with PTC mode, you only need to give it the intent of this TypeScript script, and it will be responsible for chaining the multiple operations together for execution, finally bringing back to the context only a summary result such as "how many files were processed and which directories they were categorized into":
import { readdir, readFile, mkdir, writeFile } from "fs/promises";
import { join } from "path";
const SRC = "./logs";
const OUT = "./logs-cleaned";
async function main() {
await mkdir(OUT, { recursive: true });
const files = await readdir(SRC);
let moved = 0;
for (const f of files) {
if (!f.endsWith(".log")) continue;
const raw = await readFile(join(SRC, f), "utf8");
// Remove blank lines and leading-timestamp noise
const cleaned = raw
.split("\n")
.filter((line) => line.trim().length > 0)
.filter((line) => !/^\d{4}-\d{2}-\d{2}/.test(line))
.join("\n");
// Group into subdirectories by the date prefix in the filename
const date = f.slice(0, 10);
const dir = join(OUT, date);
await mkdir(dir, { recursive: true });
await writeFile(join(dir, f), cleaned, "utf8");
moved++;
}
return { moved, out: OUT };
}
main().then((r) => console.log(JSON.stringify(r)));Note the key point of this code: the readFile / mkdir / writeFile calls throughout the loop all happen inside the program, and the model never needs to see the contents of each file. All it gets in the end is a single summary line like {"moved": 312, "out": "./logs-cleaned"}. This is the fundamental principle behind how PTC saves Tokens—keep the "process" inside the program and bring only the "result" back into the context.
When should you not use PTC? If the task itself requires the model to make judgments based on intermediate results—for example, "first see where the tests fail, then decide which piece of code to change"—then the standard mode is more suitable. That's because PTC assumes you can spell out the steps clearly before you start; for tasks you can't spell out clearly, forcing PTC on them will instead produce a program whose logic you only discover is wrong after it finishes running.
Minimal mode: keep only two tools, Bash execution and file modification
The positioning of minimal mode is completely different from the previous modes. It gives the model only two basic tools: one for executing Bash commands and one for modifying files, with all other capabilities removed. No Skills, no sub-Agent, no extra tools for looking things up, nothing at all.
Why create such a mode? According to the source material, it's more like a "bare-metal test" for the model—good for observing how far a model can get using only the command line and file editing. In other words, the previous modes test "how well the Harness body is built," while minimal mode tests "how strong this brain itself is."
It is not suitable for daily use, and the material makes this point very clear. For the vast majority of everyday development tasks, you should not choose it, because you will needlessly lose capabilities such as Skills and sub-Agent orchestration that already save you effort. Its value lies in experimental scenarios:
- If you want to know how large the gap is between V4 Pro and V4 Flash under the condition of "command line + file editing only," run the same set of tasks in minimal mode for comparison.
- If you want to verify whether a problem is due to insufficient model capability or whether the Harness's tool design is holding it back. Cut capabilities down to the minimum; if the problem remains, the fault lies with the model.
- If you want to study what the minimal execution loop of an Agent looks like, minimal mode gives you the most bare-bones version.
There is an easy pitfall to fall into: in minimal mode, the model can accomplish many things with Bash and file editing, but every step must be assembled by itself using the command line. This means it is extremely dependent on commands, and slightly complex operations turn into long shell concatenations, with a corresponding increase in the probability of errors. This is not a bug, but the inevitable cost of actively choosing a "bare-metal" setup. So when doing experiments, it is recommended to break tasks down small and observe only one variable at a time; otherwise, the results are very hard to attribute.
Creation Mode: Inspect the runtime environment, try plugins, and assemble your own Agent mode
If standard, PTC, and minimal are the three modes used to get work done, then Creation Mode is used to "create modes." It is prepared for people who want to customize their own Agent.
In Creation Mode, you can do three things:
- Inspect dsh's current runtime environment: figure out exactly what this Harness has loaded and what it can access.
- Experiment with different plugins: the material mentions that there are already more than one hundred official built-in plugins, and the number will continue to increase. These plugins can be tried one by one in Creation Mode.
- Combine the needed tools and capabilities into a new Agent mode: after trying out which plugins are useful and which combinations are effective, assemble them into your own mode.
This step should be understood under the design philosophy of "everything is a plugin." dsh turns capabilities such as models, tools, policies, storage, sandboxing, context management, and UI into things that can be disassembled and assembled like building blocks. Creation Mode is a workbench for assembling blocks. The previous three modes are essentially three pre-assembled block sets from the official team; Creation Mode dumps the blocks in front of you and lets you assemble them yourself.
If you want to configure plugins, you can find them on the settings page. One suggestion is: do not pile on plugins right from the start. Every additional plugin increases the available tools the model sees, and the cost of choice rises accordingly. First use standard mode to figure out which capabilities a task really needs, then return to Creation Mode to subtract rather than add—attach only the few that are truly useful; the resulting mode is often more stable than one stuffed with plugins.
Creation Mode also has a hidden value: it is the fastest entry point to understanding "everything is a plugin." All the behaviors you see in standard mode—including how context is compressed and how tools are invoked—have corresponding configurable items in Creation Mode. If you plan to use dsh long term, you will eventually need to explore this area.
Summary and Best Practices
Compress the key points of this section into a checklist you can directly follow:
- Set permissions first, then choose the mode. If you only want it to look at code, use Read Only; for routine project changes, use Workspace Write; enable Full Access only when you are completely clear about what it is going to do.
- Choose the model according to task difficulty. For small single-file changes, naming replacements, and formatting, use V4 Flash; for cross-file refactoring and locating difficult bugs, use V4 Pro; you can switch mid-session, using Pro in the first half to sort out the approach and Flash in the second half for repetitive work.
- Do not always max out the reasoning level. The more deterministic the task, the lower the level; raise it only when clues are scattered and long-chain reasoning is needed.
- For ordinary development tasks, use standard mode directly. It covers reading files, editing code, running commands, looking up information, invoking Skills, and sub-Agent orchestration, making it the default tier that best matches intuition.
- Write acceptance criteria into the prompt. For example, "finally rerun once to confirm both outputs are normal," letting dsh complete the self-check loop on its own, which can significantly reduce back-and-forth communication.
- For tasks with many tool calls and long steps, switch to PTC mode. Batch file processing, continuous data queries, and full-process execution are all suitable for compiling multi-step operations into a TypeScript sequence that runs serially, with intermediate data not fed back to the model and only the final result returned, greatly reducing context pressure.
- For tasks that require adjusting strategy while watching results, continue using standard mode. Forcing PTC onto tasks whose steps cannot be clearly written out will only produce a program whose logic is wrong only after it finishes running.
- Minimal mode is only for observing the model's lower bound. It keeps only two tools, Bash execution and file modification, and is a "bare-metal test"; do not use it for daily development.
- Creation Mode is for assembling your own mode. In it, inspect the dsh runtime environment, try plugins (there are already more than one hundred official built-ins, and still increasing), and then recombine capabilities into a new mode; when assembling, subtract rather than pile on plugins.
- After each task, check Token consumption and cache hits. This is the only objective basis for judging whether the model and mode were chosen correctly; low hit rate and high consumption usually mean the context is being frequently rewritten, so consider switching modes or breaking the task down smaller.
- Use the "Trajectory" to review the execution process. What prompt the model received, which tools it called, which files it changed, and how it compressed context can all be traced back along the trajectory, so you can pinpoint which step went wrong and where Tokens were spent.
Get these few things right, and the same V4 Pro in your hands versus a beginner's will show an order-of-magnitude difference in efficiency. In the next section, we move into real-task testing to see how these pattern combinations actually perform in real engineering, and how to avoid that pitfall where "the process page keeps counting time even after you close it."
In the previous section, we broke down DeepSeek Harness's positioning, installation path, permission tiers, and four run modes, and also discussed who it's suited for and who it isn't. In this section, we go deeper: we'll talk about the detachable structure behind "everything is a plugin," how to read task trajectories, how to reconcile Token bills, how to order a pitfall checklist, and finally give you a practical checklist you can follow directly.
100+ built-in plugins and "everything is a plugin": models, tools, policies, storage, sandbox, context, and UI are all detachable
Let's start with the thing most easily overlooked but actually most decisive for DeepSeek Harness's ceiling: its design philosophy is just five words—everything is a plugin. These five words sound like a marketing slogan, but in engineering terms, they mean that almost everything you can see and call in dsh is a replaceable building block.
If you've used tools like Claude Code or Codex before, you'll notice that most of them weld together "model integration," "tool invocation," and "context management" into one fixed pipeline, leaving you to make trade-offs only within a limited set of configuration options. dsh takes another path: it breaks an entire Agent pipeline into several categories of replaceable components, each with its own plugin slot.
How fine-grained is the breakdown? Based on the tested page structure and source information, it can be summarized as follows:
- Model: which underlying DeepSeek model is used is determined by the plugin layer. By default, the page lets you select DeepSeek V4 Pro and DeepSeek V4 Flash, but these are just the current built-in options; the model side itself is a plugin slot.
- Tool: which capabilities the model can call—such as reading and writing files, executing commands, looking up information, and invoking Skills—are all attached to tool plugins. The reason Minimal mode can leave only Bash + file modification as the two tools is precisely because tools themselves are building blocks that can be removed entirely.
- Policy: this includes decision rules such as permission tiers and run modes. The three permission levels Read Only / Workspace Write / Full Access, as well as the four modes Standard / PTC / Minimal / Creative, are essentially different policy combinations.
- Storage: how data such as conversation history, task records, and execution trajectories are persisted is also a plugin slot and can be replaced as needed.
- Sandbox: the isolated environment in which the model executes code and commands is also detachable, determining which files it can touch and what commands it can run.
- Context: how prompts are assembled, when context is compressed, and what is retained after compression—this entire set of logic is also plugin-based, and its traces will be especially obvious when reading trajectories later.
- UI: the outermost Web interface also falls under the plugin category. This is also why dsh opens as a Web UI, rather than leaning CLI like Claude Code, or taking a desktop form like Codex—the interface itself is an assembled shell, and DeepSeek made a form-factor choice in this round.
Once you understand this list, you'll see why dsh dares to claim "a very high degree of freedom": it doesn't give you a fixed Agent, but an Agent assembly line. When you want to change models, change tool combinations, or change context strategies, you're essentially swapping plugins, not modifying source code.
So where do you go to view and configure these plugins? The answer is the Settings page. One key figure mentioned in the source material is that there are already over 100 officially built-in plugins, and the number will continue to grow. The significance of this number isn't that it's "many," but that it has crossed the threshold of being "enough out of the box"—you don't have to write your own plugins right away. With just the 100+ built-in ones, you can already assemble quite a variety of different Agent forms.
To make the idea of "the same foundation, different plugin combinations" clear, I've organized the four run modes and their corresponding plugin trade-offs into a table:
| Run Mode | Scope of Tool Plugins Retained | Context and Execution Characteristics | Typical Use Cases | Suitable for Daily Use |
|---|---|---|---|---|
| Standard Mode | View files, edit code, run commands, look up information, invoke Skills, arrange sub-Agents | Conventional tool calls, interacting with the model round by round | Normal development tasks, the everyday workhorse | Suitable, the default first choice |
| PTC Mode | Has all the capabilities of Standard Mode | Writes multiple tool operations into a single TypeScript program and executes them in sequence; intermediate data isn't fed back to the model, only the results are returned to the context | Tasks with many steps, long workflows, and dense tool calls, such as batch file processing or continuous data queries | Suitable for specific heavy-workflow tasks |
| Minimal Mode | Keeps only two basic tools: one to execute Bash, one to modify files; all other capabilities are removed | Approximates a "bare-metal test," relying only on the command line and file editing | Observing how the model performs under a minimal capability set | Not suitable, no need to deliberately choose it for daily use |
| Creation Mode | Opens up runtime environment inspection, plugin experimentation, and tool combination | Oriented toward "building modes" itself, can combine new Agent modes | People customizing Agents, experimenting with different plugins | Oriented toward customization, not toward getting work done |
The one most worth a second look in this table is PTC Mode. Its difference from Standard Mode isn't in "whether it can do the job" but in "how it does it": in Standard Mode, the model calls a tool once, gets a result once, then thinks about the next step, with intermediate data being fed back into the context round after round; PTC Mode instead writes multiple tool operations into a single TypeScript program first, executes them in sequence, doesn't shuttle intermediate data back and forth, and only returns the final results to the context. This design has two direct benefits: first, fewer back-and-forth exchanges, and second, it's less likely to keep inflating the context. For tasks like batch file processing, continuous data queries, and running a whole set of operation workflows, the effect is especially pronounced.
If you've already installed dsh and want to see firsthand what the plugin slots look like, you can run the following commands directly in the terminal to list dsh's installation directory structure and find the plugin-related directories accordingly:
# View dsh's global installation location and plugin directory structure
# Step 1: Confirm whether the dsh command itself is available
dsh --version
# Step 2: List the installation path of dsh under the global npm package directory
npm ls -g --depth=0 | grep -i dsh
# Step 3: Enter the dsh package directory and dig out the plugin and configuration-related folders
# Note: replace <your global node_modules path> with the actual path output in the previous step
ls -la <your global node_modules path>/deepseek-harness
# Step 4: Check whether the package contains directories like plugins / skills / policies
find <your global node_modules path>/deepseek-harness -maxdepth 2 -type d | sort
Once you've run through these few steps, you'll basically have a clear picture of "which layer a plugin is actually installed at." Open the settings page alongside it and you can match things up: the model dropdown, mode selector, and permission tiers you see on the page all correspond to some category of plugin configuration behind the scenes.
There's one more detail worth emphasizing: if the AI can do it, let the AI do it. The installation method given in the source material itself reflects this idea—just send a single message in your usual Agent and let it handle the install:
Help me install DeepSeek Harness https://www.deepseek.com/harness/
In practice, it was installed in about 5 minutes. After installation, run dsh web and the browser will open the Web UI directly. Here's a point that makes many people pause on first reaction: you'd expect dsh to be a CLI Coding Agent like Claude Code, or a desktop Agent like Codex, but instead it gives you a Web UI. This isn't an arbitrary form factor—it's the natural result of the philosophy that "the UI is also a plugin." Since the interface can be detached and swapped, it can of course choose to appear as this web-layer shell.
The next initialization step is also simple: go to the official DeepSeek API platform, create an API Key, copy the Key into the dsh web page and fill it in, and you're good to go. The only thing to keep in mind in advance is that you should top up some money in your DeepSeek account before use, since the Tokens consumed by model calls are billed. This point is directly related to the "billing view" discussed later.
How to read a task trajectory: prompts, tool calls, file changes, and context compression all leave a trace
If I could pick only one feature from dsh to recommend to people who want to learn about Agents, I'd choose the task trajectory.
First, let's talk about what it looks like and why it's easy to read. The analogy in the source material is very accurate: it's somewhat like request tracing in browser developer tools. When you look at a page load in the DevTools Network panel, you can see each request's initiation time, parameters, response, and duration; the trajectory panel gives you the same perspective for an Agent executing a task—except the object being traced changes from HTTP requests to each step of the model's actions.
The key point is that the trajectory records not just the final chat content. Many people underestimate this the first time they use it. What it actually preserves includes:
- What prompts the model received: that is, the complete input sent to the model in each round, including system-level prompts, the assembled context result, and the current task description.
- Which tools were called: which tool was selected at each step and what parameters were passed.
- Which files were changed: which path the write operation landed on and which part of the content was modified.
- How context was compressed: at what point the context was compressed and what information was retained after compression.
Stringing these four types of information together is equivalent to installing a replayable log layer over the entire execution chain. As a result, the two most headache-inducing questions both have solutions: which step went wrong—trace back along the trajectory; where the Tokens were spent—also trace back along the trajectory. The original wording in the source material puts it well—you can basically trace it all back along the trajectory.
So how should you actually read a trajectory in practice? I've broken it down into a four-step method; follow it in order and you basically won't get lost:
- Locate the failure point first, then look at the success path. When a task fails, don't read from start to finish. First find the last step that errored or produced the wrong artifact, lock onto that node, and then trace upward to see where its input came from.
- Look at prompt assembly. When the same tool call fails, it's often not that the model is incapable, but that the prompt it received this round was missing key information. Checking the complete input sent to the model lets you quickly determine whether it's a "model misjudgment" or "context not fed in."
- Look at tool parameters. Wrong file paths, misspelled command arguments—these low-level but high-frequency problems are obvious at a glance on the tool call node.
- Look at the context compression node. In long tasks, the most likely place for mysterious problems is around compression: information the model still remembered before compression may be lost after. If a task suddenly "loses its memory" after a certain node, suspect this spot first.
To make this reading approach more concrete, let me compare it with the tracing capabilities of browser DevTools, and also clarify "what fields are in a trajectory":
| Comparison Dimension | Browser DevTools Request Tracing | DeepSeek Harness Task Trajectory |
|---|---|---|
| Traced object | HTTP request / response | Each round of model prompts, tool calls, file changes |
| Core purpose | Locate API errors, performance bottlenecks | Locate erroneous execution steps, where Tokens went |
| Contains final artifact | Contains response body | Not just the final chat content, but also the intermediate process |
| Key recorded items | URL, Method, Headers, Payload, Status, Timing | Prompts, tool names and parameters, file changes, context compression records |
| Typical troubleshooting scenarios | API 500, request timeout | Task stuck, wrong results, abnormally high Token usage |
| Learning value | Understand frontend-backend interaction | Understand Agent execution logic and tool call order |
For students who want to learn the Agent execution process, the right column of this table is essentially ready-made teaching material. What the model receives, how it decides, what it calls, what it changes, how it compresses—everything is recorded. The more you look, the more you'll naturally develop an intuition for "why the Agent does what it does," which is far more valuable than just looking at the final answer.
Here's one more practical engineering tip: use trajectories as regression tests. Run the same task today, then change a plugin or switch modes and run it again tomorrow—comparing the two trajectories makes it very intuitive to see "whether a plugin change caused the behavior change, or whether it's just model variance." This is especially useful when debugging custom plugins—you always need a baseline to compare against.
Token consumption and cache hits: the bill view after each task
Trajectories solve "how it ran," while the bill view solves "how much it cost." In dsh these two are presented separately, but they should be viewed together.
One point clearly mentioned in the source material is: after task execution, dsh lists the Token consumption and cache hits for this task. This is a bill automatically provided after each task, so you don't need to go dig through records on the API platform.
Don't underestimate this bill. Its timing is perfect—it appears right when your memory of the task is freshest. You can immediately line up three things:
- How many Tokens were consumed: the overall usage for this task.
- Cache hit status: how much of the input was reused via cache hits. Cached and uncached portions differ greatly in cost, so this number directly determines whether this task was expensive.
- Whether task complexity matches the cost: if a seemingly simple small task consumes an unusually high number of Tokens, it usually means the context is being repeatedly shuffled around, or the compression strategy isn't taking effect.
And this bill and the trajectory from the previous section can corroborate each other. If you find that a certain task has high Token consumption, don't just stare blankly—go back to the trajectory and look: is the same content being repeatedly stuffed into the context? Is the compression node arriving too late? Is some tool call looping for several rounds? All of these leave traces in the trajectory.
This is also why, when discussing the PTC pattern earlier, we specifically emphasized that "intermediate data doesn't need to be stuffed back into the model round after round." From the perspective of the bill, the value of the PTC pattern isn't just "fewer back-and-forth communications"—it's directly spending Tokens on results rather than on intermediate shuffling. For long-process tasks with dense tool calls, this difference will be tangibly reflected in the bill.
One more reminder directly related to money: before use, remember to top up your DeepSeek account, since Token consumption is billed. This isn't optional; it's a prerequisite. The bill view can help you build cost awareness, but you still need to top up your account balance when it's due.
Don't just wait when it's stuck: a troubleshooting checklist for the inconsistency between the dsh web process and the "Deep diving" timer
Next is the most noteworthy pitfall from this hands-on test, because it's extremely deceptive.
The scenario is like this: you start a task, and the page shows "Deep diving" continuously counting up, with the time going up and up, making it look like DeepSeek is still thinking furiously in the background. You wait and wait, possibly for a long time. But the actual situation is—according to the firsthand experience in the material: the dsh web process has long since been shut down, yet the "Deep diving" on the page is still counting up.
This phenomenon isn't complicated once explained, but its damage is not small. Whether the page timer is running and whether the background task is alive are two different things. The process is gone, but the frontend timer is still running, so the "still thinking" you see is actually an illusion. The material's assessment of it is that "the experience is quite disjointed," and that description is very accurate.
So the first rule of discipline is: if you find dsh stuck on a certain task for a long time, don't just wait foolishly. Waiting on doesn't equal getting a result.
I've organized the correct sequence of actions into the troubleshooting checklist below. Follow it and you can basically rule out the vast majority of "fake freezes":
- Open the terminal and confirm whether dsh web is actually still running. This is the first action, and it's also the suggestion explicitly given in the material. Don't refresh the page in the browser to find a solution—check the process first.
- If the process is gone, directly restart dsh web, and the task most likely needs to be re-initiated. Because the page timer doesn't mean the task is really alive, and waiting on won't produce any output.
- If the process is still there, then judge whether it's really running a long task. At this point, looking at the trajectory is far more useful than staring at the timer—whether there are new tool calls and new file changes in the trajectory is the evidence that the task is alive.
- If the process is there and the trajectory isn't moving either, then it's truly stuck. At this point, consider switching modes, narrowing the task scope, or checking whether too much stuff has been stuffed into the context.
- Make it a habit: for long tasks, don't only trust the page. Page timer increasing ≠ task alive; this equation doesn't hold in dsh.
Comparing process liveness against page behavior makes things much clearer:
| Terminal-side dsh web process | Page "Deep diving" timer | Actual task state | What you should do |
|---|---|---|---|
| Still running | Keeps increasing | Most likely genuinely executing | Check the Trajectory for new actions and wait patiently |
| Already terminated | Still counting up | The task no longer exists (very easy to misjudge as still thinking) | Restart dsh web and re-initiate the task |
| Still running | Increasing but no new actions in the Trajectory | Suspected genuine hang | Check the mode and context, consider narrowing the task or switching tiers |
The core takeaway from this table comes down to one sentence: a timer on the page that keeps increasing does not necessarily mean the task is still alive. Remember this, and it will save you a great deal of wasted waiting.
To quickly confirm process status, use the following commands. Don't judge by whether it "looks like it's running"—judge by the command output:
# Check whether dsh is still running: look at the process first, then the port
# 1. Check whether dsh-related processes are alive
ps aux | grep -i "dsh" | grep -v grep
# 2. If dsh web listens on a local port, confirm whether any process is still listening on it
# Replace 3000 with the port number you actually see
lsof -i :3000
# 3. For a quick one-shot confirmation: output = process exists, no output = process is gone
# The output of this step is the basis for judging whether the task is alive
These commands are straightforward to use: step 1 checks the process, step 2 checks the port, and step 3 is the lazy person's quick check. Get into the habit of "check the terminal before drawing conclusions," and the timer will never fool you again.
Looking at Harness again in September 2026: three new usage patterns after the plugin ecosystem expands
Looking further ahead from the present moment of hands-on testing, the most exciting thing about DeepSeek Harness is not what it can do today, but what it can be assembled into once the community plugin ecosystem keeps expanding. The stance in the source material is clear: its most valuable aspect is the large room for modification it leaves to the community; as the ecosystem grows more and more wild, it's hard to imagine what it will look like later. Let me reasonably extend this thread—by September 2026, three usage directions worth watching will likely emerge.
First: "assembling" dedicated Agents around vertical scenarios. Since the model, tools, prompts, context, and UI can all be adjusted through plugins, the most natural approach is to stop settling for a general-purpose Agent and instead reassemble these components around your own real needs. From the same foundation, you might assemble an assistant that only understands a certain kind of codebase, or an execution body that specializes in a certain kind of data pipeline. The four modes discussed earlier already gave the signal: standard mode does the work, PTC mode handles dense pipelines, minimal mode squeezes capabilities for testing, and creation mode creates modes—only when the plugin ecosystem is rich enough will the output of creation mode truly deliver value.
Second: solving context and cost problems through plugins. Context management is itself a plugin slot, which means strategies like "when to compress, what to keep after compression, and what content stays resident" can all be customized. Combined with the Token consumption and cache hit information provided by the billing view, you can tailor a context strategy specifically for your task type to drive costs down. This is pure engineering gain, and more controllable than switching models.
The third approach: treat trajectories as a team-wide debugging standard. Trajectories record prompts, tool calls, file changes, and context compression. This traceability capability isn't just for personal learning. Once plugin combinations multiply and behavior grows complex, "check the trajectory first when something goes wrong" shifts from a personal habit to a team standard—because only trajectories can simultaneously answer "which step went wrong" and "where did the Tokens go."
But the barriers must be stated just as clearly. The source material is blunt about dsh's positioning: it is inherently developer-oriented. This also means it may not suit ordinary users—if you want to use it for office tasks, you'll most likely find it awkward; those hardcore settings and features are incomprehensible and unusable to the uninitiated. Add one more real-world constraint: there is currently no one-click-install Skill marketplace. Despite the large number of plugins, there's no unified entry point where you "click once and it's installed"—for non-developers, that's a solid wall.
Putting advantages and barriers side by side makes it easier to judge whether you should get on board:
| Dimension | Meaning for developers | Reality for ordinary users |
|---|---|---|
| Everything is a plugin | Freely customizable—model/tools/prompts/context/UI can all be swapped | Too many hardcore settings; incomprehensible and unusable |
| 100+ built-in plugins | Enough material out of the box to assemble with | Don't know what to pick or how to configure |
| Task trajectories | A powerful tool for debugging and learning how an Agent executes | High information density, lacking motivation to use |
| No one-click-install Skill marketplace | Acceptable—write your own or configure manually | Entry barrier is noticeably raised |
| Office-type daily tasks | Usually easier to just write your own tools | Most likely awkward to use |
So the judgment for September 2026 isn't complicated: the expanding plugin ecosystem will make dsh increasingly powerful in developers' hands, but its developer-oriented positioning and the missing one-click-install marketplace won't disappear on their own in the short term. To reap its benefits, the prerequisite is that you're willing to get your hands dirty assembling it.
Summary and Best Practices
Finally, let's compress the core conclusions of this hands-on test into an actionable checklist. Follow it after installation and you'll avoid quite a few pitfalls:
- Nail down the prerequisites first. Just send an install command from your usual Agent—about 5 minutes in practice; run
dsh webto open the Web UI; go to the official DeepSeek API platform to create an API Key and fill it into the page; top up your account first—Tokens are billed. - Create a working directory before chatting. dsh requires you to select a working folder before it can start; create the directory on your computer first, then have dsh open it.
- Choose permissions as needed—don't jump straight to Full Access. For reading code only, use Read Only; for modifying projects, use Workspace Write (the most common daily choice; it will ask you first if you go out of scope); Full Access is equivalent to removing the guardrails—only use it when you clearly know what it's going to do.
- Choose modes by task. Use Standard Mode for daily development; use PTC Mode for multi-step, call-intensive tasks like batch file processing and continuous data queries; use Minimal Mode to observe the model's bare-metal performance; use Creative Mode to compose custom Agents.
- Treat trajectories as your first debugging entry point. Locate the failure point first, then examine prompt assembly, tool parameters, and context compression nodes; if a task suddenly "loses its memory," suspect compression first.
- Reconcile the bill after every task. Check Token consumption and cache hit rates; if consumption is abnormally high, go back to the trajectory to inspect context transport and compression timing.
- When stuck, open the terminal first. Confirm whether the dsh web process is still alive; a growing "Deep diving" timer on the page doesn't mean the task is alive; if the process is gone, restart and resend.
- Make good use of the plugin settings page. There are already 100+ official built-in plugins and more will keep coming—browse through them before deciding whether to write your own.
- Be honest with yourself. If you're a developer, dsh's freedom and trajectory capabilities will suit you well; if you mainly want to handle office tasks, the current lack of a one-click-install Skill marketplace plus its hardcore settings mean you'll most likely find it awkward to use.
Three bonus practices worth adding:
- Run the same task twice and compare the two trajectories to determine whether a behavior change comes from a plugin or from model variance.
- For long tasks, prefer PTC, keeping intermediate data inside the program instead of repeatedly stuffing it back into the context.
- Treat "is the process still alive" as the primary basis for judging task status, and use the page timer only as a reference.
After testing the whole thing end to end, my conclusion is this: dsh is worth watching, but its value isn't in "how great it is out of the box"—it's in the enormous room it leaves the community for reworking it. Models, tools, prompts, context, and UI can all be adjusted through plugins, letting you reassemble an Agent's capabilities and way of working around your own real needs. It is indeed very developer-oriented, and it does have pitfalls—especially that jarring experience where the process has already closed but the timer keeps running. But once you get the hang of plugins, trajectories, and billing, you'll start to understand why the phrase "everything is a plugin" deserves to be repeated again and again.