Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Feature request: graceful performance degradation preferred over silent context compaction [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#56385•Fetched 2026-05-06 06:29:30
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Author
jodybrownelljodybrownell
Participants
github-actions[bot]github-actions[bot]jodybrownelljodybrownell
Timeline (top)
commented ×2labeled ×2cross-referenced ×1

Error Message

  1. If compaction is truly unavoidable (hard limit), warn with enough lead time for the user to run /compact themselves and control what gets preserved.

Root Cause

  • Users pay for context window capacity. Silent compaction removes what they paid for.
  • For professional users building production software, the conversation context IS the working memory. It's not disposable.
  • Trust in the tool requires predictable behavior. Silent data loss — even "just" conversation data — destroys trust.
  • The user's context is their property. Wiping it without consent is a UX failure regardless of the technical justification.
RAW_BUFFERClick to expand / collapse

The Problem

When a conversation approaches the context limit, Claude Code silently auto-compacts the conversation — summarizing earlier messages to make room. The user gets no warning, no prompt, no choice. Their working context is wiped without consent.

This happened to me mid-session while building a production application. I lost a multi-day conversation's worth of working context — exact code discussions, decision rationale, nuanced back-and-forth — with zero warning. I'm paying for this context window. Having it silently taken away is unacceptable.

What Should Happen Instead

Performance degradation should be preferred over compaction. Specifically:

  1. Never auto-compact without explicit user consent. Ask the user: "Context is getting deep — do you want me to compact now, or keep going?" Wait for a yes.

  2. If the user says no, degrade gracefully:

    • Slower responses are acceptable
    • Reduced tool parallelism is acceptable
    • Shorter responses are acceptable
    • Losing working context without consent is NOT acceptable

  3. Give the user visibility into context usage. A simple indicator (percentage used, messages remaining, something) so they can make informed decisions about when to compact on their own terms.

  4. If compaction is truly unavoidable (hard limit), warn with enough lead time for the user to run /compact themselves and control what gets preserved.

Why This Matters

  • Users pay for context window capacity. Silent compaction removes what they paid for.
  • For professional users building production software, the conversation context IS the working memory. It's not disposable.
  • Trust in the tool requires predictable behavior. Silent data loss — even "just" conversation data — destroys trust.
  • The user's context is their property. Wiping it without consent is a UX failure regardless of the technical justification.

Environment

  • Claude Code CLI
  • Claude Opus 4.6 (1M context)
  • Long multi-day session with heavy tool usage (hundreds of tool calls, large diffs)

extent analysis

TL;DR

To prevent silent auto-compaction, the system should prioritize performance degradation over compaction and provide explicit user consent mechanisms.

Guidance

  • Implement a warning system that alerts the user when the context limit is approaching, allowing them to decide whether to compact the conversation or continue with potential performance degradation.
  • Introduce a context usage indicator to provide users with visibility into their context usage, enabling them to make informed decisions about compaction.
  • Modify the system to degrade gracefully when the user declines compaction, accepting slower responses, reduced tool parallelism, or shorter responses instead of losing working context.
  • Consider adding a manual compaction option (/compact) that users can invoke to control what gets preserved when compaction is unavoidable.

Example

No code snippet is provided as the issue focuses on the desired behavior and user experience rather than specific implementation details.

Notes

The solution requires changes to the Claude Code CLI and potentially the underlying system architecture to prioritize user consent and provide more control over conversation compaction.

Recommendation

Apply a workaround by implementing a warning system and context usage indicator to provide users with more control over conversation compaction, as upgrading to a fixed version is not mentioned in the issue. This approach addresses the user's concerns about silent data loss and trust in the tool.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#inference speed#output truncation#response parsing#generation error#database connection

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Feature request: graceful performance degradation preferred over silent context compaction [2 comments, 2 participants]