[Feature]: Automatic context compaction for OpenCode threads at a configurable fraction of the window

[ImBIOS]

Problem

When I use T3 Code with the OpenCode provider (model: Muse Spark 1.3 Contributor, xhigh effort), quality degrades after the thread reaches ~20% of the model's max context window. OpenCode itself only auto-compacts near the context limit (via compaction.buffer, default 15% headroom / min 16k tokens — i.e. ~85%+), so a thread can sit in the degraded zone for a long time before anything compacts it. The only in-app remedy today is manual /compact (or the Compact chip/meter button), which requires constant monitoring.

Related per-provider precedent: Claude threads have a server-side "compact idle threads" mechanism (IdleCompactionService, useComposerSend → /compact with idleCompaction: "onReturn") plus a per-instance autoCompactWindow setting that is surfaced into tokenUsage.autoCompactThreshold and displayed in the context meter. OpenCode threads have neither:

• packages/provider-opencode/src/server/v2/adapter.ts finishTurn emits tokenUsage with usedTokens + maxTokens but never autoCompactThreshold, and there's no OpenCode-provider setting equivalent to Claude's autoCompactWindow.
• apps/server/src/orchestration-v2/IdleCompaction.ts idleCompactionWindow() returns null for any driver that isn't claudeAgent.
• The OpenCodeSettings schema (packages/provider-opencode/src/settings.ts) has no auto-compact threshold field.

Upstream, OpenCode already tracks near-limit compaction (docs: compaction.auto / buffer / keep.tokens), and there are open upstream requests for earlier/per-model thresholds (anomalyco/opencode#43703 per-model reserved/buffer, #8140 configurable threshold + maxContext, #11314 configurable compaction threshold, #50777 idle-time compaction). None of those give T3 Code a T3-side trigger that compacts an OpenCode thread at a user-chosen fraction of its window to preserve answer quality.

Proposal

Add a T3-side automatic context compaction for OpenCode threads, mirroring the existing Claude machinery:

1. New OpenCode provider-instance setting, e.g. autoCompactThreshold (tokens) or autoCompactRatio (fraction of the model's window, default e.g. 0.2), following the ClaudeSettings.autoCompactWindow pattern (validated range, empty = default/off, surfaced per-instance with General default).
2. Report the effective threshold in the OpenCode adapter's tokenUsage (autoCompactThreshold, like claudeProviderTurnTokenUsage does), so the context meter (ContextWindowMeter + formatContextWindowCompactionMessage) shows it and handoffBudget accounts for it.
3. Extend the server-side trigger so OpenCode threads compact automatically once the reported usage crosses the configured threshold — either by generalizing IdleCompactionService/idleCompactionWindow beyond claudeAgent, or by a before-send/after-turn check in ProviderTurnStartService/RunExecutionService that dispatches /compact the way useComposerSend does for onReturn (server-created, createdBy: "agent", creationSource: "server", so it stays distinguishable from manual compacts).
4. No changes to OpenCode itself: T3 dispatches its existing /compact path (session.compact via compactThread), same as the manual Compact chip.

Scope for a first PR: setting schema + adapter threshold reporting + one server trigger + meter display + focused tests (threshold math, below/above/at-threshold, unknown maxTokens, opt-out). Idle-cache-TTL coupling (Claude's beforeCacheExpires semantics) is explicitly out of scope; this trigger is usage-fraction based, not cache-expiry based.

Open questions

1. Tokens vs fraction? A fraction of the model's window (e.g. 20%) adapts across models; an absolute token count matches Claude's autoCompactWindow. Which does the team prefer (or both, like OpenCode's buffer in tokens)?
2. Trigger point: after-turn background compaction (like IdleCompactionService, pauses nothing) vs before-send pre-compact (like onReturn, user waits)? For a quality-preservation trigger, after-turn seems right so the next prompt starts clean.
3. Should the same threshold also gate the stale-resume Compact chip (shouldOfferResumeCompaction, currently Claude-only) for OpenCode threads?

Related

• T3: [Feature]: Make stale Claude resume-compaction token threshold configurable #19823 (configurable resume-compaction threshold), Make auto-compact-before-send configurable (it compacts long before the context window is full) #20344 (configurable auto-compact-before-send), [Bug]: OpenCode thread permanently wedged by "Insufficient context allowance" after a failed turn; /compact cannot recover it #19875 (OpenCode wedge where /compact can't recover), [Bug]: OpenCode threads via OpenRouter never show context-window usage in the composer #8388 (OpenCode usage not shown for some models), [Bug]: OpenCode run on oversized session fails with opaque provider.invalid-request, orphaned opencode serve #20142 (oversized OpenCode session fails), [Bug]: OpenCode 2.1.2 rollback fails decoding compaction history: missing recent field #22656 (compaction history decode), PR feat(claude): add opt-in compaction suggestions #22462 (opt-in compaction suggestions).
• Upstream OpenCode: [FEATURE]: per-model compaction threshold (reserved/buffer) anomalyco/opencode#43703 (per-model compaction threshold), [Bug]: Android: Pressing enter in terminal with physical keyboard selects entire terminal #8140 (configurable threshold + maxContext), fix(web): offer recovery from missing pages #11314 (configurable threshold), #50777 (idle-time compaction), docs https://opencode.ai/v2/docs/compaction/ (compaction.buffer = earlier auto-compact in tokens).