[Feature]: Make stale Claude resume-compaction token threshold configurable #19823

Problem

T3 Code offers Compact on a Claude thread after its prompt cache expires once the thread reaches 100,000 tokens. The chip defaults to compact-before-send, so pressing Enter after returning to an idle session first compacts the existing conversation and only then sends the typed message.

I often work with long-lived coding-agent threads, including models with a 1M-token context window. At 100K, there may still be plenty of useful context and headroom. I want to preserve architectural decisions and other details rather than accidentally replace the history with a summary.

The threshold is currently hardcoded:

// apps/web/src/components/chat/ContextWindowMeter.logic.ts
const CLAUDE_RESUME_COMPACTION_TOKENS = 100_000;

This is different from Claude's Settings → Providers → Claude → Auto-compact after. Setting that to, say, 300K or 500K does not change when the stale-thread Compact chip appears.

Proposal

Add a setting for the resume-compaction suggestion threshold, separate from the existing auto-compaction setting.

• Suggested UI: Settings → Providers → Claude → Suggest compaction on resume after [token count].
• Keep 100,000 as the default for backward compatibility.
• Allow higher thresholds, e.g. 300,000 or 500,000, particularly for 1M-context models.
• Ideally also allow Never, so users who prefer to manage compaction manually can disable the suggestion.
• Only offer the stale-session Compact chip when both conditions are met: the prompt cache has expired and the configured token threshold has been reached.

This would preserve the existing cache-expiry behavior while letting users choose how early the suggestion becomes relevant.

Example

With a configured threshold of 300,000 tokens:

1. Work in a Claude thread until it reaches 120K tokens.
2. Leave it idle until the prompt cache expires.
3. Return and send a prompt. No Compact chip should appear, and the prompt is sent with full history.
4. Later, when the thread reaches 320K tokens and becomes stale again, the existing Compact suggestion can appear.

Why not just use "Auto-compact after"?

That setting controls when Claude compacts due to context usage. The stale-resume chip is a separate T3 Code decision based on a fixed 100K threshold and cache TTL. Users configuring one should not have to assume it controls the other.

Related discussions

The question of whether Compact should be on by default is already being discussed in Ideas #17170 and was raised in #17467 / #19182. A persistent Full by default preference would also help avoid accidental compaction, but this request is intentionally narrower: let users configure the 100K threshold independently.

Thanks!