[BUG]: Compaction overflow threshold too low when limit.input is set; compaction LLM overflow causes retry loop

[LifetimeVip]

Description Bug in the compaction overflow detection: isOverflow threshold too low when limit.input is set. overflow.ts:14-19 鈥?when model.limit.input is set, usable() uses limit.input - reserved. reserved is min(COMPACTION_BUFFER, maxOutputTokens) where COMPACTION_BUFFER is 20,000. Since max output tokens are typically 32K-128K, reserved stays at 20K even when the model needs more headroom. Compaction triggers with only 20K of reserve, but the next API call may need 32K+ 鈥?causing an actual overflow despite compaction having fired. Note: the compaction retry loop (compaction LLM overflow 鈫?infinite retry) is already tracked in #27924, #15533, #30443. This issue focuses on the distinct threshold calculation bug that causes compaction to fire too late. Focused follow-on to #30376. Suggested fix: use maxOutputTokens as reserve when limit.input is set, instead of min(20K, maxOutputTokens). ### OpenCode version

main

Steps to reproduce 1. Start a session with a model that has limit.input set (e.g., 128K input limit) 2. Fill context to near the limit 3. Compaction fires with only 20K reserve 4. Next API call overflows because output needs more than 20K headroom

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• bug(session): infinite compaction loop when compression fails to reduce context #27924: infinite compaction loop when compression fails to reduce context — covers the same retry loop scenario described in Bug 2 (compaction LLM overflow causing infinite retries with no progress)
• Auto-compaction infinite loop when assistant ended its turn (finish !== tool-calls) #15533: Auto-compaction infinite loop when assistant ended its turn — another related infinite compaction loop
• Infinite "Session compacted" loop on multiple models (DeepSeek V4, MiMo V2.5, MiniMax M3) #30443: Infinite "Session compacted" loop on multiple models — similar symptom of unrecoverable compaction cycling

Bug 1 (threshold too low when limit.input is set) may be a distinct issue not covered by the above, but please verify before proceeding.

[LifetimeVip]

Real-world evidence (observed in production use):

After context compression triggers during an active session, the AI model consistently exhibited:

1. Loss of awareness of what task was being worked on — reverted to an earlier incorrect understanding
2. Forgetting files it had already read and analyzed — tried to re-read or re-analyze from scratch
3. Confusion about the current state of work — mixed up completed tasks with pending ones
4. Regression from current conversation topic to older, unrelated topics from earlier in the session

This confirms that session state preservation during compression has practical defects beyond the theoretical code paths documented in this issue. The AI model's behavior after compression demonstrates that critical conversation context (task state, file read tracking, current objectives) is lost or corrupted during the compaction process.

This observation was made over multiple compression cycles with different models, consistent with the overflow/retry loop described above.

[LifetimeVip]

Confirmed that Bug 2 (compaction retry loop) is already tracked in #27924, #15533, #30443. Removed from this issue. This issue now scoped to Bug 1 only (threshold calculation error).

[LifetimeVip]

@rekram1-node — now assigned to you. Two issues: (1) compaction overflow threshold is too low when limit.input is set, causing excessive compaction, (2) compaction LLM overflow causes a retry loop. Related to #30806, #30807, #30811 in the compaction family.

[LifetimeVip]

已提交此问题的修复 PR #31891（compaction context loss, prune re-attach, overflow threshold）