Repository navigation
Auto-compaction loops forever when the system prompt and tools exceed the usable context #54993
Description
Description
When the fixed part of every request (system prompt plus tool definitions) is larger than the model's usable window, every turn overflows, compaction cannot shrink it, and the auto-continue message starts another turn that overflows again. The loop runs until the provider rejects the requests. I hit 261 build/compaction pairs in one session (about $20 of provider credit plus a weekly OpenAI limit used up by the compaction model).
A second problem makes it worse: a compaction request that was interrupted or failed never finishes, so MessageV2.latest keeps it as a pending task. It then runs ahead of every later prompt on the compaction model, even after switching models, so one exhausted compaction model blocks the whole session.
Also, an absolute compaction.reserved tuned for a large model (for example 100000) leaves only 50000 usable tokens on a 150000-token model.
Plugins
None involved.
OpenCode version
dev
Steps to reproduce
- Use a model with a 150000-token context and set
compaction.reservedto 100000 (or have a tool list larger than the window). - Send any prompt.
- The session alternates between a build turn and a compaction until the provider stops answering.
Operating System
macOS
Terminal
Ghostty
Activity
opencode-agent commentedon Oct 13, 2026
Thanks for the detailed report, and sorry about the credits this cost you.
I think this was hit on OpenCode v1, not v2.
MessageV2.latest, the auto-continue turn after compaction andcompaction.reservedall come from the v1 code. Thedevbranch was v1 until v2 was promoted to it on 2026-10-10, and your PR #54994 changes files underpackages/opencodethat are not on the currentdev. v1 only gets fixes for critical bugs (data loss, security problems, or breakage with no workaround), so this is unlikely to be fixed there. Loweringcompaction.reserved, turning off auto-compaction, or using fewer tools/MCP servers avoids the loop.Please try v2 (
opencode upgrade --major, notes: https://anoma.ly/notes/opencode-2-0). Its compaction is a separate implementation: it does not auto-compact again right after a compaction completes, andcompaction.reservedis only read as an alias forcompaction.buffer. I haven't tested your scenario on v2, though.Related issues, most closely related first:
If you can reproduce this on 2.x, or think it is critical on v1, please reply here with your
opencode --versionand the model you used.opencode-agent commentedon Oct 14, 2026
Closing this as not planned, since there has been no reply. What you described (
MessageV2.latest, the auto-continue turn after compaction,compaction.reserved) is v1 code, and v1 only gets fixes for critical bugs. Until then, loweringcompaction.reserved, turning off auto-compaction, or using fewer tools/MCP servers avoids the loop.v2 (
opencode upgrade --major) has a separate compaction implementation. If you can reproduce the loop or the stale compaction on 2.x, please reopen this issue or open a new one with youropencode --versionand the model you used. #50474 is the open v2 report of a related compaction loop, if that turns out to match.