Description
compaction.auto: false does not fully disable automatic compaction. It prevents the proactive token-threshold path, but OpenCode still enqueues and runs automatic compaction from the provider/processor compact recovery path.
This is still reproducible on OpenCode 1.15.13.
Related existing issue: #16882. Filing this separately because the behavior is still present in current 1.15.x, and this reproduction adds a more specific failure mode: automatic overflow compaction can happen at only ~20-30% displayed context usage after manual compaction, and can trigger repeatedly.
Current config
opencode debug config resolves the config as:
"compaction": {
"auto": false,
"reserved": 5000
}
No project-level .opencode/opencode.json(c) exists in the session directory.
Observed behavior
A long local session had already been manually compacted, then later automatically compacted twice in a row even though compaction.auto was disabled.
Compaction marker evidence from the part table:
manual compaction:
2026-06-03 15:06:49 {"type":"compaction","auto":false,"tail_start_id":"msg_<redacted>"}
2026-06-04 09:51:04 {"type":"compaction","auto":false,"tail_start_id":"msg_<redacted>"}
automatic compaction after that:
2026-06-04 11:09:41 {"type":"compaction","auto":true,"overflow":true,"tail_start_id":"msg_<redacted>"}
2026-06-04 11:10:56 {"type":"compaction","auto":true,"overflow":true,"tail_start_id":"msg_<redacted>"}
The important part: the first automatic compaction was not triggered near a full context window.
The resolved custom model limit for github-copilot/gpt-5.5 was:
{
"context": 568000,
"input": 386240,
"output": 128000
}
The last successful assistant request before the first automatic compaction had:
input: 128,051
output: 240
cache_read: 25,600
total: 154,038
That is only:
154,038 / 568,000 = 27.1% of context
154,038 / 386,240 = 39.9% of input limit
The second automatic compaction happened immediately after the first one. The compaction summary request itself had only:
input: 13,761
output: 4,767
cache_read: 3,584
total: 22,365
That is only:
22,365 / 568,000 = 3.9% of context
So this is not normal proactive context-threshold compaction.
Most likely trigger
Right before the first automatic compaction, the assistant had read several image files. The tool outputs were small textual outputs, but each tool part contained one attachment. One attachment JSON payload was about 1.78 MB:
read image attachment: ~104 KB
read image attachment: ~103 KB
read image attachment: ~104 KB
read image attachment: ~1.78 MB
This suggests the provider/processor returned compact because of request payload/media/attachment overflow, not because text token context was near the configured model context limit.
That is fine as an error condition, but compaction.auto:false should still prevent OpenCode from automatically compacting the session.
Source code observation
The proactive overflow path correctly respects compaction.auto === false via SessionCompaction.isOverflow() / overflow.ts:
if (input.cfg.compaction?.auto === false) return false
But the provider overflow/processor result path in packages/opencode/src/session/prompt.ts appears to enqueue compaction unconditionally:
if (result === "compact") {
yield* compaction.create({
sessionID,
agent: lastUser.agent,
model: lastUser.model,
auto: true,
overflow: !handle.message.finish,
})
}
Because auto: true is hardcoded there, compaction.auto: false is bypassed for provider/context/media overflow recovery.
Expected behavior
If compaction.auto === false, OpenCode should not enqueue an automatic compaction task in any automatic path, including provider/context/media overflow recovery.
Instead it should surface a recoverable overflow error and stop, allowing the user to:
- manually compact if desired
- switch to a larger context model
- fork/start a new session
- remove large attachments/tool outputs manually
Actual behavior
OpenCode creates a compaction marker with auto:true, overflow:true and runs the compaction agent automatically, despite compaction.auto:false.
In this reproduction it happened twice consecutively, and at only ~27% context usage before the first automatic compaction.
OpenCode version
Model/provider
Operating system
Windows
Terminal
Windows Terminal / PowerShell 7
Description
compaction.auto: falsedoes not fully disable automatic compaction. It prevents the proactive token-threshold path, but OpenCode still enqueues and runs automatic compaction from the provider/processorcompactrecovery path.This is still reproducible on OpenCode
1.15.13.Related existing issue: #16882. Filing this separately because the behavior is still present in current 1.15.x, and this reproduction adds a more specific failure mode: automatic overflow compaction can happen at only ~20-30% displayed context usage after manual compaction, and can trigger repeatedly.
Current config
opencode debug configresolves the config as:No project-level
.opencode/opencode.json(c)exists in the session directory.Observed behavior
A long local session had already been manually compacted, then later automatically compacted twice in a row even though
compaction.autowas disabled.Compaction marker evidence from the
parttable:The important part: the first automatic compaction was not triggered near a full context window.
The resolved custom model limit for
github-copilot/gpt-5.5was:{ "context": 568000, "input": 386240, "output": 128000 }The last successful assistant request before the first automatic compaction had:
That is only:
The second automatic compaction happened immediately after the first one. The compaction summary request itself had only:
That is only:
So this is not normal proactive context-threshold compaction.
Most likely trigger
Right before the first automatic compaction, the assistant had read several image files. The tool outputs were small textual outputs, but each tool part contained one attachment. One attachment JSON payload was about 1.78 MB:
This suggests the provider/processor returned
compactbecause of request payload/media/attachment overflow, not because text token context was near the configured model context limit.That is fine as an error condition, but
compaction.auto:falseshould still prevent OpenCode from automatically compacting the session.Source code observation
The proactive overflow path correctly respects
compaction.auto === falseviaSessionCompaction.isOverflow()/overflow.ts:But the provider overflow/processor result path in
packages/opencode/src/session/prompt.tsappears to enqueue compaction unconditionally:Because
auto: trueis hardcoded there,compaction.auto: falseis bypassed for provider/context/media overflow recovery.Expected behavior
If
compaction.auto === false, OpenCode should not enqueue an automatic compaction task in any automatic path, including provider/context/media overflow recovery.Instead it should surface a recoverable overflow error and stop, allowing the user to:
Actual behavior
OpenCode creates a compaction marker with
auto:true, overflow:trueand runs the compaction agent automatically, despitecompaction.auto:false.In this reproduction it happened twice consecutively, and at only ~27% context usage before the first automatic compaction.
OpenCode version
Model/provider
Operating system
Windows
Terminal
Windows Terminal / PowerShell 7