[Bug]: Idle compaction fires during an active usage limit, and its failure makes recovery resume the idle thread with a full uncached read #36916

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Use a Claude provider on a subscription (1-hour prompt cache) with auto-resume after usage limits turned on and "Compact idle threads" set to "Before the cache expires".
2. Let a Claude thread with more than 200K tokens of context complete a turn and go idle.
3. Before that thread's prompt cache expires, hit the provider's 5-hour usage limit, from this thread or from another one.
4. Wait for idle compaction to fire on the idle thread, then wait for the limit reset.

Expected behavior

No compaction is sent to a thread while its provider reports an active usage limit. If a compaction does fail on a usage limit, usage-limit recovery does not send "Continue where you left off." to that idle thread. Or it retries the compaction instead of continuing the conversation.

Actual behavior

Idle compaction sends /compact to the idle thread about 2 minutes before its prompt cache expires, even though the usage limit is already hit. The compaction fails:

Error during compaction: You've hit your 5-hour limit · resets 7pm (Europe/London)

That failure marks the thread as failed with usage_limit, so usage-limit recovery arms it. At the reset, recovery sends "Continue where you left off." to a thread that had nothing left to do. The prompt cache expired long before, so the provider re-reads the whole conversation uncached. In our case the first request after the reset wrote 260,214 tokens to the cache and read none. The thread then found no pending work and stopped. This spends a large part of the new usage window on an idle thread. It happens to every idle Claude thread above 200K tokens whose compaction window falls inside the limit.

Code pointers, at commit 5a15495 (v0.1.10-nightly.20261114.4695):

• apps/server/src/orchestration-v2/IdleCompaction.ts line 61 and lines 95-105: the compaction decision checks the run state and the prompt-cache expiry, but not the usage-limit state.
• apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.ts lines 23-31 and 65-73: any failed run classed usage_limit with a future reset is armed and later resumed with a plain continuation, including a failed compaction run.

Related, not duplicates: #17184 (a compaction cancelled by the user sends a continuation, closed) and PR #27742 (an opt-in setting to compact before a usage limit is reached, which does not stop compaction from firing while the limit is active).

Suggested fix: skip idle compaction while the provider reports an active usage limit. Do not arm usage-limit recovery for a failed compaction run, or recover it by retrying the compaction instead of sending a continuation.

Impact

Major degradation or frequent failure

Version or commit

v0.1.10-nightly.20261113.4630 (observed). The same code is in v0.1.10-nightly.20261114.4695, commit 5a15495.

Environment

Linux desktop app (nightly), Claude Code provider on a Claude subscription, Claude Opus 5.5

Logs or stack traces

17:31:39 UTC  idle compaction sends /compact to the idle thread
17:31:40 UTC  Error during compaction: You've hit your 5-hour limit · resets 7pm (Europe/London)
19:00:07 UTC  usage-limit recovery sends "Continue where you left off."
19:00:15 UTC  first request: cache_creation (1h) 260,214 tokens, cache_read 0
19:00:21 UTC  the thread reports nothing pending and stops

Screenshots, recordings, or supporting files

No response

Workaround

Turning off auto-resume after usage limits prevents it, but that is one global setting, so it also stops threads that were in the middle of real work. We avoid it by pacing usage so the 5-hour limit is not reached.