DSH plugin system prompt: how DeepSeek Harness builds it

The DeepSeek Harness system prompt is not a fixed piece of text: the system-prompt package assembles it at the start of every turn from tool descriptions, system instructions and fragments contributed by DSH plugins, then hands it to the model (source). This piece explains where that prefix comes from, how it is assembled, and why it grows with plugins; the whole chain is in how one turn runs, how tool descriptions enter the prefix in the tool pipeline, and cost assessment in DSH plugin context overhead.

Why the system prompt is worth understanding first

In every turn the system prompt is the first thing the model reads, deciding what capabilities it knows about, which rules it follows and which tools it can call — in other words, much of a plugin's effect only reaches the model through it (source). Once you treat it as an analysable object, three common questions land:

1. "Why didn't the model do what I asked?": the model's input is not only your message but a whole prefix; the rules in the prefix and your instruction act together, so a conflict looks like it "ignored you".
2. "Why did behaviour change after installing a plugin?": a plugin either adds fragments to the prefix or changes the tool list, and the model reads both, so behaviour follows.
3. "Why did the context suddenly run out?": the prefix is sent every turn, so what it occupies directly squeezes the remaining window, and more layers make it worse.

Conversely, treating the system prompt as a black box mixes up "plugins, prompt and model behaviour" so you cannot locate a problem. Split it into "who assembles, what goes in, when it happens" and everything becomes traceable.

Who assembles it: the system-prompt package

The DeepSeek Harness system prompt is assembled by the system-prompt package: it gathers fragments into a prefix at the start of a turn and then hands it to the model (source). Three points:

1. Before, not after: the prefix is assembled before the model call and is part of that turn's input; it is not a note added after the model responds.
2. Gathered centrally: plugins do not each concatenate strings but hand their fragments to system-prompt for central assembly, so "who added what" has one place to look.
3. Rebuilt every turn: because it reflects the DSH plugins and config loaded at that moment, it may differ between rounds — change config or swap a plugin and the next turn's prefix can follow.

This is also why it sits alongside agent-loop, llm, tools and session among the core subsystems: it is the link that assembles the opening of the input, not a private concern of some plugin.

What goes into the prefix: three kinds of content

The DeepSeek Harness system prompt prefix holds three kinds of content: tool and capability descriptions, system-level instructions, and fragments contributed by DSH plugins (source). Taken one by one:

1. Tool and capability descriptions: which tools are available, what each is for and what parameters it takes. This connects to the tools subsystem — register more tools and there is usually more to describe, as in the tool pipeline.
2. System-level instructions: the framework's rules and constraints, deciding the model's behavioural boundary. They come from the framework rather than a plugin's ad-hoc note, so they hold for every turn.
3. Plugin-contributed fragments: every loaded DSH plugin can add content to the prefix, and together they form the complete prompt. This layer is the most flexible and the easiest to grow quietly after installing plugins.

Only when the three are joined does the opening the model actually reads exist; understanding the makeup explains why swapping one plugin can change the model's behaviour elsewhere.

When assembly happens: before each turn, and rebuilt each time

Assembly happens at the start of every turn, before the model is called, and it is not one-off but rebuilt each turn (source). Two properties to keep apart:

1. "Before" fixes its standing: sitting ahead of the model, it is the first segment of that turn's input and is read with high priority.
2. "Rebuilt" means it changes: the prefix reflects which plugins are loaded and what the config looks like right now, so two rounds in the same session need not share the same prefix.
3. It is not the session log: a session log is an accumulating event record (see sessions, stored and queried), while the prefix is assembled per turn and used for that call; do not confuse "what history recorded" with "what this turn's prefix says".

A direct corollary: for a new plugin or rule to "be seen" by the model, it must reach the prefix assembly step; a change that cannot enter that step is invisible to the model.

How a DSH plugin affects the prompt

A DSH plugin affects the system prompt by contributing fragments into the assembly step — the system-prompt package gathers them, and plugins take part through a service entry such as ctx.systemPrompt rather than concatenating strings. Two points:

1. Contribution goes through a service entry: in the everything-is-a-plugin architecture, a plugin does not edit core text but hands fragments to the framework's prompt service, which keeps the boundary clear and easy to trace.
2. The effect lasts for later turns: because the prefix is rebuilt each turn, while the plugin stays loaded its contribution keeps appearing in later rounds — which also explains why installing a plugin tends to have a persistent effect rather than a one-off one.

So to judge whether a plugin will affect model behaviour, look at whether it takes part in prompt contribution and how much it contributes.

Why installing plugins makes the context longer

Installing plugins makes the context longer because their fragments enter the DeepSeek Harness system prompt prefix, and the prefix is sent to the model every turn (source). Break the cost down:

1. The prefix is sent every turn: unlike a one-off note, it occupies input budget on every round.
2. Fragments accumulate: each extra layer may add a description or a declaration; one piece may be short, but together they are visible.
3. Tool descriptions grow with them: capability plugins tend to add tools whose descriptions also enter the prefix, so "more tools" and "more text" are two parallel costs.
4. It squeezes the usable window: the more the prefix takes, the less is left for dialogue and model output — which is exactly why the overhead needs assessing.

How to assess and balance it is in DSH plugin context overhead.

How to reduce one plugin's effect on the prompt

To reduce a DSH plugin's effect on the system prompt, work from two layers: disable or remove that entry at the profile layer, or use the plugin's own setting to turn the behaviour off. From cheapest to most expensive:

1. Check for a setting switch first: some plugins make "whether to contribute prompt fragments" configurable, and turning it off is usually easier than uninstalling.
2. Then disable the entry: disabling it in the profile's list means the whole layer does not start, so it contributes nothing.
3. Uninstall last: uninstalling also removes the tools and commands it provides, so do it only after confirming you do not need them.
4. Verify by comparison: observe one round before and after the change and confirm the difference actually comes from this spot, not from something else.

Notes on the system prompt

Read the system prompt as a "prefix recomputed each turn" and many phenomena become explainable.

1. It is not fixed text: it changes with plugins and config, and may differ each turn.
2. It is the opening of the context: it forms the model's input together with the rest of the conversation, read with high priority.
3. Prefix ≠ session log: one is the per-turn input opening, the other an accumulating event record.
4. Adding content costs: each fragment takes budget; more plugins usually means longer.
5. Reduce from two layers: disable or remove a profile entry, or turn off the plugin's own setting.
6. To trace "who added it", look at the contribution source: first find which layer introduced the fragment, then see whether it can be turned off.
7. Full chain in how one turn runs, tool descriptions in the tool pipeline.

Source: DeepSeek Harness docs - core subsystems, docs - tools subsystem.