Background compaction: hardcoded 64k floor makes it unreachable on smaller context windows #58818

Version: opencode v2.1.4 (source tag v2.1.4)

Summary

experimental.background_compaction can only ever start a background summary when the
measured prompt of the latest response is at least PRECOMPUTE_MIN_TOKENS = 64_000, and
the summary is only started while the context is still below the compaction ceiling
(ceiling = limit.input - buffer). That makes the feature unreachable whenever the
ceiling is at or below 64k, regardless of how much memory the provider actually has.
The 64k value is a fixed constant, not a configuration key, so users with a smaller
window cannot enable the feature without patching the source.

Where

packages/core/src/session/compaction.ts

• line 147: const PRECOMPUTE_RATIO = 0.85
• line 149: const PRECOMPUTE_MIN_TOKENS = 64_000
• line 337: if (estimateContext(context) < ceiling * PRECOMPUTE_RATIO) return
• line 342: if (anchor.tokens.input + anchor.tokens.cache.read + anchor.tokens.cache.write < PRECOMPUTE_MIN_TOKENS) return

The only settings exposed to the config plugin are precompute (the boolean),
auto, buffer and keep.tokens (packages/core/src/config/plugin/compaction.ts).
Neither the floor nor the ratio can be set from config or from a plugin.

Why it fails for a small window

The conditions are:

1. measured prompt >= 64_000, and
2. estimate < ceiling (otherwise compaction is already due).

Since the estimate is never below the measured prompt, both can only hold if
ceiling > 64_000. With limit.input = 53_544 and buffer = 6_000 (ceiling 47_544),
the window is empty: compaction always fires before the prompt reaches 64k, so
precompute returns at line 342 every time. The feature is silently inert.

Reproduction: any local OpenAI-compatible server whose effective prompt budget is below
~70k (for example a 76k KV pool with limit.input set to match), with
"experimental": { "background_compaction": true }. Inspect the session: no background
summary is ever started. opencode debug config shows the flag is accepted.

Verified

Tested against a mock OpenAI-compatible server that reports a fixed usage.prompt_tokens,
with opencode run --standalone in an isolated HOME, limit: { context: 67312, input: 53544, output: 11474 }, compaction.buffer = 6000 (ceiling 47_544) and a reported prompt of 44_000:

build	background summary requests
stock v2.1.4	0
same source with PRECOMPUTE_MIN_TOKENS = 40_000	2

With larger limits (input 80_000, prompt 70_000) stock v2.1.4 does send the summary request,
so the path itself works; only the fixed floor keeps it from running on smaller windows.

It also cannot be worked around by patching the released binary: the CLI is compiled with
bytecode: true, so the executable runs the cached bytecode and ignores the embedded JS. A copy
of the stock exe with the constant in the embedded source changed to 99_999 still sent the summary
request. Changing it requires building from source (with bytecode: false), which is a lot to ask
of someone who only wants a different threshold, and is why a config option would help.

Why the constant is the wrong shape

The 64k floor encodes "a summary is only worth doing in the background above this
prompt size", a measurement from one setup. The right threshold depends on the provider's
budget (the window), which opencode already knows as limit.input/limit.context, and
the measured cost of prefill on the user's hardware. A fixed number ignores both.

Proposal

Either of these would fix it:

1. Make the floor configurable, e.g. experimental.background_compaction accepts
   { "min_tokens": <n> } (or a sibling key), defaulting to 64_000 so nothing changes
   for current users.
2. Derive the floor from the window instead of a constant, e.g. a fixed share of the
   ceiling (so the feature engages on any window large enough for the 0.85 ratio to be
   meaningful).

Either way, the feature should not be silently inert: if the ceiling is below the floor,
a single log line (or a config validation warning) saying so would make the cause
obvious.