Harness re-injects identical context blocks (task-list snapshots ×15, 18k tool-schema delta ×2, skill bodies ×5) with no change detection

The numbers here are striking: 559k tokens across 178 task-list snapshot re-injections, 46% of all dynamically injected content, zero information gain after the first injection.

The core issue is change-blindness in the injection layer. The harness is treating "has the session received this block before?" as outside its responsibility, so it re-sends verbatim copies without checking whether anything changed. At 1.2M injected tokens per session, a large fraction is pure padding.

A few things worth considering for the fix path:

1. Content hash on the injection site, not at request construction time. Before appending a block to the conversation, hash it and compare against a per-session "already-sent" set. If unchanged, skip. This covers the task-list snapshot and skill-body cases directly.

1. Delta injection for task lists specifically. Instead of re-sending all task subjects and descriptions on each periodic reminder, send only a header ("N tasks in scope, [X] newly updated since last injection") and the diffs. Most sessions would drop to a single full snapshot plus small deltas.

1. Tool-schema change detection. The 18k delta being re-sent twice sounds like the schema is rebuilt from scratch on each injection cycle rather than compared against the previously-sent version. A simple equality check before schema re-injection would catch this.

1. Injection budget tracking as a first-class metric. The 559k / 1.2M ratio (46%) is a useful number. Surfacing "injected token overhead this session" in the session summary would make regressions visible before they compound.

The harness-level fix is probably the highest-leverage place to act -- it is upstream of everything else and the cost reduction compounds across all sessions.

559k tokens of identical re-injections out of ~1.2M measured — 46% of all dynamically injected content being task-list snapshots alone — is a carefully documented audit. The category breakdown is genuinely useful for prioritizing where CC's de-dup would have the most impact.

Worth noting what this pattern does structurally: each re-injection isn't just wasted tokens at request time. Each one is a new JSONL entry that permanently increases the token mass every subsequent turn has to carry — and the compaction event doesn't clear them either, it summarizes them. So a session with ×15 identical task-list snapshots is carrying roughly 15× the overhead on every turn and polluting the compaction summary with repetitive operational noise instead of actual task narrative. The practical effect is that compaction fires earlier than it should, and when it does, the summary has less real content to preserve.

The accumulated identical entries in the JSONL are something cozempic can trim between sessions. cozempic treat current --diagnose shows the breakdown by category (system-reminder payloads, tool results, etc.) and estimates what's pruneable; --execute applies it. It doesn't have per-class hash-dedup — it prunes based on size thresholds and staleness — but duplicate task-list injections and repeated system-reminder payloads tend to fall squarely in its scope. The effect is keeping the JSONL lean despite the re-injection pattern, so sessions stay under the compaction threshold for more turns.

The root fix is clearly CC-side — hash-check before injecting, or delta-only for the task list (as you suggest). Cozempic is the "clean up the mess" side of that while the fix lands.

Thanks for the detailed measurements. Two of the four classes you list have been addressed: re-invoking a skill that's already loaded no longer appends a second copy of its instructions (v2.1.202), and the deferred-tool reminder being sent twice after a skill invocation was fixed (v2.1.228). Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

The task-list reminder snapshots and skill-availability list re-injection are still worth looking at, so I'll leave this open for those.

🤖 Generated with Claude Code