Protected-message exemption inflates the incompressible context floor: per-compression reasoning is never reclaimable (~83.5% of measured residual)

[LightX001]

Summary

After repeated compression of a long session, 146 messages (~1.1 MB) remained that no compression block had ever covered. The largest component is reasoning parts (50.9%), and 83.5% of that reasoning is co-resident with compress tool parts. The proximate cause is that filterProtectedToolMessages excludes messages from compression selection at message granularity while compress is force-protected: the thinking emitted by each compression operation is thereby excluded from all future compression and re-sent with every request. The non-reclaimable context floor consequently grows monotonically with the number of compressions performed.

Environment

• opencode-acp 1.14.27. All code-level statements below were verified against both the shipped dist/index.js and the TypeScript recovered from its embedded sourcemap (75/75 lib/*.ts files byte-identical).
• Observed session: ~1M-token context limit, 4,846 messages, 227 blocks created across the session's lifetime.

Method

Read-only forensics over opencode.db (SQLite, mode=ro) joined against the plugin registry (storage/plugin/acp/ses_*.json). A message is classified as uncovered if it appears in no block's effectiveMessageIds and has no covering entry in prune.messages.byMessageId. Part size is length(data) in bytes.

Measurements

Residual after the final compression (146 uncovered messages, 1,105,625 B):

component	bytes	share
reasoning parts	563,171	50.9%
compress tool parts (summaries in state.input.content, force-protected)	153,939	13.9%
skill parts	121,542	11.0%
remaining (other tools, text, step parts)	~266,000	~24%

Attribution of the 563,171 B of reasoning by co-resident tool part:

• 95.0% (534,833 B) resides in messages containing at least one protected tool part
• 83.5% (446,479 B) specifically in messages containing a compress part; session-wide, 120 compress-carrying messages hold 1,130,202 B of reasoning (mean 9,418 B, max 28,067 B per message)
• 0% attributable to the recent-tail window (no uncovered post-last-compression messages without protected parts) — the residual is structural, not ordinary recent context

Mechanism

1. filterProtectedToolMessages removes whole messages from every compression selection (lib/compress/protected-content.ts:188-234; removedMessageIds.add(messageId) — no part-level handling). A message's reasoning is therefore exempted together with its protected tool part.
2. compress and skill are the defaults for compress.protectedTools (config.ts:158/245), and compress is force-appended regardless of user configuration (config.ts:167/476).
3. Exempted messages never enter byMessageId, so the pruning survival rule (lib/messages/prune.ts:60-89) never removes them, and they are included in every outgoing request while the message is in the array.
4. Retention of the compress message itself is defensible: the live summary reaches the model only through that message (range.ts:378; wrapCompressedSummary, compress/state.ts:55). The reasoning part in the same message is not covered by that constraint — it never re-enters any selection (excluded prior to selection), and neither tier distillation nor decompress reads it (those operate on the registry and DB).

Scope limitation

The figures above are DB-level totals accumulated over the session's entire lifetime, and bound the per-request residue from above; they do not represent the size of any single outgoing request, which was substantially smaller once consumed blocks were pruned and spliced. When a block is consumed by a higher tier, hideConsumedCompressCalls drops the compress part, and messages left with only structural parts are spliced (compress/parts.ts:1-5 classifies reasoning as structural). Two subclasses have no such reclaim path: (a) the live-block window — every compression round adds an exempt message that persists until T2/T3 consumption; (b) skill-carrying messages — hideConsumedCompressCalls handles only compress parts. Exact per-request decomposition would require simulating the full pipeline and was not performed.

Related findings

1. The displayed residual is estimated over text+tool only (estimateContextComposition, inject/utils.ts:623-666, total at :703; length/4 heuristic) and excludes reasoning; lastPerMessageNudgeTokens is a lagging snapshot. The reported percentage therefore omits the largest measured residual component.
2. byMessageId entries whose activeBlockIds drain to empty remain permanently visible: prune.ts:62 treats "entry present, no active blocks" as survive. Observed on 8 messages / 28,338 B.
3. rewriteCompressInput bails out conservatively when all batch siblings are consumed (hide-consumed.ts:42, kept.length === 0 → return null), leaving unmatched batch summaries in the request (~3.7 KB/block in this session).

Possible mitigation

Strip reasoning parts at request time for messages that survive solely via the protected-message exemption, excluding the last unclosed assistant turn. Providers mandate replaying thinking blocks only for the current unresolved tool round (Anthropic thinking-signature validation; Gemini thought_signature on tool calls), so gating on turn-closure state rather than provider identity covers all providers. No persistent writes required.

[LightX001]

Withdrawn at author's request — no further action needed from maintainers.

[ranxianglei]

ework 接单

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 Triage complete — all core mechanism claims verified against source (checked out v1.14.26; line numbers match your report within a hash).

Verification (confirmed in code, not just taken on faith)

• Message-granular protection — filterProtectedToolMessages (lib/compress/protected-content.ts:188-234) does removedMessageIds.add(messageId) at :202. The whole message — reasoning parts included — is excluded from every compression selection. ✓
• compress/skill are force-protected — FORCE_COMPRESS_PROTECTED = ["compress"] (lib/config.ts:167, force-appended at :476); default COMPRESS_DEFAULT_PROTECTED_TOOLS = ["skill", "compress"] (:158). Users genuinely cannot opt out of the biggest offender. ✓
• Excluded messages are never pruned — lib/messages/prune.ts:60-66: survive[i] = true when a message has no byMessageId entry (or empty activeBlockIds). So the protected message is re-sent every turn, reasoning riding along. ✓
• Summary lives only in the surviving compress-call message — wrapCompressedSummary (lib/compress/state.ts:55-63); hideConsumedCompressCalls (lib/compress/hide-consumed.ts:62) is what removes it after consumption. Dropping the whole message would kill the live summary; the safe lever really is the reasoning part only. ✓
• Proposed insertion point exists and is correct — transform runs prune (hooks.ts:256) → truncateLargeToolOutputs (:257) → hideConsumedCompressCalls (:258). Your "after truncate, before hide" slot is valid. ✓

I can't independently reproduce your session numbers (83%, ~9 KB/round) — those come from your forensic audit of opencode.db. But the mechanism that produces that monotonic floor is fully confirmed in code: each compress call's own reasoning rides on a force-protected, never-pruned message, so the floor grows with every round.

Assessment

The proposal is sound, minimal, and correctly scoped. The narrow exemption predicate (only messages that exist solely due to the message-level protected exemption; never touching user-visible text) is the right call. Provider-gating for Anthropic (thinking-block signature validation) is necessary and correctly identified. Prefix-cache impact is acceptable: the pass is deterministic → stable after first apply; the only invalidation events coincide with block consumption / tail-shift, which already perturb those same messages.

One refinement worth deciding up front: placing the pass after getCurrentTokenUsage's pre-prune snapshot (i.e., in your proposed slot) reduces real sent cost but leaves nudge cadence keying off the pre-strip count. Non-blocking — I'd take the simpler placement unless you want recovered tokens to feed nudge timing.

Recommendation (clear, per feature-triage policy)

1. One focused PR for the main feature: stripExemptReasoning pass + config flags (stripExemptReasoning default on, internally provider-gated; stripExemptReasoningKeepRecent default 2). Rationale for default-on: it only removes ephemeral private reasoning from messages already permanently retained for other reasons — zero loss of user-visible or compression-critical data. If you'd rather match the qualityGate precedent (ship off, burn in one release), that's a one-line default flip — your call.
   • Tests per §5.7 (multi-turn, side-effect assertions, preserveRecentMessages > 0, growth cycle) + Docker E2E per §5.7.2. Dual-agent code + test review before merge.
2. Keep the three secondary findings OUT of that PR — they're independent bugs. I'll file them as separate issues with source markers:
   • A — display/acp_status estimator excludes reasoning entirely. estimateContextComposition (lib/messages/inject/utils.ts:586+) counts only text+tool parts (no reasoning branch), while real usage includes it (lib/token-utils.ts:19,44: input+cacheRead+cacheWrite+output+reasoning). → shown % undercounts actual, and hides the single largest residual component.
   • B — orphaned byMessageId entries stay visible forever. Once a block deactivates and activeBlockIds drains to empty, prune.ts:60-66 treats "entry exists but no active blocks" as survive → the covered messages reappear. Needs root-cause in the sync/deactivation path (your 8-msg / 28 KB sample).
   • C — rewriteCompressInput leaks on full consumption. lib/compress/hide-consumed.ts:42: kept.length === 0 → return null leaves the part intact, so batch summaries whose blocks are all consumed still leak (~3.7 KB/block in your measurement).

Two things before I cut the branch (owner call)

1. Floor 1 shows the OP withdrew ("no further action needed from maintainers"). You've since assigned this to ework — confirming you want me to proceed despite the withdrawal?
2. Scope OK as above — main feature = 1 PR, secondaries = 3 separate issues?

Say the word and I'll create the branch, write the devlog REQ, and start implementation. Optional: happy to fold your read-only audit script in as the test fixture — send it over if you want it included.

[LightX001]

Body updated — responses to the triage

The issue body was revised before this triage ran. The current version was substituted (and the issue reopened) at 2026-09-07T09:46:32Z, roughly two hours before the triage comment. The triage quotes constructs that exist only in the original version and are absent from the current body: the stripExemptReasoning name, the provider-gated design, stripExemptReasoningKeepRecent = 2, the "after truncate, before hide" insertion slot, and the 446–534 KB recovery estimate. The five verifications were run against the original body and remain meaningful for the mechanism claims, but any recommendation keyed on the original proposal should be re-read against the current text. Separately, an independent source-level audit of ours (line-by-line against the 1.14.27 sources) confirmed the direction as the only minimal fix covering both residual classes without persistent writes, and produced a buildable patch spec; three of its findings materially changed the proposal — they are the three substantive deltas below:

1. The gate axis is turn-closure, not provider identity. Providers mandate replaying thinking blocks only for the current unresolved tool round (Anthropic signature validation; Gemini thought_signature on tool calls). Reasoning from already-closed historical assistant turns is replayable-strippable for all providers. So the mitigation is not "exempt Anthropic-family providers" (which would forfeit the largest single contributor precisely on the highest-thinking-volume models) but "exempt the last unclosed assistant turn". The numeric KeepRecent = 2 in the original version is superseded by this semantic exemption.
2. The measurements are scoped to DB-level session-lifetime totals. They bound the per-request residue from above; they are not the size of any single request. Messages whose blocks have been consumed by a higher tier are reclaimed via hideConsumedCompressCalls (reasoning counts as structural in compress/parts.ts, so reasoning-only leftovers are spliced). What has no reclaim path: the live-block window, and skill-carrying messages. The growth claim — each compression adds one permanently exempt message carrying mean 9,418 B of reasoning — remains code-verifiable end to end.
3. Naming and placement refinements. I deliberately left the pass unnamed in the revised body: stripExemptReasoning collides with the existing lib/messages/reasoning-strip.ts (stripStaleMetadata). On insertion point, I would now prefer running the pass after hideConsumedCompressCalls rather than before it, so it never processes messages about to be spliced and operates on a minimal working set.

On the defaults: fine to make the pass default-on provided a kill-switch flag ships with it; the qualityGate burn-in precedent is equally acceptable. On the noted refinement — yes, nudge cadence keyed off the pre-strip count is accepted as non-blocking for a first iteration.

On the audit script: declined; the reproduction path described in Method is sufficient.

Answers to the two owner questions:

1. Confirmed — please proceed. The reopen with the current body is the intended state of this issue.
2. Scope accepted: one PR for the main feature; findings A/B/C as separate issues with source markers.

[ranxianglei]

简述这个什么问题

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

简述 —— 这个问题是什么

一句话：长会话中，模型每次调用 compress/skill 时产生的"思考内容"（reasoning/thinking）会永久滞留在上下文里，任何压缩都回收不掉，形成一块只增不减的"地板"。

为什么回收不掉（已逐条在源码核实，v1.14.x）：

• compress/skill 是受保护工具，携带它们的整条消息被排除在所有压缩选择之外（lib/compress/protected-content.ts:202，按整条消息粒度剔除，reasoning 一并被排除）。
• 这些消息不进压缩索引 → 每轮都原样重发给模型，reasoning 跟着一起（lib/messages/prune.ts:60-66）。
• 净效果：每压一轮就新增一条带 ~9KB reasoning 的不可回收消息，压得越多地板越高（实测约占残留的 83%）——一个正反馈循环。

修法（按作者修订后的方案，我已重新核对源码）：每次请求发出前，把这类"仅因受保护而保留"的历史消息上的 reasoning 剥掉；当前这一轮（可能还在等工具结果）不动。只改请求数组、不写库、不碰用户可见文本。判据用"轮次闭合"而非按 provider 一刀切，默认开启并带 kill-switch。

进度：机制已核实，作者已确认放行。我接下来按此实现（feature 分支 + devlog + 代码 + §5.7 测试 + 双 agent 评审 → PR）；三个次要发现（显示估算漏算 reasoning / 孤儿 byMessageId / rewriteCompressInput 泄漏）将另开 issue。

[ranxianglei]

每次请求发出前，把这类"仅因受保护而保留"的历史消息上的 reasoning 剥掉；

这里有个问题,就是可能导致缓存命中大跌.

但是有一些上游,比如gpt的,要求思考完整才可以.

需要想更好的办法

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

两个顾虑都成立，我先给结论再给依据——建议改成「provider 白名单 + 轮次闭合门控 + kill-switch」，请你拍板两点后我继续（分支已建好，未写代码）。

① 缓存命中——我的分析是「有界」，不是持续大跌：

• strip 的判定集合 = 「最后一条真实 user 消息之前的、受保护豁免的历史消息」。这个边界用 getLastUserMessage（lib/messages/query.ts:10，与现有 stripStaleMetadata 同一机制）定位，同一轮内不变。
• 因此同一轮里多次请求发出的前缀逐字节一致 → 缓存正常命中，不会因为"每轮都 strip"而反复失效。
• 只有新 user 消息到来时边界前移：仅「上一轮」那段（约一轮消息量）从"保留 reasoning"变"剥掉"→ 前缀在该点分叉。4.8k 消息的会话里，这一小段占比极小，且新 user 消息本身也会让其后内容失效。
• 唯一的大头是一次性：首次启用/升级那一刻，整段历史被重新 strip → 一次较大失效，之后稳定，可被后续省下的 floor 摊薄。
• 所以代价 = 「一次重建 + 每轮小额」，不是持续性的缓存塌陷。若你认为连这次重建都不可接受，见下面③的替代路径。

② GPT 要求思考完整——同意，按 provider 门控：

• 我无法在此环境独立验证各家 API 的 reasoning 回放规则，所以以你的一线经验为准（GPT 需完整 → 排除）。
• 设计上加一层 provider 白名单：只对"确认 closed-turn reasoning 可剥"的 provider 生效，默认 ["anthropic","gemini"]（审计确认的那两家），排除 GPT/OpenAI；未知/新 provider 默认不剥 → 不会误伤。完全可配置，另有总开关 stripProtectedReasoning 一键全关。
• 叠加轮次闭合门控：当前这一轮（可能还在等工具结果）永远不剥。两层门控取交集，最保守。

③ 为什么请求时 strip 仍是 ACP 约束下的最优（回应"更好的办法"）：

• ACP 是请求变换插件，只能改"每次发送的数组"，改不了 opencode 落库的消息，也不能改压缩选择语义。所以"从源头不累积 reasoning"对 ACP 不可达。
• 唯一"零请求时 strip"的替代 = part 粒度保护重做（把 reasoning 部分纳入正常压缩、仅 tool 部分保留），改动大、LightX001 已判非最小，建议另立 issue，不塞进这个 PR。

请你拍板：

1. provider 策略用 白名单（默认 anthropic+gemini、排除 GPT） 还是黑名单（默认剥、仅 GPT 类不剥）？我推荐白名单（安全默认，未知 provider 不误伤）。
2. ①的「一次重建 + 每轮小额」缓存代价是否可接受？

你定了我就按此实现。

[ranxianglei]

是否可以在思考特别大的时候,移除完整的思考呢?然后只留下一个工具调用?但是思考特别小的时候,就不处理?

[LightX001]

可不可以在整个窗口对话轮次数特别大的时候，对古早的已经没什么价值的内容进行压缩

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

可以，这个思路更好——按"思考大小"设阈值：大的剥、小的不动。我认同，理由：

• 收益几乎不掉：地板由"大 reasoning"主导（实测均值 9.4KB、最大 28KB/条）。只剥超阈值的，就拿走绝大部分 floor。
• 缓存更稳：小 reasoning 的消息完全不动 → 这些消息的前缀零改动；而且"长度是否 > 阈值"对每条消息是稳定不变的判定，不随轮次抖动。
• 更精准：不为几十字节的 reasoning 付出前缀失效的代价。

先对齐选择器（这点想跟你确认）：目标应是带 compress/skill 工具调用、且从未被压缩的受保护消息——因为只有它们的 reasoning 是"地板"（普通历史消息的 reasoning 早被压缩回收了，不在 floor 里）。所以规则 = 历史轮 + 带受保护工具调用 + reasoning 超阈值 → 剥掉 reasoning、保留工具调用。不是"所有大 reasoning 消息"（那会误伤正常消息、扩大失效面）。

阈值：做成可配置，我建议默认 ~2KB（按该消息 reasoning 内容的字符/字节长度）。你定具体值和单位（字符 vs token）。

和 provider 门控的关系：尺寸阈值解决的是"缓存/性价比"，不解决 GPT"要求思考完整"那条——GPT 仍需按 provider 排除（与大小无关）。所以最终三层叠加：历史轮（当前轮不动）+ 尺寸阈值 + provider 白名单（默认 anthropic+gemini，排除 GPT）。

请你拍板：

1. 选择器 = 带受保护工具调用（compress/skill）的消息（而非所有大 reasoning 消息）——对吗？
2. 阈值默认值 + 单位？
3. provider 白名单默认 {anthropic, gemini}、排除 GPT —— 沿用上一条推荐，OK？

定了我就按此实现（分支 + devlog 已就绪）。

[ranxianglei]

provider 先不管 有问题再说,阈值按照你的推荐,
另外向https://github.com/ranxianglei/billion-context
https://github.com/ranxianglei/billion-context-pi
提交相同issue
开工吧.