[FEATURE] Configurable compaction forward size (how much survives auto-compact)

Resolved 💬 3 comments Opened Mar 16, 2026 by mark-hubers Closed Apr 13, 2026

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

With the 1M context window on Opus 4.6, auto-compaction is a different problem than it was at 200K.

The problem:
When compaction triggers (~83% of window), the conversation gets compressed to a small summary (~33-45K tokens). For short sessions that's fine. But for long architecture/planning sessions using the 1M window, losing 95% of context is devastating — decisions, design rationale, and cross-references between topics all disappear.

I just did a 15-hour architecture session at 605K tokens. Every topic connected to every other topic. If compaction fires and only 40K survives, I'd lose the thread between design decisions that took hours to work through.

The request:
A configurable setting for how much context survives compaction:

CLAUDE_AUTOCOMPACT_FORWARD_SIZE=150000

Or in settings.json:

{
  "autoCompactForwardTokens": 150000
}

Why this matters now:

  • At 200K, there wasn't room for a big summary. At 1M, there's plenty of room.
  • Architecture and planning work needs continuity across hours, not minutes.
  • The current ~40K forward size was designed for 200K windows. It should scale with the window.
  • Users on 1M context are paying for that space — let us use more of it for compaction survival.

Suggested defaults:

  • 200K window: 40K forward (current, fine)
  • 1M window: 150-200K forward (proportional)

This pairs well with the existing CLAUDE_AUTOCOMPACT_PCT_OVERRIDE env var — one controls WHEN to compact, this controls HOW MUCH to keep.

Thanks for making the 1M context available — it's transformative for deep work. This would make it even better by reducing the cost of the one interruption that still breaks flow.

Proposed Solution

When auto-compaction triggers, allow users to configure how many tokens survive in the compressed summary:

Environment variable:

CLAUDE_AUTOCOMPACT_FORWARD_SIZE=150000

Or in settings.json:

{
  "autoCompactForwardTokens": 150000
}

This pairs with the existing CLAUDE_AUTOCOMPACT_PCT_OVERRIDE — one controls WHEN to compact, this controls HOW MUCH to keep afterward.

Default behavior unchanged. Users who don't set it get current behavior (~40K forward). Users on 1M context who need more continuity set it higher.

Alternative Solutions

Currently I work around this by:

  • Saving critical decisions to files before compaction hits (SESSION-HISTORY.md, tracker files)
  • Using recall-context.sh to query the chat database after compaction
  • Re-reading 5-6 files at session start to rebuild context manually
  • Running /compact manually at natural breakpoints so I control the timing

These work but cost 15-20 minutes every time compaction fires. With 1M context and architecture sessions running 10-15 hours, compaction still interrupts deep work.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

  1. I'm doing architecture planning for a multi-product system (database schema, methodology, CLI design)
  2. Session runs 15 hours, reaches 605K of 1M context
  3. Every topic connects to others — database tables reference CLI commands reference methodology steps
  4. At ~835K, auto-compact fires
  5. Currently: ~40K summary survives. I lose the connections between topics. Spend 20 min re-reading files.
  6. With this feature: 150K summary survives. Key decisions, design rationale, and cross-references preserved. I keep working without interruption.

The 1M window made the session possible. Configurable forward size would make compaction painless.

Additional Context

  • Opus 4.6 with 1M context (claude-opus-4-6[1m]) went GA March 13, 2026
  • At 200K, small forward size made sense (no room). At 1M, there's 165K of headroom after compaction — plenty of room for a larger summary.
  • Related issues: #23711, #25528, #29760 (two-tier architecture), #27293 (lossless cleanup)
  • This is the simplest possible change: one number, proportional to window size

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗