Compaction re-injects previously-invoked skill bodies in full — on 200K-window models the restored baseline can consume ~50% of context; request catalog-style restoration + a pin mechanism
Summary
After auto-compaction, the harness re-injects every skill invoked earlier in the session into the post-compact context under the banner "The following skills were invoked EARLIER in this session … shown here for context only", mostly as full bodies. On large-window models this is a tolerable tax; on a 200K-window model it can dominate the window and produce a rapid compaction loop.
Measurement (live session, claude-haiku-4-5)
- Session compacts at ~155K tokens (normal ~78% threshold for the 200K window).
- Immediately post-compaction, the fresh context already holds 98,657 tokens — the restoration payload (5 previously-invoked skills re-injected as full bodies, plus summary and file-reference reads).
- Working room per cycle ≈ 55K tokens → one large artifact write ≈ one compaction → the session compacts "after very little" user-visible work, repeatedly. Observed twice in a row within minutes.
A sibling session on the same machine shows the same banner after its own summarization carrying 8 skills, several at 3–5K words each.
The interesting part: partial catalog behavior already exists
In the sibling session's post-compact context, some re-injected skills are truncated with:
[... skill content truncated for compaction; use Read on the skill path if you need the full text]
— i.e. the harness already knows how to restore a skill as a pointer instead of a body. But other skills in the same banner are carried in full. The inconsistency is the bug-shaped part: the truncation-with-pointer form is exactly right, it just isn't the default.
Request
- Catalog-not-inline by default: restore previously-invoked skills as name + one-line description + the existing "use Read on the skill path" pointer, for all skills, not some.
- A pin/eager mechanism (e.g. skill frontmatter flag): some skills govern the session's operating discipline and must survive compaction in full — lazy-loading those creates a bootstrap problem (a session resuming mid-workflow needs the workflow rules in context at wake; knowing-to-fetch-the-rules is itself part of the rules). Let the skill author or user mark those; everything else gets the pointer.
The same inline-vs-catalog correction was recently applied to an MCP server's session-init payload in our stack (150K of inlined skill bodies → catalog + fetch-on-demand) with no behavioral loss — the model reliably fetches what it needs when the pointer is explicit.
Environment
- claude-code CLI, Linux
- Observed on claude-haiku-4-5 (200K window); the same mechanism is a smaller relative tax on 1M-window models
- Related but distinct from #76147 (that one was compaction firing at the wrong threshold; here the threshold is correct and the restored baseline is the problem)