[FEATURE]

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

Title: Context compaction wastes compute and destroys work — not a one-time issue

Summary

Context compaction is actively harmful to both the user experience and Anthropic's compute costs. It does the opposite of what it's designed to do. This is not a one-time occurrence — it happens regularly and consistently turns what should be quick tasks into hour-plus ordeals.

Session ID: b53d1047-9288-4acc-a193-49e07983c4a5
Date: 2026-03-14
Start: 10:55 AM PDT
End: 12:55 PM PDT
Model: claude-opus-4-6

What happened (today's example)

I have a documentation workflow with Claude Code. The goal is 20 minutes — and even that target is inflated by accumulated compaction problems from previous sessions. Today it took 120 minutes. Here's why:

1. I pasted 3 session addendums plus my current quick reference backlog and full backlog into the conversation.
2. Claude completed the quick reference backlog and full backlog updates.
3. Claude told me I could delete my addendums from my local docs because "I have them."
4. Context compaction fired.
5. Everything was gone — the addendums, both completed backlogs, all working context.
6. I had to re-paste every document. The addendums Claude told me to delete? I had to go find them and paste them again.
7. Claude then wrote build log entries from the compaction summary instead of the actual source documents, producing lower quality output.
8. Claude claimed documentation times that were clearly wrong (said "8 minutes" when it obviously hadn't been 8 minutes).
9. Claude wrote build log entries in the wrong order because compaction lost the format reference from previous entries.
10. Claude had to grep through its own conversation transcript JSONL file to recover build log entries it had already written before compaction destroyed them.

This is not a one-time occurrence

While 2 hours is extreme, this is a typical experience. Our documentation target is 20 minutes. Documentation sessions regularly take over an hour. That is solely because of context compaction. There is no other issue causing this.

And documentation is just one example — it's not even close to the worst impact. Compaction causes serious problems with actual code:

• Features disappear or malfunction because Claude loses context about what was already built and edits code based on incomplete information.
• New features deploy wrong because Claude doesn't build with the latest information — it builds with whatever the compaction summary retained, which is never the full picture.
• Claude makes confident claims about code it no longer has context for, leading to bugs that take additional sessions to diagnose and fix.

Compaction does the opposite of what it's designed to do

The purpose of compaction is to save compute. In practice, it wastes compute — over and over again. Every time compaction fires:

• The user has to re-paste documents (more input tokens)
• Claude has to redo work it already completed (more output tokens)
• Mistakes from incomplete context require additional rounds of correction (more tokens)
• Recovery work like searching JSONL transcripts burns tokens on overhead that shouldn't exist

Today's session used roughly 4x the compute it would have needed without compaction. This pattern repeats regularly.

The trust problem

Claude told me to delete my source material because "I have it." Then compaction threw it away. This isn't a minor UX issue — Claude actively caused data loss by giving advice it couldn't back up. If Claude can't guarantee it will retain information across a session, it should never tell users they can delete their copies.

Suggestion

At minimum:

• Give users control. Let me opt out of compaction entirely. I'd rather hit a context wall and know it than have context silently destroyed mid-task.
• Never compact user-pasted content without warning. If I paste a 500-line document, that document is there for a reason.
• Preserve Claude's own recent output. If Claude just generated a deliverable, don't throw it away 5 minutes later.
• Don't let Claude tell users to delete source material. If retention isn't guaranteed, Claude shouldn't imply that it is.

Proposed Solution

At minimum:

• Give users control. Let me opt out of compaction entirely. I'd rather hit a context wall and know it than have context silently destroyed mid-task.
• Never compact user-pasted content without warning. If I paste a 500-line document, that document is there for a reason.
• Preserve Claude's own recent output. If Claude just generated a deliverable, don't throw it away 5 minutes later.
• Don't let Claude tell users to delete source material. If retention isn't guaranteed, Claude shouldn't imply that it is.

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

Performance and speed

Use Case Example

Session ID: b53d1047-9288-4acc-a193-49e07983c4a5
Date: 2026-03-14
Start: 10:55 AM PDT
End: 12:55 PM PDT
Model: claude-opus-4-6

What happened (today's example)

I have a documentation workflow with Claude Code. The goal is 20 minutes — and even that target is inflated by accumulated compaction problems from previous sessions. Today it took 120 minutes. Here's why:

1. I pasted 3 session addendums plus my current quick reference backlog and full backlog into the conversation.
2. Claude completed the quick reference backlog and full backlog updates.
3. Claude told me I could delete my addendums from my local docs because "I have them."
4. Context compaction fired.
5. Everything was gone — the addendums, both completed backlogs, all working context.
6. I had to re-paste every document. The addendums Claude told me to delete? I had to go find them and paste them again.
7. Claude then wrote build log entries from the compaction summary instead of the actual source documents, producing lower quality output.
8. Claude claimed documentation times that were clearly wrong (said "8 minutes" when it obviously hadn't been 8 minutes).
9. Claude wrote build log entries in the wrong order because compaction lost the format reference from previous entries.
10. Claude had to grep through its own conversation transcript JSONL file to recover build log entries it had already written before compaction destroyed them.

This is not a one-time occurrence

While 2 hours is extreme, this is a typical experience. Our documentation target is 20 minutes. Documentation sessions regularly take over an hour. That is solely because of context compaction. There is no other issue causing this.

And documentation is just one example — it's not even close to the worst impact. Compaction causes serious problems with actual code:

• Features disappear or malfunction because Claude loses context about what was already built and edits code based on incomplete information.
• New features deploy wrong because Claude doesn't build with the latest information — it builds with whatever the compaction summary retained, which is never the full picture.
• Claude makes confident claims about code it no longer has context for, leading to bugs that take additional sessions to diagnose and fix.

Compaction does the opposite of what it's designed to do

The purpose of compaction is to save compute. In practice, it wastes compute — over and over again. Every time compaction fires:

• The user has to re-paste documents (more input tokens)
• Claude has to redo work it already completed (more output tokens)
• Mistakes from incomplete context require additional rounds of correction (more tokens)
• Recovery work like searching JSONL transcripts burns tokens on overhead that shouldn't exist

Today's session used roughly 4x the compute it would have needed without compaction. This pattern repeats regularly.

The trust problem

Claude told me to delete my source material because "I have it." Then compaction threw it away. This isn't a minor UX issue — Claude actively caused data loss by giving advice it couldn't back up. If Claude can't guarantee it will retain information across a session, it should never tell users they can delete their copies.

Additional Context

_No response_