[Bug]: Growth nudges ignore minContextLimit and fire below it

[bernhardberger]

Bug description

ACP injects T1 compression nudges well below a configured model-specific minContextLimit.

I am using a 400K-context model with these settings:

{
  "compress": {
    "modelMinLimits": {
      "openai/gpt-5.6-sol": 150000
    },
    "modelMaxLimits": {
      "openai/gpt-5.6-sol": 215000
    },
    "nudgeGrowthTokens": 50000,
    "nudgeForce": "soft"
  }
}

The minimum is 150K, or 37.5% of the model window. During about two hours of normal use, ACP logged ten regular compression nudges. All ten had trigger=growth; none was caused by the 215K maximum. They fired at these context sizes:

67,068
82,172
83,594
86,384
90,162
90,510
102,299
132,826
140,552
152,500

Some representative log entries:

Compression nudge injected | trigger=growth currentTokens=67068 usagePct=16.8% growthSinceBaseline=66852 growthFloor=22500 recommendedRanges=1
Compression nudge injected | trigger=growth currentTokens=90510 usagePct=22.6% growthSinceBaseline=89710 growthFloor=22500 recommendedRanges=1
Compression nudge injected | trigger=growth currentTokens=102299 usagePct=25.6% growthSinceBaseline=60402 growthFloor=22500 recommendedRanges=3
Compression nudge injected | trigger=growth currentTokens=140552 usagePct=35.1% growthSinceBaseline=52564 growthFloor=22500 recommendedRanges=2
Compression nudge injected | trigger=growth currentTokens=152500 usagePct=38.1% growthSinceBaseline=54338 growthFloor=22500 recommendedRanges=2

The model normally follows the nudge and compresses old ranges, so its working context tends to stay around 80K to 150K instead of reaching the configured minimum.

Expected behavior

I expected the limits to work like this:

T1 efficiency nudge = currentTokens >= minContextLimit
                       AND growth >= nudgeGrowthTokens

T1 maximum nudge    = currentTokens >= maxContextLimit

T2/T3 nudge         = accumulated summary threshold

In this configuration, routine T1 compression would start after 150K, with stronger pressure at 215K. T2 and T3 consolidation should remain independent because it is useful even when the current working context is small.

Source findings

The runtime behavior matches the current source:

• computeShouldNudge() uses growthSinceLastNudge >= nudgeGrowthTokens || overMaxLimit.
• overMinLimit selects the message variant but does not gate shouldNudge.
• lib/messages/inject/utils.ts marks minNudgeContextPercent as deprecated and ignored.
• lib/messages/inject/inject.ts passes overMinLimit into the decision but does not require it in nudgeAllowed.

This also means that raising modelMinLimits does not delay growth nudges. Raising nudgeGrowthTokens is not a clean workaround because the same setting controls T2 and T3 promotion.

Issue #300 covers percentage-based nudgeGrowthTokens and the broader decision chain. This report is narrower: a configured lower context limit does not act as a lower limit for T1 growth nudges. The explanation in issue #340 also says nudges require the context to exceed the minimum and pass the growth threshold, which does not match the current runtime behavior.

If bypassing minContextLimit is intentional, a separate T1 growth floor or a separate tier-promotion threshold would make this policy configurable without coupling unrelated behavior.

Environment

• opencode-acp: 1.14.25
• context-compress-algorithms: 1.3.0
• OpenCode: 1.18.23
• Model: openai/gpt-5.6-sol
• Model context window detected by ACP: 400,000 tokens

[ranxianglei]

ework 接单

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

Confirmed — this is a real bug, not intentional. Fixed in PR #343.

Root cause. computeShouldNudge() (external context-compress-algorithms/trigger) only uses overMinLimit to pick the tips variant (normal/minLimit/maxLimit), not to gate the decision:

shouldNudge = growthSinceLastNudge >= nudgeGrowthTokens || overMaxLimit

So a growth nudge fired whenever context grew past nudgeGrowthTokens, regardless of minContextLimit. That's why all ten of your trigger=growth nudges fired at 67K–152K against a 150K minimum. Turn/iteration anchors were already gated on overMinLimit — only the growth path bypassed it, which is also why the README's documented semantics ("below this, reminder nudges are off") didn't match runtime.

Fix (lib/messages/inject/inject.ts, injectCompressNudges): add an explicit min-gate to the T1 growth path:

const nudgeAllowed =
    emergencyOverride ||
    (decision.shouldNudge &&
        (overMaxLimit || overMinLimit) &&   // issue #342: min-gate
        growthSinceBaseline !== undefined &&
        growthSinceBaseline >= growthFloor)

This gives you exactly the policy you described:

• T1 efficiency nudge = currentTokens >= minContextLimit AND growth >= nudgeGrowthTokens
• T1 maximum nudge = currentTokens >= maxContextLimit (bypasses the gate)
• T2/T3 tier-promotion nudges = independent, unchanged (they never consult minContextLimit)

The emergency override (default 98%) still bypasses the gate. overMaxLimit || (rather than just overMinLimit) keeps the max path working even for a misconfigured min > max. The fix lives in ACP, not the shared context-compress-algorithms package, since minContextLimit semantics are ACP-specific policy — no dependency bump.

Tests. 4 new tests in tests/inject.test.ts (suppression below min → fire after crossing; full growth cycle; production config with preserveRecentMessages > 0; over-max bypasses the gate). 2 existing growth-mechanism tests had minContextLimit lowered — they'd set it above the test context to keep it out of the way, which the fix now (correctly) suppresses. Full suite: 1033 tests, 0 failures; typecheck + build clean.

One note: raising nudgeGrowthTokens was the only partial workaround before, and it coupled T1 to T2/T3 cadence — with this fix you no longer need it; modelMinLimits now actually delays T1 growth nudges as documented.

PR: #343

[bernhardberger]

Thanks for confirming and fixing this so quickly. The PR minimum gate matches the behaviour we expected from modelMinLimits.

We temporarily raised nudgeGrowthTokens from 50K to 100K, staged without restarting OpenCode. Once the fix is merged and released on latest, we expect to restore 50K: the 150K model minimum can then control the earliest T1 nudge while 50K retains the intended T2/T3 promotion cadence.

I left one non-blocking review note on PR #343 about the maximum path still being gated by growthFloor, since that can delay a configured max-limit nudge.

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

Glad the min-gate matches what you expected from modelMinLimits.

On restoring nudgeGrowthTokens to 50K once this is on latest: yes, that's exactly the end state this fix enables. With the min-gate in place, the earliest T1 nudge is governed by the 150K minContextLimit (independent of nudgeGrowthTokens), while 50K continues to set the T2/T3 promotion cadence. So restoring 50K gives you "T1 starts after 150K, T2/T3 promote at 50K" — no coupling workaround needed.

On the review note (max path still gated by growthFloor): you're right, and worth being precise about scope:

• It's pre-existing, not introduced by this PR. My diff only added the (overMaxLimit || overMinLimit) min-gate to the growth path. The growthSinceBaseline >= growthFloor cadence gate (and the emergencyOverride bypass) were already there and apply to both the min and max paths.
• It's intentional. growthFloor is an anti-thrashing cadence gate (default max(5000, 0.45 × nudgeGrowthTokens) = 22.5K). By design it's only bypassed at emergencyThresholdPercent (default 98%). The max-limit alert is a soft overflow warning that's cadence-gated to avoid re-nudging every turn; the 98% emergency is the hard one that always fires regardless of growth.

So a configured max-limit nudge can be delayed by up to ~growthFloor past the last nudge baseline. That's the tradeoff the gate makes: without it, once over max the strong "compress now" alert would re-fire every turn until the model compresses — the exact thrashing the gate (and the nudge-loop history in AGENTS.md §5.7) was added to prevent.

I deliberately kept this PR scoped to the reported min-gate bug so it stays a one-line, low-risk change and doesn't touch the anti-thrashing guarantees. Making the max path bypass growthFloor is a separate behavior change that deserves its own analysis + tests.

If you want the max path to fire immediately at maxContextLimit, I can do that in a follow-up — the change is small (split the gate so overMaxLimit skips the growthFloor check), but it does remove the cadence on the max alert. Want me to open a follow-up issue to track it, or leave it as a documented design choice?

[bernhardberger]

Thanks — that distinction between the cadence-gated soft max warning and the unconditional 98% emergency makes sense.

For our intended post-fix configuration, restoring nudgeGrowthTokens to 50K makes growthFloor 22.5K. With the Sol max at 215K, the worst approximate delayed warning is therefore around 237.5K, still about 34.5K below the 272K OpenAI premium boundary. That preserves useful headroom while avoiding repeated max alerts every turn.

No follow-up issue is needed for our use case; leaving this as the documented anti-thrashing design choice is reasonable. We will wait for PR #343 to merge and reach latest, then restore the 50K growth/tier cadence during a controlled restart and verify that T1 growth nudges stay suppressed below the configured 150K minimum.

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

That math checks out: nudgeGrowthTokens=50K → growthFloor = max(5000, 0.45×50K) = 22.5K, so the worst-case max-warning firing point is ~215K + 22.5K ≈ 237.5K, leaving ~34.5K of headroom under the 272K boundary.

Agreed — no follow-up issue; keeping the max path cadence-gated as the documented anti-thrashing choice.

PR #343 is ready for merge (that's the human-only step — I don't merge PRs). Once it's on latest, the cleanest verification is the same log lines you quoted in the issue: after a controlled restart, every Compression nudge injected | trigger=growth entry should show currentTokens ≥ 150000. Any trigger=growth line below 150K after the release would be a regression worth flagging. (trigger=emergency lines are the separate 98% path and can legitimately appear at any size.)

[ranxianglei]

这里有一个严重的问题需要处理,ework你替我转达(因为我英语不好)和确认.
minContextLimit 目前的默认值是80%,原本的含义是在这里开始注入软的压缩提醒,在dcp上,实际上小于minContextLimit也会有压缩提醒,而且每个调用都有压缩提醒.如果把这个字段解释成,压缩保护,那么后果是整个压缩插件不再工作,直到80%上下文的时候.

所以需要寻找是否已经有一个字段了?应该是15%默认保护?那个字段可以控制低于一个阈值不压缩.你进行确认

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

@Dog 你好，你提的问题确认属实，已修正。

• 你说得对：minContextLimit 的默认值是 80%（不是 README 里写的 45%），它原本的含义是"turn/iteration 提醒的软下限"，不是压缩保护阈值。我第一版用它来 gate 增长型压缩提醒，会导致默认用户在 80% 之前完全收不到压缩提醒——相当于压缩插件在 80% 之前不工作。这是个严重问题，谢谢指出。
• 正确的字段是 minNudgeContextPercent（默认 15%），它本来就是"低于这个比例不提醒"的保护阈值，只是之前一直没生效（传给了策略但被忽略）。我已把增长型提醒的下限改成用它。
• 效果：默认用户（15% 下限）整个会话都能正常压缩；想推迟压缩的用户把 minNudgeContextPercent 调高即可（如 400K 模型设 37.5 = 150K 下限）。
• 双 agent 评审期间有另一个 agent 在分支上推了基于 minContextLimit 的改动，我已把我的 15% 下限方案整合进去，并保留了他们修正 README/CONFIGURATION 默认值（45%/55% → 80%/80%）的部分。
• 测试：1035 个全部通过。PR fix: gate T1 growth nudges on minContextLimit (issue #342) #343 已更新。

---

English (for bernhardberger & the record):

Confirmed @Dog's concern — it was valid, and my first fix was wrong.

The problem with the first fix: I initially gated T1 growth nudges on minContextLimit, but that field defaults to 80% (lib/config.ts:200) and is documented as the "soft lower threshold for turn/iteration reminders" — not a compression-protection floor. Gating growth nudges on it would suppress all growth nudges below 80% for default users, effectively disabling compression for most of a session. (A dual-agent review had also pushed a minLimitResolved refinement on the branch, but that only handled unresolvable percent limits — it didn't fix the 80%-default regression.)

The fix: the correct field is minNudgeContextPercent (default 15, a percent of model context) — the intended "don't nudge below this" floor, which was previously a no-op (plumbed into the trigger policy but ignored). Growth nudges now require currentTokens >= minNudgeContextPercent% × modelContext. When the model context limit is unknown the floor is unresolvable and growth nudges keep their pre-#342 behavior. overMaxLimit and the emergency override bypass the floor; T2/T3 tier-promotion nudges are unaffected.

Effect & your config:

• Default users (15% floor): compression works throughout the session, as before.
• To defer compression, set minNudgeContextPercent higher — e.g. 37.5 on your 400K model = a 150K floor. Note it's a global percent (no per-model variant yet), so your modelMinLimits no longer drives the growth floor directly; a per-model modelMinNudgeContextPercent would be a follow-up if you need per-model control.

Integration note: a dual-agent review pushed refinements based on the original minContextLimit approach while I was revising. I integrated the floor approach on top and preserved the review's valuable non-conflicting work (README/CONFIGURATION default corrections 45%/55% → 80%/80%, plus the unresolvable-limit and T2-independence tests, re-pointed at the floor).

Tests: 1035 tests, 0 failures. Typecheck + build clean. PR #343 updated.

[ranxianglei]

ework 帮我看pr中最小讨论和最小方向是否正确,同时帮我转达中英文

[ranxianglei]

继续

[ranxianglei]

（新会话）继续：修复 Growth nudges 忽略 minContextLimit 的问题

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

@Dog 你让我确认的「最小讨论和最小方向」已核查完毕，结论：方向正确、范围最小，PR #343 已就绪。

最小方向（修复方向是否最小且正确）—— 是：

1. 根因确认：computeShouldNudge()（外部 context-compress-algorithms 包）只把 overMinLimit 用来选提示文案变体，从不作为门槛；lib/messages/inject/inject.ts 的 nudgeAllowed 里完全没有上下文大小下限。所以增长型提醒在任何上下文大小下都会触发。
2. 第一版修复（用 minContextLimit 做门槛）是错的，你指出的问题完全属实：minContextLimit 默认值是 80%（lib/config.ts:200），用它做门槛会让默认用户在 80% 之前收不到任何增长型压缩提醒——相当于压缩插件大半会话不工作。
3. 最终方案：改用 minNudgeContextPercent（默认 15%，lib/config.ts:202）——这个字段本来就是「低于此比例不提醒」的保护阈值，只是之前传给了策略但被忽略（no-op）。核心改动只有 inject.ts 里约 15 行：

   const minNudgeFloorTokens =
       modelContextLimit !== undefined
           ? Math.round(((config.compress?.minNudgeContextPercent ?? 15) / 100) * modelContextLimit)
           : undefined
   const overMinNudgeFloor =
       minNudgeFloorTokens === undefined ||
       currentTokens === undefined ||
       currentTokens >= minNudgeFloorTokens
   const nudgeAllowed =
       emergencyOverride ||
       (decision.shouldNudge &&
           (overMaxLimit || overMinNudgeFloor) &&
           growthSinceBaseline !== undefined &&
           growthSinceBaseline >= growthFloor)

4. 为什么说它最小：不改外部依赖包、不改 computeShouldNudge 签名、超 max 和 98% 紧急路径绕过门槛、T2/T3 层级提升提醒完全不受影响、模型上下文窗口未知时门槛不可解析→保持修复前行为（不会误杀）、不碰持久化状态格式。

最小讨论（PR 范围是否聚焦）—— 是：

• 核心修复（inject.ts 门槛）+ 6 个测试（4 个新门槛测试 + 2 个回归锁定）+ 文档修正（README/CONFIGURATION 里过期的默认值 45%/55% → 80%/80%，正是同一组字段，顺带修正合理）。
• PR 上那条非阻塞评审意见（max 路径仍受 growthFloor 节奏门控）已按讨论结论处理：保留为文档化的防抖设计，不另开 issue（与 bernhardberger 达成一致）。
• 本轮新做了一件事：README 配置示例块缩进 9 空格 → 8 空格（0b92dd1，已推送）。

本轮验证：

• npm run test：1035 通过，0 失败；typecheck、build 干净。
• 反向验证（测试必须能抓住 bug）：临时移除门槛行重跑，6 个新测试中 3 个失败（低于门槛被抑制、生产配置、T2 独立性）；恢复后全绿。符合 AGENTS.md §5.7 要求。

@bernhardberger 关于你的配置，一个需要明确的差异：最终方案里驱动 T1 增长提醒下限的是全局 minNudgeContextPercent（百分比），不再是 modelMinLimits。要得到你期望的 150K 下限，在 400K 模型上设 minNudgeContextPercent: 37.5 即可（modelMinLimits 继续作用于 turn/iteration 提醒的软下限，语义不变）。你恢复 nudgeGrowthTokens: 50000 的计划不受影响——T1 最早提醒由 37.5% 下限控制，T2/T3 节奏仍由 50K 控制。

PR: #343 （合并是人工操作，我不合并 PR）

---

English (for the record):

Verified the "minimal discussion + minimal direction" question — the direction is correct and the scope is minimal. PR #343 is ready.

Minimal direction — yes:

1. Root cause confirmed: computeShouldNudge() (external context-compress-algorithms) only uses overMinLimit to pick the tips variant, never as a gate; nudgeAllowed in lib/messages/inject/inject.ts had no context-size floor at all — so growth nudges fired at any context size.
2. The first fix (gating on minContextLimit) was wrong — @Dog's concern was valid: minContextLimit defaults to 80% (lib/config.ts:200), so using it as the growth floor would suppress ALL growth nudges below 80% for default users, effectively disabling compression for most of a session.
3. Final fix: uses minNudgeContextPercent (default 15%, lib/config.ts:202) — the existing "don't nudge below this" protection field, which was previously a no-op (plumbed into the trigger policy but ignored). Core change is ~15 lines in inject.ts (floor computation + one gate clause in nudgeAllowed).
4. Why it's minimal: no dependency bump (fix lives in ACP, not the shared package), no computeShouldNudge signature change, over-max and the 98% emergency path bypass the floor, T2/T3 tier-promotion nudges are untouched, unknown model context → floor unresolvable → pre-fix behavior preserved (no accidental suppression), no persisted-state changes.

Minimal discussion — yes:

• PR scope: core fix + 6 tests (4 new floor tests + 2 regression locks) + doc corrections (stale README/CONFIGURATION defaults 45%/55% → 80%/80%, same field family — justified).
• The non-blocking review note (max path still cadence-gated by growthFloor) was resolved per discussion: kept as the documented anti-thrashing design choice, no follow-up issue.
• This session additionally fixed a README config-block indentation slip (9→8 spaces, 0b92dd1, pushed).

Verification this session:

• npm run test: 1035 pass, 0 fail; typecheck + build clean.
• Negative verification (tests must fail when the bug is present): temporarily removed the gate clause → 3 of the 6 new tests failed (below-floor suppression, production config, T2 independence) → restored → all green. Satisfies AGENTS.md §5.7.

@bernhardberger — one difference from your original expectation: the final fix drives the T1 growth floor from the global minNudgeContextPercent (a percent), not from modelMinLimits. For your 150K floor on a 400K model, set minNudgeContextPercent: 37.5. (modelMinLimits still governs the turn/iteration reminder soft limit — semantics unchanged.) Your plan to restore nudgeGrowthTokens: 50000 is unaffected: the earliest T1 nudge is governed by the 37.5% floor, T2/T3 cadence by 50K.

PR: #343 (merge is a human-only step — I don't merge PRs)