Experiment: keeping DeepSeek Harness minimal with on-demand capabilities

[waywaywayway]

Unofficial community experiment. Independently maintained and not affiliated with or endorsed by DeepSeek.

I have been experimenting with a small DeepSeek Harness preset called LiangShen Lazy:

https://github.com/waywaywayway/deepseek-harness-lazy-capability

The starting point is the LiangShen / 梁神模式 work from zhu1090093659/dsh-web-ui.
LiangShen first made a clean Minimal bootstrap practical in DSH: start V4 Pro with only a
small system/tool surface, then later promote back to the full Harness.

This experiment keeps the Minimal bootstrap idea but changes the second stage:

LiangShen:
Minimal -> promotion -> Full Harness / run_code / restored context

LiangShen Lazy:
Minimal -> request_capability -> only the needed capability -> release -> Minimal

The public preset keeps the system prompt exactly:

You are a helpful software engineer assistant.

That is 46 characters, with four default tools:

bash
str_replace_editor
request_capability
release_capability

There is no Full Harness promotion and no run_code fallback.

What the raw request headers showed

In a long DeepSeek API + V4 Pro Lazy session, the initial header was:

systemChars = 46
toolCount = 4

The model later called request_capability(web_search) on its own. The next header was still:

systemChars = 46
toolCount = 5

Later it decided search summaries were not enough and requested browser. At that point
web_search was still held for the current task, so the next header contained 16 tools total
(base 4 + web_search + 11 browser tools), while the system prompt was still 46 characters.
The full registry never came back.

That run had 329 assistant steps, 316 of them containing reasoning text. Using a simple
case-insensitive literal count over those reasoning blocks:

Let me = 0
We need = 54
Let's = 256

I am not claiming that We need means the model is smarter, or that Let me means it is
worse. I am only treating these phrases as lexical / trajectory fingerprints.

It also reproduced on Windows + OpenCode Go + V4 Flash

A separate raw session used:

Windows
provider = opencode-go
model = deepseek-v4-flash
reasoningEffort = max
initial systemChars = 46
initial toolCount = 4

It had 19 reasoning blocks:

Let me = 0
We need = 15
Let's = 36

After the user clarified that the task required GitHub / internet lookup, the model
independently requested web_search; the next request stayed at 46 system characters and
5 tools.

So the stronger idea that this trajectory only appears through the official DeepSeek API is
not supported by these observations.

Comparison with original LiangShen promotion

In archived original-LiangShen comparison sessions, the request headers directly show:

before promotion:
systemChars = 46
tools = bash + str_replace_editor

post promotion:
systemChars = 59096
systemBytes = 67566
tools = run_code

In the longer comparison, the post-promotion reasoning segment contained 130 literal
Let me occurrences.

One caveat: the first user prompt in that comparison explicitly instructed the model to start
with "We need...", so I do not treat the first We need as natural evidence. The actual
request-surface expansion and the later Let me recurrence are still visible in the raw log.

One negative experiment

I also tried appending roughly 1027 characters of capability-awareness policy to the
46-character persona, telling the model when to proactively request web, vision, skills, etc.
That variant made the earlier trajectory harder to reproduce. Restoring the exact 46-character
system was followed by successful reproductions again.

I consider that an observation / hypothesis, not a causal proof. It is one reason the public
baseline does not add capability-awareness instructions to the system prompt.

What I would like others to reproduce

If you try it, the most useful evidence is not the UI preset label. Please inspect the actual
request/header events and report:

• DSH version
• provider / model / reasoning effort
• exact system text / character count
• complete tool list
• capability requests
• whether run_code or a full registry ever appears
• lexical counts if you want to compare trajectories
• negative results too

The repo includes the preset, verification runners, attribution/provenance notes, and a more
detailed experiment write-up in EXPERIMENTS.md.

Again, this builds directly on the LiangShen author's Minimal bootstrap work. The new part is
the long-lived Minimal-by-default + capability-on-demand + auto-release experiment.

I would be interested in results from other providers, operating systems, and longer real
coding tasks—especially failures or runs where the trajectory does not reproduce.

[waywaywayway]

Update: native pwsh on Windows

The preset mounted the builtin Minimal preset's persistent bash unconditionally. On Windows that shell's PTY backend fails at the first foreground-process inspection, because dsh-subprocess-local implements the process inspector for linux and darwin only:

subprocess-local: terminal inspection is unsupported on platform win32

The base shell is now selected by platform, using the same gate the builtin standard preset uses: the persistent-bash rows are disabled on win32, @deepseek-ai/dsh-tool-pwsh is disabled everywhere else, and baseTools follows. macOS and Linux are unchanged.

The Windows default surface is now:

pwsh
str_replace_editor
request_capability
release_capability

bash no longer appears on the Windows wire surface, and the system prompt is still exactly 46 characters.

Validation run — DSH 0.1.0-rc.6, OpenCode Go, deepseek-v4-flash, reasoningEffort=max:

initial systemChars: 46
initial toolCount:   4
reasoning steps:     11

Let me  = 0
I need  = 0
We need = 6
Let's   = 23

Through pwsh alone the model read files, ran node --test, edited code, and re-ran the suite, finishing at 14/14 passing. No capability was requested, so the surface stayed at four tools for the whole run.

The narrow point: the We need / Let's trajectory previously recorded on Windows did not depend on the broken bash/PTY path — it reproduces on a working native shell. As before, these are lexical / trajectory fingerprints only. They are not evidence of higher intelligence, a hidden expert model, or better reasoning. A single run is also not a rate, and these counts were reported from the live session rather than re-derived from an archived session.jsonl with the counting script, so they should be read as operator-reported.

The repo is updated: presets/lazy-capability/agent.cordis.yml only. capability-broker.mjs is unchanged — no new system policy, no change to the capability enum, mappings, lifecycle, or the request_capability description template. Notes are in EXPERIMENTS.md, section E.