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

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 31, 2026

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

  1. 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.
  2. 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)

View original on GitHub ↗