tool-skill repeatedly emits unchanged replacement catalogs during continuable subagent turns

[zerocorebeta]

The native skill catalog listener republishes an identical skill-catalog replacement message on repeated agent/pre-step cycles.

This becomes visible when a parent agent uses a continuable subagent such as browser_subagent. The catalog contents do not change, but DSH emits multiple “Replacement catalog” messages, wasting context tokens.

Environment

• macOS
• DSH Web
• @deepseek-ai/dsh-tool-skill@0.1.1-rc.2
• Node.js 26
• Simple preset
• A model-visible skill catalog
• A continuable subagent

Reproduction

1. Configure a session with a model-visible skill, for example browser-delegation.
2. Add a continuable subagent tool.
3. Start a task that invokes the subagent.
4. Allow the subagent to report back or perform multiple turns.
5. Inspect the session transcript.

Actual behavior

The same catalog is emitted repeatedly as a replacement:

Context injection · skill-catalog
Replacement catalog
browser-delegation ...

The session contained identical catalog entries at multiple event sequences: 10, 55, 175, 241, and 404.

The catalog contents were unchanged each time.

Expected behavior

The catalog should be emitted once initially and only be replaced when its canonical skill entries actually change.

Subsequent agent/pre-step cycles should reuse the existing catalog without adding another replacement message.

Additional findings

I instrumented both the custom capability plugin and the native DSH listener. The repeated publications came from:

@deepseek-ai/dsh-tool-skill

The custom plugin did not publish the duplicate messages.

The issue appears related to the native listener relying on session surface/history state during repeated pre-step cycles. Recently injected catalog messages are not consistently available to the next cycle’s history check, so the listener treats the unchanged catalog as changed.

A per-agent in-memory digest guard prevents the problem.

Suggested fix

Track the last published catalog digest per agent/session, or make the durable history check include recently injected catalog messages before deciding to emit a replacement.

Do not emit a replacement when:

currentCatalogDigest === lastPublishedCatalogDigest

This should remain true across continuable subagent turns and subagent report delivery.

[argszero]

Thanks for the precise write-up — this is very reproducible. I verified the native listener against the npm package you're running (dsh-tool-skill@0.1.1-rc.2) and against the current alpha sources (repo HEAD 0.1.2-alpha.4 and npm 0.1.2-alpha.5): the dedup logic is behaviorally identical across all three (the alpha line only refactors it — a ...decision spread fix and an eventAt() accessor change), so this is a live issue, not one already fixed upstream.

How the listener actually decides (catalog pre-step listener + catalogHistory() in the tool-skill package; same logic at rc.2 lib/index.js:198-210 and 309-323):

1. digest = sha256 of the current catalog entries
2. catalogHistory(agent) walks the durable log backwards to the newest skill-catalog event whose seq is present in session.surface.nodes, and returns that digest plus published=true. surface.nodes is the folded model-visible surface; replacement surface events deliberately SHADOW the ranges they replace (session surface module: "the model-visible surface deliberately shadows replaced ranges"), and context reconstruction excludes shadowed events (runtime-context.ts:35-44)
3. If that visible digest equals the current digest — the catalog is already in the model-visible durable context — the listener strips any copy restored into this step's messages (no re-render)
4. Else, if this step's message array already carries a catalog with the same digest, it keeps it as-is
5. Only otherwise does it re-render: an initial catalog if none was ever published, or a full "Replacement catalog" appended as a NEW durable event

So a replacement is emitted exactly when the guard believes the newest catalog is NOT in the current surface — which matches what you instrumented ("recently injected catalog messages are not consistently available to the next cycle's history check"). The remaining question is why the catalog drops out of surface.nodes between pre-step cycles, because the right fix differs by mechanism:

(A) Genuine eviction (compaction / context trim). Re-rendering is correct by design here — the model must not keep acting from a catalog it can no longer see. A naive per-agent "same digest → never re-emit" guard would regress exactly this recovery path.

(B) Surface re-anchor shadowing. If the duplicate emissions align with continuable-subagent boundaries, the continuation materializes its context by REPLACING a surface range; when that range includes the catalog event, the catalog leaves surface.nodes while still present in the durable log. The next pre-step then legitimately sees "no visible catalog", appends a full replacement copy, and the durable log accumulates identical full copies per re-anchor (your seqs 10 / 55 / 175 / 241 / 404) even though the digest never changed. If this is your case, the fix belongs in the seam between the re-anchor and the guard — e.g. copy the last catalog event forward into the replacement range (the session layer already re-synthesizes closer events the same way on resume), or key a digest guard on "still present in the durable log" rather than on surface membership, so an unchanged catalog that was shadowed (not compacted) is not re-rendered.

The fastest discriminator: at the pre-step where seq 55's replacement was emitted, did the assembled model context still contain the seq-10 catalog (two copies visible → the guard's inputs diverge from what the model sees), or had seq 10 already dropped out of the visible context (single visible copy per step, accumulation only in the durable log)? The replacement surface events in the transcript list their sourceEventSeqs, which will show the shadowing directly. A snippet of the events around one re-emission boundary (plus which agent's pre-step emitted each replacement — parent resume vs subagent continuation steps, since both fire pre-step on the shared session) would let me pinpoint which branch of the guard is misfiring.

[lucas-wang-1]

Independent measurement that adds the cache-cost side of this exact issue, from a DSH Web on Windows (deepseek-v4-flash via opencode-go), reading the same ~/.dsh/sessions zstd logs.

1. Catalog accumulation is real and is not limited to content-unchanged replays. In one session on 2026-09-07 the skill catalog changed four times (seq 9 initial, then seq 55 / 240 / 298 updates). All four messages are skill-catalog user messages with distinct ids, all appended as new durable events. The old copies are never removed from the middle of the message stream — the replacement path in the pre-step listener (decision.messages.map(id → catalog)) can never match them because they live in session history, not in the current step's message array.

2. Each appended copy is a prefix cache break. That session showed miss surges of 78k and 212k tokens immediately after catalog updates, vs ~1k steady-state misses between updates. Across the day, 16 miss surges (>20k and >4x the previous call) accounted for 67% of all cache-miss input tokens (1.5M of 2.2M); steady-state per-call misses were actually lower than the previous two days (1.84k vs 2.37k/1.99k). So the entire hit-rate drop (95.0% vs 96.5%/96.7%) is attributable to these break events, not to the cache itself.

3. On the A/B discriminator you asked for: in our case the catalog digest genuinely changed (genui/modsearch entries were added and removed mid-session), so this is closer to your branch (A)-adjacent re-render plus accumulation — but the old copies staying in the durable log and in the surface means the guard never gets a chance to prune them, and each new append re-breaks the prefix. Worth checking whether the guard should act on the durable-log digest (last published catalog, regardless of surface membership) and additionally remove/replace the stale copies, not just append.

4. Practical impact: one update = one full re-prefix of the conversation. For long sessions with several catalog changes (plugin installs/reloads that alter the visible catalog), this dominates the miss budget. Tool schemas in the system prompt are constant; the catalog messages planted mid-stream are the churn.

[lucas-wang-1]

Standalone follow-up / sibling report (independent of the replay case above; cross-links the cache-cost angle)

Title: Skill catalog updates append stale mid-stream copies that are never pruned — each update re-breaks the provider prefix cache

Full report: see my earlier comment (#5420 (comment)). Short version:

1. On 2026-09-07 one session's catalog changed four times (seq 9 / 55 / 240 / 298); all four skill-catalog messages were appended as new durable events with distinct ids, and the old copies were never removed from the middle of the stream. decision.messages.map(id -> catalog) can't prune them because they live in session history, not the current step's message array.
2. Each appended copy is a prefix-cache break: 78k and 212k miss surges immediately after updates, vs ~1k steady-state. Across the day, 16 such surges accounted for 67% of all miss input tokens (1.5M of 2.2M), while steady-state per-call misses were lower than the previous two days (1.84k vs 2.37k/1.99k). Net: hit rate 95.0% vs 96.5-96.7% baseline, fully attributable to these break events.
3. This is the sibling of the surface re-anchor case in OP: here the digest genuinely changed, yet stale copies stay in both the durable log and the surface, so nothing prunes them. Suggested fix: key the guard on the durable-log digest (last published catalog, regardless of surface membership) and remove/replace stale copies so at most one catalog message remains, at the tail.

Impact: one catalog update = one full re-prefix. Plugin installs/reloads that change the visible catalog dominate the miss budget in long sessions.