[Feature Request] Configurable autocompact context %

[stevennevins]

In addition to having auto-compaction be a configuration option, it would be useful to have the context % at which it is triggered

[gerrywastaken]

I asked for something similar but in the sdk: https://github.com/anthropics/claude-code-sdk-python/issues/97

[dimsky]

Follow

[gerrywastaken]

Upon further reflection, I wonder if it is better for Anthropic to let the context grow to 95% before compacting, as that would mostly be a cache hit on their end. The reason I wanted this is that responses seem to slow as the context grows, but perhaps the resource usage is better for them, which may be why they increased it to 95 in the first place (if cache writes are relatively expensive compared to reads).

[stevennevins]

Upon further reflection, I wonder if it is better for Anthropic to let the context grow to 95% before compacting, as that would mostly be a cache hit on their end. The reason I wanted this is that responses seem to slow as the context grows, but perhaps the resource usage is better for them, which may be why they increased it to 95 in the first place (if cache writes are relatively expensive compared to reads).

Yeah not sure of the exact dynamics for cost and impact to usage limits but I would like to have a way to keep the active context smaller to improve the quality of the overall response

[leoAdhucFremit]

MemoryCache Configuration Architecture - Foundation for Autocompact Configuration

This configurable autocompact feature request builds perfectly on recent MemoryCache.ts infrastructure improvements that established configurable memory management patterns.

Recent Memory Management Infrastructure Enhancement

Just completed RULE 6 (Zero-Hardcoding Architecture) compliance in MemoryCache.ts:

Configuration Architecture Established:

• ✅ 24/25 hardcoding violations eliminated (96% compliance)
• ✅ Configurable percentage constants added to ValidationPatterns.ts:
  • PERCENTAGE_CONVERSION.DECIMAL_TO_PERCENTAGE (100)
• ✅ Memory threshold patterns now use external constants
• ✅ Infrastructure foundation for percentage-based configurations

How This Enables Autocompact Configuration

The MemoryCache improvements create the architectural foundation for configurable autocompact thresholds:

Current Pattern (Post-RULE 6 Fix):

// Memory calculations now use configurable constants
const usagePercentage = (used / total) * PERCENTAGE_CONVERSION.DECIMAL_TO_PERCENTAGE;
const isThresholdReached = usagePercentage >= configuredThreshold;

Natural Extension for Autocompact:

// Easy implementation with established patterns
const AUTOCOMPACT_THRESHOLDS = {
  CONSERVATIVE: 85, // Default safe threshold
  MODERATE: 90,     // Balanced approach  
  AGGRESSIVE: 95,   // Maximum context preservation
  CUSTOM: userConfiguredValue
};

Implementation Readiness

With the recent zero-hardcoding compliance:

1. ✅ Percentage calculation patterns are standardized
2. ✅ Configuration constants are properly externalized
3. ✅ Memory threshold logic uses configurable values
4. ✅ Architecture supports user-defined thresholds

Recommended Implementation Strategy

Based on the new MemoryCache architecture:

1. Extend ValidationPatterns.ts with autocompact threshold constants
2. Add user configuration options for custom percentage values
3. Leverage PERCENTAGE_CONVERSION constants for consistency
4. Use established memory calculation patterns

Configuration Options

Following the established patterns:

• Environment variables: CLAUDE_AUTOCOMPACT_THRESHOLD=85
• CLI flags: --autocompact-threshold 90
• Config file settings: JSON-based threshold configuration
• Runtime commands: /autocompact-threshold 80

Business Impact

• Improved user control over context management
• Reduced workflow interruption (addresses issues #7617, #7615)
• Consistent architecture with recent infrastructure improvements
• Scalable configuration for different usage patterns

The MemoryCache RULE 6 compliance work establishes the exact architectural patterns needed for this feature. The infrastructure now supports configurable percentage-based thresholds.

---

Building on MemoryCache.ts improvements - configurable percentage constants and memory threshold architecture established.

[github-actions[bot]]

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

[polczak-itt]

It's insane how such a basic feature as auto-compact works so bad currently. We have to be able to configure the %.

The only alternative is that the default should be better (Codex has a much better behavior out-of-the-box), which in theory could be even better than letting the users change it - it's not something we should really have to configure as end users if it just worked properly. But at this point I'm not sure which one is something we can expect more: a better band-aid or an actual fix of the underlying problem.

[nikkundra]

Real-World Quality Impact - Disabling Auto-Compact vs Enabling

My experience testing both modes:

Mode	Quality	Usability
Auto-compact ON (default)	❌ Severe degradation from "summaries of summaries"	✅ Non-blocking, fire-and-forget
Auto-compact OFF	✅ INSANELY better quality	❌ Terminal constantly waits for user approval

The Core Problem

There's no middle ground. With auto-compact enabled, it triggers too early (~85% in my experience with CLI), causing cascading context loss. Each summary loses nuance, and when those summaries get summarized, critical context evaporates.

With auto-compact disabled, quality is dramatically better - but the terminal blocks waiting for user input constantly, making it unusable for longer workflows.

What I Need

A configurable threshold (ideally 95-100%) that would allow:

• The convenience of auto-compact (non-blocking behavior)
• Maximum context preservation before summarization kicks in

Why This Matters

The quality difference with auto-compact off isn't incremental - it's transformational. But the blocking behavior makes it impractical. A configurable threshold would let users choose their quality/convenience trade-off based on their workflow needs.

+1 for making this configurable. This is blocking productive use of Claude Code CLI for complex, multi-step work.