Preface¶

DeepSeek Harness (dsh) treats models, tools, sessions, and loops as plugins. Once an agent is running, what usually consumes the most time is not a single read or bash call, but the model’s rethinking before each tool invocation. Author Electricitysheep illustrated this phenomenon in the repository README: a tool chain of around 50 steps might spend several minutes on the thinking between tools, rather than on the tools themselves.

Around August 13, 2026, DeepSeek’s chat interface made the reasoning intensity adjustable via the parameter reasoning_effort. The official adapter @deepseek-ai/dsh-llm-deepseek integrated it into the request configuration, with options off / low / high / max, defaulting to high when omitted. It also explicitly stated that agent/request can replace this value in each conversation step. In other words, the plugin has a formal entry point to modify the next round’s reasoning level without changing the task prompt or the Harness source code.

dsh-tool-turbo does exactly this: it checks if the recent rounds of tool calls are “simple, deterministic read/write operations”, drops to low for simple tasks, and raises the level back when the work becomes heavy. No changes are needed to the task itself.

What It Is¶

dsh-tool-turbo is a host plugin for DeepSeek Harness, maintained by Electricitysheep, with the repository at Electricitysheep/dsh-tool-turbo. It is categorized under “Workflow and Automation” in the community directory, primarily written in TypeScript. The current version is 0.1.0 in package.json, requiring Node.js 20 or above. As of August 18, 2026, both the directory page and GitHub show 4 stars.

It solves a specific problem: in long tool chains, simple steps still use the high-level reasoning mode, causing wall-clock time to be delayed by the thinking phase. The plugin hooks into dsh’s agent/request waterfall flow, and injects the reasoningEffort it deems appropriate for the next model request based on the recent tool/call records of the current step. The directory page summarizes it as: use low level for simple tool chains, upgrade for heavy tasks, with zero changes to the task itself.

First, it is important to clarify its ecosystem position. The official philosophy of DeepSeek Harness is “everything is a plugin”, with the source code at deepseek-ai/deepseek-harness. The retrieval portal used in this article, deepseek-harness-plugin.com, is an independent community directory, which also states on its site that it has no official affiliation or sponsorship with DeepSeek or FunPlus, does not host plugin code, and entries only point to maintainer repositories. Do not treat it as an official app store.

How It Works¶

The official LLM adapter re-parses the request configuration at each step. dsh’s agent loop allows plugins to propose the next round’s GenerateOptions in agent/request (the plugin source code points to buildRequest in packages/core/agent-loop/src/agent.ts). dsh-tool-turbo hooks into this entry point, and the workflow can be divided into three steps.

1. Observe. From the current session’s session.events, collect the most recent tool/call records in reverse order, with a window size of 8, then pass them to the decision function in chronological order. Each sample only retains the tool name and the character length of the parameters, without modifying the tool parameters themselves.
2. Decide. The pure function decideEffort selects low / high / max based on the “proportion of simple tools” and “heaviest payload” in the most recent calls. The source code defines “simple, deterministic” tool names via regex, with prefixes including fs, bash, read, write, grep, glob, edit, and common commands like ls / cat / mkdir; a parameter character count reaching 800 is not considered a small payload. This logic has no external dependencies, and the repository tests it separately with Vitest.
3. Inject. The listener first await next() to get the pre-assembled request configuration from downstream, then overrides the reasoningEffort in it, and prints a log line [tool-turbo] agent/request: .... The task prompt, tool list, and session content remain unchanged.

The same plugin also hooks into agent/tool to record wall-clock time between the tool start and end events, writing it to the host log. In the README roadmap, “displaying time consumption in the UI / agent context” is not yet implemented, and currently it can only be viewed in the logs.

Decision Strategy¶

The decision table is based on the README, and cross-checked with src/effort-decision.ts and tests/effort-decision.spec.ts. The rules can be summarized as follows.

The default configuration is in DEFAULT_CONFIG in src/index.ts:
- enabled: true (plugin works by default after loading)
- allowDowngrade: true (allow downgrading from the baseline)
- allowUpgrade: false (disabled by default, conservative)
- baseline: high

The README refers to these three switches as a planned settings namespace (using dsh-settings). The corresponding roadmap item is still incomplete, so do not expect a ready-made settings panel for now; to modify the switches, you need to refer to how Cordis plugin configurations are passed to apply(ctx, config), rather than treating it as a delivered UI feature.

Unit tests cover several key behaviors: keep the baseline for brand new prompts; downgrade to low for small-parameter calls like bash / fs_read / fs_write; stop downgrading after turning off allowDowngrade; upgrade to max for oversized payloads only when allowUpgrade is enabled; lift to high for mixed calls like web_search or mcp__db. The repository claims 6/6 tests passed, and tsc --noEmit runs cleanly. The README also includes logs from a real dsh instance: keep high when the baseline is high and no tool calls have been made, and change to low after a write call appears.

In the source code comments, the author believes that about 90% of wall-clock time for simple tasks is spent in the thinking phase, and dropping from high to low could reduce thinking time to a fraction of the original. This is the repository author’s judgment, and this article has not independently verified it; treat it as background information only, not as a published benchmark result.

Installation and Enablement¶

The installation command given on the community directory page is as follows, run it in the DeepSeek Harness terminal:

dsh plugin add github:Electricitysheep/dsh-tool-turbo

The dsh CLI will parse the plugin from GitHub and add it to the current configuration. The directory page also reminds users: for reproducible installations, please pin the commit hash. As of August 17, 2026, the latest commit on the repository’s main branch is d29e7d9d73032516e37797ea69592ce18e0fe05f (this commit added the dsh.bundle manifest and cordis.patch.yml to support dsh plugin add). The pinned installation command is:

dsh plugin add github:Electricitysheep/dsh-tool-turbo#d29e7d9d73032516e37797ea69592ce18e0fe05f

The repository’s built-in cordis.patch.yml will insert id: dsh-tool-turbo and name: dsh-tool-turbo. The README also includes a local clone + link: registration method for the ~/.dsh/profiles/web profile, suitable for debugging source code modifications; the plugin ID written in that instruction is tool-turbo, which does not match the repository files, so refer to the original content of cordis.patch.yml instead. The README also states that installation documentation for other profiles such as headless / TUI is still on the roadmap, and currently examples are mainly based on the web profile.

After installation, restart the corresponding profile according to the README, for example:

dsh web

The peer dependencies declared in package.json are @deepseek-ai/cordis ^4.0.1, and @deepseek-ai/dsh-agent and @deepseek-ai/dsh-settings at ^0.1.0-rc.6. dsh is still in developer preview, and core plugins and APIs will continue to change, so you should check your local Harness version before installing.

Typical Usage¶

This plugin has no separate “start acceleration” command. After installing and restarting, assign tasks to the agent as usual. It only modifies the next round’s reasoning level after tool calls have already appeared; for the first user prompt without any tool/call yet, it will keep your selected baseline.

It is suitable for observing repository tasks that will consecutively call read / write / grep / bash: modify a few files, search for symbols, then run a short command. With the default strategy, rounds with small parameters and a high proportion of simple tools will be downgraded to low. Once a web_search, MCP-style tool, or a long parameter appears later, the decision will stop downgrading; if you explicitly enable allowUpgrade, particularly heavy payloads may be upgraded to max.

To confirm that it is working, check if there are lines like the following in the host log (the real runtime record provided in the README):

[tool-turbo] agent/request: baseline=high calls=[]                    => reasoningEffort=high
[tool-turbo] agent/request: baseline=high calls=[{"name":"write",…}] => reasoningEffort=low

Tool time consumption is another type of log, formatted as [tool-turbo] tool <callId> took <ms>ms.

Applicable Scenarios and Notes¶

It is more suitable for users who are already running long tool chains in dsh, with a large number of steps involving reading files, writing files, searching, and short commands. It does not replace model selection or modify tool implementations, it only turns the fixed configuration of “whether to use high-level reasoning this round” into an automatic selection based on recent tool calls.

Keep the following points in mind before installing.

1. The plugin runs with the permissions of the current dsh process, and may execute code during installation. This is stated in the installation section of the directory page, so you should open the source code and license agreement yourself before installing, instead of just reading the introduction. package.json and the README declare the license as MIT; the GitHub repository metadata currently does not recognize a separate LICENSE file, so if you need file-level declaration for compliance, you should confirm with the repository.
2. Upgrade is disabled by default. When allowUpgrade is false, mixed tools will not automatically lift to high (it will keep your selected baseline), and oversized payloads will not automatically become max. To let heavy tasks automatically add more thinking, you need to modify the configuration; do not assume that it will automatically adapt to max across the board after installation.
3. “Simple tools” are judged by name prefixes. web_search and various mcp__... tools are not in the simple set; even if the name looks like a file tool, it will not be treated as a small payload if the parameters are long. The strategy is heuristic, not an exact classification of task difficulty.
4. The settings panel, time consumption display in the UI, and installation instructions for non-web profiles are all incomplete in the README roadmap. What can be verified currently are: the decision core, waterfall flow injection, and host log telemetry.
5. reasoning_effort still needs to pass the official adapter’s verification. The adapter treats off as disabling thinking, and only low / high / max will be sent as the official reasoning_effort; unsupported values will fail with UNSUPPORTED_REASONING_EFFORT before being sent over the network. This plugin injects the latter three levels. If your deployment locks thinking to thinking: disabled, injecting low will have no effect.

Summary¶

dsh-tool-turbo connects the reasoning level already provided by DeepSeek to the agent/request that runs at every step of dsh: downgrade to low for simple tool chains, and consider lifting back for heavy tasks, without modifying the task prompt. It is a community-maintained early-stage plugin (0.1.0, 4 stars), with settings and UI not yet completed, but the installation command, decision table, and source code path can all be matched on the directory page and GitHub.

Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-tool-turbo/

GitHub: https://github.com/Electricitysheep/dsh-tool-turbo