[FEATURE] Tiered context compression to replace blunt summarization

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

aDuring long coding sessions, Claude Code compresses prior conversation context when approaching the ~200K token context window limit. The current compression uses a blunt summarization approach that treats all messages equally — critical project decisions get the same treatment as verbose build output.

This causes:

• Loss of important context (database names, architectural decisions, key constraints)
• - Disorientation after compression ("forgetting" what project we're working on)
• - - Disrupted workflow requiring users to re-explain fundamentals
• - - - Heavy reliance on CLAUDE.md/memory files as manual workarounds for what should be native functionality

In a real-world multi-project codebase (~15 interrelated components, multiple databases, hundreds of stored procedures), compression regularly causes loss of critical constraints like "never modify database X" or "always use pattern Y", requiring re-explanation and risking errors.

Proposed Solution

Current workaround: CLAUDE.md and memory files act as a manual "T0 pinned tier" — critical project context is re-injected on every message and survives compression. This works but is manual, limited, and doesn't address the noise problem (T4).

Other approaches considered:

• RAG (Retrieval-Augmented Generation): Store full conversation in a vector DB, retrieve relevant chunks on demand. Higher complexity, but would provide effectively unlimited conversation length.
• - Compressed memory tokens: Distill old context into dense vectors the model attends to natively. More information density than English summaries, but requires architectural changes (research-stage).
• - - Separate cache model: Small fast model maintains structured state while the large model handles reasoning. Adds latency and infrastructure complexity.
• - - - LIFO stack popping: Just drop oldest messages entirely. Loses critical early-session context (project setup, constraints, decisions) — worse than current summarization.

Tiered relevance offers the best balance of impact, feasibility, and incremental shippability compared to these alternatives.

Alternative Solutions

Current workaround: CLAUDE.md and memory files act as a manual "T0 pinned tier" — critical project context is re-injected on every message and survives compression. This works but is manual, limited, and doesn't address the noise problem (T4).

Other approaches considered:

• RAG (Retrieval-Augmented Generation): Store full conversation in a vector DB, retrieve relevant chunks on demand. Higher complexity, but would provide effectively unlimited conversation length.
• - Compressed memory tokens: Distill old context into dense vectors the model attends to natively. More information density than English summaries, but requires architectural changes (research-stage).
• - - Separate cache model: Small fast model maintains structured state while the large model handles reasoning. Adds latency and infrastructure complexity.
• - - - LIFO stack popping: Just drop oldest messages entirely. Loses critical early-session context (project setup, constraints, decisions) — worse than current summarization.

Tiered relevance offers the best balance of impact, feasibility, and incremental shippability.

Priority

High - Significant impact on productivity

Feature Category

Performance and speed

Use Case Example

aReal scenario from a multi-project codebase with ~15 interrelated components:

1. Session starts: User establishes context — "We're working on TriLockPortal (separate database: TrilockPortal). Never modify TriLockM database for Portal work."
2. 2. User reads 10+ files, runs builds, debugs issues across stored procedures, C# services, and Blazor components
3. 3. ~60 messages in: context compression fires
4. 4. After compression: Claude "forgets" the database constraint and suggests modifying the wrong database, or loses track of SP naming patterns established earlier

With tiered compression:

• T0 (pinned): "Database = TrilockPortal, never modify TriLockM" survives indefinitely
• - T4 (noise): 500-line build outputs, file reads that were only checked once — dropped immediately, freeing ~50K tokens
• - - T2 (reference): "We decided to use cross-DB SELECT (never UPDATE) for identity data" — compressed to a single structured fact instead of the full discussion
• - - - Result: Session continues coherently without the user needing to re-explain fundamentals

Additional Context

_No response_