You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Compact a large Claude thread before auto-resuming it after a usage limit
#24862
Auto-resume limited threads waits for the usage-limit reset and then sends Continue where you left off. straight into the thread (UsageLimitRecoveryWorker.ts). Neither compaction mode covers that resume:
When you return runs in the composer send path, so a server-sent resume never compacts first.
Before the cache expires (beta) only arms after a run that completed. A usage-limited run ends as failed, so the thread never qualifies.
The reset is almost always past the prompt-cache lifetime: 1 hour for a main Claude thread on a subscription, and 5 minutes for child threads on the default subagent TTL (or for API-key/overage sessions). A 5-hour or weekly reset is well past both. So the first resumed turn reads the full history uncached and writes all of it back to the cache (1h writes bill at 2x base input). Every turn after that keeps paying for the bloated context. In practice, the threads that hit a limit are the long ones: 200K-900K tokens is common.
Unattended overnight runs are where auto-resume matters most, and they pay this cost on every wake-up. A tree of delegated children multiplies it, because each child resumes separately on a 5-minute TTL.
Proposal
When auto-resume fires on a Claude thread that is above the idle-compaction token threshold (200K today) and whose prompt cache has expired:
Send /compact first, as a visible T3 turn like the idle compactions (idleCompaction: "onReturn" or a new "onLimitResume" provenance).
Then send the continuation message.
Gate it on the existing Compact idle threads setting (anything but Never), or on a separate toggle under Auto-resume limited threads if maintainers prefer explicit opt-in. The cache-expiry check makes it a no-op when the reset comes before the TTL runs out.
#18069's skip cache writes on cold compaction would combine well with this: a compaction run with caching disabled avoids writing a history that is about to be discarded.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Problem
Auto-resume limited threads waits for the usage-limit reset and then sends
Continue where you left off.straight into the thread (UsageLimitRecoveryWorker.ts). Neither compaction mode covers that resume:failed, so the thread never qualifies.The reset is almost always past the prompt-cache lifetime: 1 hour for a main Claude thread on a subscription, and 5 minutes for child threads on the default subagent TTL (or for API-key/overage sessions). A 5-hour or weekly reset is well past both. So the first resumed turn reads the full history uncached and writes all of it back to the cache (1h writes bill at 2x base input). Every turn after that keeps paying for the bloated context. In practice, the threads that hit a limit are the long ones: 200K-900K tokens is common.
Unattended overnight runs are where auto-resume matters most, and they pay this cost on every wake-up. A tree of delegated children multiplies it, because each child resumes separately on a 5-minute TTL.
Proposal
When auto-resume fires on a Claude thread that is above the idle-compaction token threshold (200K today) and whose prompt cache has expired:
/compactfirst, as a visible T3 turn like the idle compactions (idleCompaction: "onReturn"or a new"onLimitResume"provenance).Gate it on the existing Compact idle threads setting (anything but Never), or on a separate toggle under Auto-resume limited threads if maintainers prefer explicit opt-in. The cache-expiry check makes it a no-op when the reset comes before the TTL runs out.
#18069's skip cache writes on cold compaction would combine well with this: a compaction run with caching disabled avoids writing a history that is about to be discarded.
Related
Version: T3 Code Nightly (2026-10-25), Claude Opus 5.5, macOS.
All reactions