compaction.auto: false is ignored when provider throws a context overflow error

Description

Setting compaction: { "auto": false } prevents proactive compaction (the token threshold check), but compaction still runs when the provider returns a hard context overflow error. The auto: false flag is completely ignored in this path.

The catch block for ContextOverflowError in processor.ts bypasses isOverflow() entirely and schedules compaction unconditionally. Once scheduled, the compaction task marker is written into the session message stream and SessionCompaction.process() runs on every subsequent loop iteration regardless of config.
The practical consequence: when a session hits the context limit, stopping and switching to a model with a higher token limit has no effect. The session remains stuck in the compaction task. The only escape is starting a new session entirely or manually changing the session json and removing the error entirely.

Reverting the last message is not an option as the agent would lose track of file edits already made in the session

Plugins

None

OpenCode version

1.2.24

Steps to reproduce

Set compaction: { "auto": false } in opencode.json
Run a session until the provider returns a context overflow error (this triggers the auto compaction task)
(optional)
Stop the session and switch to a model with a higher context limit
Resume - the session is stuck in the compaction task

Screenshot and/or share link

No response

Operating System

Windows 11 Enterprise

Terminal

Windows Terminal

this looks like a clear config-consistency bug in the overflow path.

suggested fix:

in the ContextOverflowError catch path, apply the same compaction.auto gate used by proactive overflow checks (isOverflow() path)
if compaction.auto === false, do not enqueue a compaction task marker; surface a recoverable error instead
on resume / model-switch, clear any stale queued compaction marker when auto compaction is disabled (or when current model context no longer overflows)

right now the session can get trapped in a compaction loop, and switching to a higher-context model doesn’t recover because the queued task keeps re-running.

expected behavior: auto:false should consistently mean no automatic compaction, regardless of whether overflow is predicted proactively or returned by provider error.

Found the PR where the auto flag was overlooked:

Commit: be20f86
Issue: Request entity too large error #6574 (linked from PR)
PR: fix: recover from 413 Request Entity Too Large via auto-compaction #14707

packages/opencode/src/session/processor.ts, lines 356-364 in the diff:
// Before (fell through to error → stop):
if (MessageV2.ContextOverflowError.isInstance(error)) {
  // TODO: Handle context overflow error
}
// After (forces compaction, skips error path):
if (MessageV2.ContextOverflowError.isInstance(error)) {
  needsCompaction = true          // line 360
  Bus.publish(Session.Event.Error, {
    sessionID: input.sessionID,
    error,
  })
} else {
The else on line 365 is the bug — overflow no longer reaches input.assistantMessage.error = error (line 379), so the session never stops.

Proposed Design:

When auto: false: treat ContextOverflowError as a normal error → set assistantMessage.error → return "stop". No compaction marker is written. Session stops cleanly. User can resume the same session with a bigger model.

When auto: true (default): keep current behavior — needsCompaction = true → compacts and recovers. PR #14707's fix stays intact for the majority of users.

Opened PR #17936 with a fix for this. The change adds a compaction.auto === false gate to the ContextOverflowError catch block in processor.ts so the session stops cleanly instead of being forced into compaction.

The PR is taking a long time to be merged. Perhaps you could configure the model as follows:

"limit": {
"context": 1000000000,
"input": 1000000000,
"output": 1000000,
}

I was looking into the recent compaction-loop reports, and this issue seems like the best place to keep the related context together.

From tracing the current code and the related PRs, it looks like there are a few separate pieces involved:

fix(core): honor compaction.auto on provider overflow #17936 seems to have addressed the compaction.auto === false path for ContextOverflowError, but it was closed without merge and is now stale.
fix(session): break infinite compaction loop #27919 adds an attempt counter to stop repeated compaction.
fix(session): stop stalled auto-compaction #28139 and fix(opencode): break auto-compact loop when compaction makes no progress #29150 try to detect stalled compaction.
fix(opencode): bound compaction request payload #29860 limits the compaction request payload.
fix(opencode): finish errored compaction summaries #30836 handles errored summary messages more explicitly.

So far, none of these seem to have landed as a complete fix, and they appear to cover different parts of the same failure mode rather than being exact duplicates.

Would it make sense to consolidate the useful parts into a single PR against the current dev branch? I'd be happy to put one together if that would be useful.

I was looking into the recent compaction-loop reports, and this issue seems like the best place to keep the related context together.

From tracing the current code and the related PRs, it looks like there are a few separate pieces involved:

fix(core): honor compaction.auto on provider overflow #17936 seems to have addressed the compaction.auto === false path for ContextOverflowError, but it was closed without merge and is now stale.

fix(session): break infinite compaction loop #27919 adds an attempt counter to stop repeated compaction.

fix(session): stop stalled auto-compaction #28139 and fix(opencode): break auto-compact loop when compaction makes no progress #29150 try to detect stalled compaction.

fix(opencode): bound compaction request payload #29860 limits the compaction request payload.

fix(opencode): finish errored compaction summaries #30836 handles errored summary messages more explicitly.

So far, none of these seem to have landed as a complete fix, and they appear to cover different parts of the same failure mode rather than being exact duplicates.

Would it make sense to consolidate the useful parts into a single PR against the current dev branch? I'd be happy to put one together if that would be useful.

#30749

Nexxeln already made yesterday a merge, his merge is related to the problem we had, so this issue can be closed

Thanks for clarifying — that makes sense for the specific scope of this issue.

For the compaction.auto: false path reported here, #30749 does look like the relevant fix.

I was separating that from the remaining auto-enabled loop case, where auto-compaction is allowed but keeps running because compaction does not reduce tokens enough. That seems better tracked by #28543 / #30680 and the stalled-compaction approach in #29150.

So for this issue's original auto: false case, #30749 seems to cover it.

Navigation Menu

Repository navigation

compaction.auto: false is ignored when provider throws a context overflow error #16882

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Proposed Design:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

compaction.auto: false is ignored when provider throws a context overflow error #16882

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

MaheshBhushan commented on Mar 10, 2026

timwkosatec commented on Mar 10, 2026

timwkosatec commented on Mar 10, 2026

Proposed Design:

timwkosatec commented on Mar 18, 2026

one-pyy commented on Apr 25, 2026

danielxxomg commented on Jun 5, 2026

timwkosatec commented on Jun 5, 2026

danielxxomg commented on Jun 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions