Feature request: lossless context cleanup before auto-compaction
Problem
/compact replaces the entire conversation with a short summary. This is lossy — it destroys reasoning, decision context, and nuance. A 150k-token session where you spent 40 minutes mapping architecture becomes "We discussed the codebase architecture and identified key patterns."
But the majority of a typical session's context isn't conversation at all. From analysis of 33 real Claude Code sessions (full methodology and data):
| Content | % of context | Value on reload |
|---------|-------------|-----------------|
| Tool results (file contents, bash output) | ~60-70% | None — already synthesised by the model |
| Thinking signatures (base64 blobs) | ~15-20% | None — cryptographic verification, not reasoning |
| Actual conversation | ~10-15% | All of it |
Proposal
Before compaction triggers, stub mechanical overhead while preserving every message verbatim:
tool_resultblocks over N chars →[File read: src/auth.ts, 847 lines]tool_useinputs (Write/Edit file contents) →[Trimmed input: ~N chars]- Image blocks (base64 screenshots) → stripped
- Thinking block signatures → stripped
- Pre-compaction dead lines, file-history snapshots, queue operations → skipped
The model's own synthesis stays intact. If it needs a file again, it can re-read it.
Evidence
I built Contextual Memory Virtualisation (CMV) to test this approach. Results from the cache impact analysis across 33 real sessions:
- Benchmark-estimated reduction: 10.5% mean (conservative model that understates by ~2x — see methodology)
- Observed reduction: ~50% when validated against actual
/contextoutput (148k tokens → 74k tokens, documented with screenshots) - 97% context → ~20% on a near-full session using the v1.1.0 trimmer, with no observable quality degradation
- Zero conversation loss — every user message, assistant response, and tool use request is preserved verbatim
For API-key users, the one-time cache miss penalty from trimming ($0.07-0.22) is recovered within 3-45 turns of continued conversation. For subscription users, there is no cost implication at all — it's purely a context window optimization.
The community response suggests this is a widely felt pain point.
Why this matters
Context is the most expensive thing users build. It takes real time and real tokens to get Claude up to speed on a codebase. /compact treats that accumulated understanding as disposable. A lossless cleanup step before (or instead of) lossy compaction would let users keep working in the same session far longer without quality degradation.
The model doesn't struggle after trimming because you're removing inputs to understanding, not the understanding itself. When Claude reads 847 lines and responds "this uses JWT with refresh tokens in httpOnly cookies", that sentence is the knowledge. The 847 lines were consumed to produce it.
14 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
As mentioned above, I've implemented this in CMV's trimmer so more than happy to contribute a PR implementing this.
Related issues: #17428, #25967, #23504
This is closely related to #27242, which documents three scenarios where conversation history is preserved in JSONL but inaccessible from the TUI: post-compaction (Ctrl+O/E don't show pre-compaction content), post-plan-mode ("clear context" severs session history), and branch navigation (right-arrow in
/resumepicker broken).Your lossless cleanup proposal would help prevent the problem at the source. Meanwhile #27242 tracks the fact that even the data we already preserve is inaccessible. If this affects your workflow, please 👍 and comment on #27242 to help consolidate engagement toward the triage threshold.
This is exactly the gap I've been trying to fill. While waiting for a native fix, I've been using Mantra (mantra.gonewx.com) — it keeps a full session timeline anchored to git states, so even if compaction loses context, you can replay exactly what the AI saw and did. Not lossless in the true sense, but gives you the full picture to recover from. Might tide you over until this lands natively.
@CosmoNaught this looks pretty interesting. How does the tool avoid running stale? Like, the readme says you can branch out from the same base context multiple times. Is the source context kept up to date? How about the context already shared with branches?
Thanks for linking #27242 — I'm aware of it, but this proposal is intentionally distinct. #27242 tracks the symptom (preserved data being inaccessible from the TUI). This issue proposes a concrete solution via a lossless pre-compaction cleanup step, with a working implementation, benchmarks across 33 sessions, and documented results showing ~50-80% context reduction with zero conversation loss.
Consolidating engagement toward a broader tracking issue would actually dilute the specific, actionable proposal here. I'd rather keep discussion focused on the merits of the approach. Thanks.
Appreciate the thought, but this issue is a feature request for native Claude Code behaviour and not a thread for third-party tool recommendations. The whole point of the proposal is that this should be built in, with the data to back it up.
If Mantra is relevant to #27242's broader accessibility concerns, that might be a better place for it. Thanks.
Thanks, good question! Snapshots are point-in-time by design, like git commits. They don't update after creation, and that's intentional. The whole point is that a snapshot captures a known-good state of understanding you can reliably branch from.
So if you snapshot after a 20-minute architecture deep-dive and branch three times from it, all three branches start from that exact state but they're fully independent after that. Work in one branch doesn't affect the others or the original snapshot.
If your codebase moves on and you want a fresher base, you just snapshot a newer session. You can also chain snapshots. Work in a branch, snapshot that, branch from the new one, so context builds up over time rather than going stale.
The model for staleness is basically the same as git. A branch doesn't track upstream automatically, but you can always create a new one from a more recent point. The snapshots themselves are cheap (just JSONL copies) so there's no cost to snapshotting often. Hope this helped!
Appreciate the detailed answer!
This is exactly what we needed too — lossless cleanup instead of lossy compaction. We coded cozempic to solve this and open-sourced it.
It runs 13 composable strategies that remove dead weight (progress ticks, duplicate system-reminders, stale file reads, oversized tool outputs, metadata bloat) while keeping your actual conversation, decisions, and tool results intact. Typical sessions carry 20-50% noise — removing it means compaction triggers less often and has cleaner input when it does.
Also ships as a Claude Code plugin with MCP tools and a guard daemon that auto-prunes before compaction fires. Feedback welcome.
I've done extensive analysis on this exact problem. Using ccusage_go (open-source Claude Code usage tracker), I found that Cache Read tokens consumed 97.7% of my session costs — API actual cost was $1.47, total billed cost was $64.98 (a 44x markup). Cache also degrades instruction following in long sessions, which I documented with per-turn JSONL analysis.
Full write-up with data, community issue references, and Claude Code's own self-analysis report:
https://blog.sd.idv.tw/en/posts/2026-03-25_claude-code-cache-trap/
Tool: https://github.com/SDpower/ccusage_go
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.