频繁触发压缩，导致缓存一直掉

[Juna9969]

acp.log请查看附件log日志

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 先同步进度和遇到的阻塞，避免你再干等：

阻塞：我这边拉取你附件里的 acp.log 一直超时（我的运行环境只放行了 GitHub API 域名，访问不到附件 CDN），上一次就是卡在这一步导致进程无输出被重启。已避开该操作，改用代码侧分析推进，但日志是关键证据，我这边拿不到。

代码侧初步分析（压缩触发逻辑，src/index.ts + src/config.ts）：
压缩由 nudge 驱动，三条触发路径——

1. 增长分支：自上次 nudge 后上下文增长 ≥ nudgeGrowthTokens（默认 50000）→ 软 nudge
2. 压力带：上下文使用 ≥ 75%（maxContextLimit）→ 强制 nudge（绕过增长门）
3. 紧急带：≥ 95%（emergencyThresholdPercent）→ 紧急截断

每次 compress 把一段消息替换成 summary，改变了上下文前缀 → 在该点之后 LLM 的 prompt cache 全部失效。压缩越频繁，cache 反复失效（也就是你说的"缓存一直掉"）。所以根因是压缩触发太频繁，而不是压缩本身。

需要你帮忙补一下证据（任选其一即可）：

1. 把 acp.log 里 [turn] 和 [nudge] 相关的行贴出来，重点是这些字段：tokens / pct / nudgeReason / event=drop-reanchor / event=scale-flip-reset / nudge=active|emergency；
2. 或者直接描述：压缩大概多久触发一次？每次触发时 tokens/pct 是多少？你的模型 context window 多大、用的哪个 provider/model？

拿到这些我就能定位到底是「增长分支太频繁」「压力带长期驻留」还是「baseline 重置 bug」，再给对应方案，不会瞎改。

[ranxianglei]

acp.log 已经放到你的工作目录根下了(文件名 acp.log),直接读文件分析即可,不用再走网络拉取。

[Juna9969]

模型支持272K，读两、三个文件它就压缩一次

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 已拿到并逐行分析了 acp.log（0.1.52 版本）。根因定位如下——不是压缩逻辑太敏感，而是有效上下文上限被压到了 28K。

根因（日志证据）

1. 第 1 行 contextWindow=128000 —— 你的模型实际支持 272K，但系统只检测到 128K（本地 gguf / openai-completions，Pi 没拿到真实窗口，用了 128K）。
2. 第 6 行 output-headroom before=128000 after=28000 maxOutput=100000 —— OpenAI 系 API 的 output 占用 window，系统从 128K 里预留了 maxTokens=100000 给模型输出，留给上下文的只剩 28000。
3. 28K 有效上限 → 75% 压力带 ≈ 21K。读两三个文件（每个几 K~十几 K token）就突破 21K → 触发 OVER-LIMIT nudge → 压缩。
4. 第 32 行 tokens=21232 … usage 76%（21232/28000=75.8%）→ 第 34 行压缩（只压了 3206 token，还排除了 5 条受保护消息）。

所以"读两三个文件就压缩一次"是有效上限只有 28K 导致的；压缩逻辑在 28K 窗口下其实是正常工作的。（顺带：日志里那个 pct=44% 是 host/Pi 尺度的旧字段，和实际触发用的 76% 不是一回事，#289 已在 0.1.59 拆成 hostTokens/hostPct，可忽略。）

修复（配置侧，改一个就够，两个都改更稳）

• 首选：把窗口设成真实值 272000。 两种方式：
  • Pi 模型配置（models.json）里把这个模型的 contextWindow 改成 272000；或
  • ~/.pi/acp.json 加 "modelContextLimit": 272000（或环境变量 ACP_MODEL_CONTEXT_LIMIT=272000）。
  • 设成 272K 后，预留 100K output，有效上限 = 172K，读几个文件不会触发压缩。
• 同时建议：maxTokens=100000 偏高。 编码回复通常几 K token，降到 16384~32768 更合理。即使窗口保持 128K，降到 32768 后有效上限也有 ~95K。

代码侧（可选改进，听你拍板）

目前 output-headroom 只打 [info]，没有提醒"有效上限过小"。我建议加一条 [warn]：当预留后有效上限 < window 的 25%（或 < 32K）时，明确提示"maxTokens 预留过大，建议调低 maxTokens 或调高 window"。这样这类配置问题能第一时间暴露，而不是等到频繁压缩才发现。

下一步

你倾向哪个：(a) 我直接提这个 warn 的 PR（治本，防以后再踩）；(b) 你先按上面改配置验证一下，确认 272K 生效后我再决定要不要做 (a)？

[Juna9969]

请基于在环境变量ACP_MODEL_CONTEXT_LIMIT=180000的情况下再进行回答

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 收到，基于 ACP_MODEL_CONTEXT_LIMIT=180000 重新算一遍。

先澄清：之前那份 acp.log（0.1.52）里是 contextWindow=128000 / after=28000，说明那个 session 没设这个环境变量（用了 Pi 报的 128K）。现在按你实际的 ACP_MODEL_CONTEXT_LIMIT=180000 重算：

计算（env 优先级最高，config.ts:384-391）：

• base window = 180000（env 覆盖 Pi 的 128K）
• maxTokens 仍 = 100000（来自 Pi 模型配置，env 不改它）
• output-headroom（OpenAI 系，index.ts:281）：180000 − 100000 = 80000 有效上限
• 75% 压力带 = 60000，emergency(95%) = 76000

所以：就算设了 180K，有效上下文还是只有 80K，75% 带卡在 60K。读两三个大文件（每个 >20K token）就突破 60K → 触发压缩。瓶颈不是 180K 窗口，是 maxTokens=100000 吃掉了 100K。

修复（按杠杆从大到小）：

1. 主要：把 maxTokens 从 100000 降到 16384~32768。 编码回复通常几 K token，100K 的 output 预留严重浪费窗口。
   • 降到 32768：180000 − 32768 = 147232 有效上限，75% 带 = ~110K（余量翻倍多）。
2. 次要：把 ACP_MODEL_CONTEXT_LIMIT 提到模型真实窗口 272000。 你设的 180K 低于模型支持的 272K，还留着 92K 没用。
   • 272000 − 32768 = 239232 有效上限，75% 带 = ~179K，非常宽裕。

结论：180K 窗口本身没问题，频繁压缩的根因是 maxTokens=100000 预留过大，把有效上限压到 80K。降 maxTokens 是关键，提窗口是锦上添花。

麻烦确认下你 Pi 模型配置里这个模型的 maxTokens 是不是 100000？如果是，先降到 32768 应该就能明显缓解；如果已经是较小值了，那把新 session 的 log 再发我一份（看 output-headroom 那行的 before/after/maxOutput），我接着定位。

[Juna9969]

这是我ACP面板：“
[acp-status]

╭─────────────────────────────────────────────╮
│ ACP Context Analysis │
╰─────────────────────────────────────────────╯
billion-context-pi@0.1.59

Context (session accounting, host footer scale): 62% (43k / 69k) — includes compressed originals; shrinks slower than the sent view
Growth: +544 since last nudge

Sent to LLM (after compression, est.): 25k (36% of limit)
Session-only (compressed originals, est.): 29k — pruned from every request; the footer/nudge still count them”，环境变量设置值为200K， acp.json设置了272000，尝试过执行/reload进行重载，但acp面板仍显示目前发送给你的这情况。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 看了你的 ACP 面板，定位到关键点了。

面板里的 "limit"（69k）不是你的窗口，而是 窗口 − maxTokens（output-headroom，src/index.ts:281 → src/overflow-selfheal.ts:85-96）。面板两行都印证：43k/69k=62%、25k=36% of limit → limit 就是 69k。

你设了 ACP_MODEL_CONTEXT_LIMIT=200000 + acp.json modelContextLimit=272000，但有效上限只有 69k，倒推 maxTokens：

• 若 env(200K) 生效：maxTokens = 200000 − 69000 = 131000
• 若 acp.json(272K) 生效：maxTokens = 272000 − 69000 = 203000

无论哪种，maxTokens 都异常大——这才是把有效上限压到 69k 的元凶，不是窗口设小了。27B 模型正常 maxTokens 是 8k~32k，131k/203k 明显是配置里写大了（或 Pi 给这个本地模型默认了个很大的值）。

两件事需要你确认：

1. 配置到底生效没？ env 变量是 Pi 进程启动时读的，/reload 重读 acp.json 但不重读 env。如果你是 Pi 启动后才设的 ACP_MODEL_CONTEXT_LIMIT=200000，那它根本没进 process.env，得重启 Pi 才生效。
2. maxTokens 实际是多少？ 这是决定性数字。

请发一份新 session 的 acp.log（用你当前配置跑），我要看这两行：

• 开头的 … contextWindow=…（Pi 报的 live 值）
• [overflow-selfheal] … event=output-headroom before=… after=… maxOutput=…

before 告诉我 base 窗口（200000=env 生效 / 272000=acp.json 生效 / 别的值=都没生效）、maxOutput 直接给出 maxTokens。有了这两行我就能一锤定音：是 maxTokens 写大了，还是配置没加载上。

（临时缓解：把 Pi 模型配置里这个模型的 maxTokens 降到 32768，重启 Pi，有效上限立刻回到 ~137k/239k。）

[Juna9969]

在基于ACP_MODEL_CONTEXT_LIMIT设置200K，模型的输出token会进一步压缩窗口空间，如输出token最大值为131000，空间仅剩下69K，实际正常输出达不到最大值（这仅是模型参数理论值），请以结合当下模型能力及coding情况寻找最优平衡方案（需穿透+横向进行审视）。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 确认你的判断：maxTokens=131K 是瓶颈，而预留完整 max 是过度保守——coding 实际输出远达不到 131K（那只是理论上限）。下面给穿透+横向审视后的最优平衡方案。

穿透：根因是「按理论最大值预留，而非按典型输出预留」

• output-headroom 现在做 effective = window − maxTokens，把理论最大输出整个扣掉。你的 200K 被 131K 吃掉，只剩 69K。
• 但 coding 的实际输出通常几 K~32K（代码文件/解释/工具调用），几乎到不了 131K。预留 131K = 浪费 65% 窗口。
• 安全网：overflow self-heal（src/overflow-selfheal.ts）在真正 overflow 时会学习真实窗口并 arm emergency。所以「少预留一点」是安全的——最多多一次 overflow，self-heal 立刻纠正。这正是不必预留完整 max 的依据。

横向：不同 API 怎么处理

• Anthropic Messages：input limit 独立于 max_tokens（output 单独计），不需预留（代码已豁免，shouldReserveOutputHeadroom）。
• OpenAI 系：output 占 window，需预留，但预留完整 max 过度保守。
• 通用原则：按典型输出预留，而非理论最大值；再用窗口比例兜底小窗口。

最优平衡方案（推荐）

给 output-headroom 的预留设上限：

reserved = min(maxTokens, min(32768, 0.25 × window))

• 32768：覆盖典型 coding 输出（几 K~32K），再多靠 self-heal 兜底。
• 0.25 × window：小窗口兜底（32K 窗口只预留 8K，不会把上下文压到 0）。
• 大窗口下 32K 是约束（更省），小窗口下 25% 是约束（更安全）。

你的场景（200K + maxTokens=131K）：
reserved = min(131000, min(32768, 50000)) = 32768 → effective = 200000 − 32768 = 167232（69K → 167K，2.4×）。75% 压力带 52K → 125K，读几个文件不再触发压缩。

影响面（精准）：只改 maxTokens > cap 的模型（大 maxTokens 场景，正是出问题的那类）；maxTokens ≤ 32K 的常见模型行为完全不变（reserved 仍 = maxTokens）。

可选增强

加配置项 outputHeadroomCap（默认 32768），让确实需要大输出预留的模型能手动调高，不破坏默认。

请 owner 拍板

要我直接提 PR 吗？改动集中在 src/overflow-selfheal.ts 的 reserveOutputHeadroom（加 cap）+ 单测。默认值 32768 / 25% 你认可我就按这个实现；想调默认值现在说。

[ranxianglei]

#207 看看是一个问题吗

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 是同一个问题——#333 就是 #207 的重复，而且 #207 已经修好了（PR #301），只差合并。

根因完全一致：reserveOutputHeadroom（src/overflow-selfheal.ts:85-96）按 ctx.model.maxTokens（模型注册表的最大输出能力，非实际使用值）全额预留，effective = window − maxTokens：

• 输出预留(output headroom)按最大输出能力全额预留,输入预算被砍半,75% 强制压缩过早触发 #207：qwen3.8-27b (vllm)，window=262144，maxTokens=131072 → effective=131072（砍半），75% 带在完整窗口 ~34% 就触发。
• 频繁触发压缩，导致缓存一直掉 #333：qwen3.8-27b (gguf)，window=200K（env），maxTokens=131K → effective=69K，同样过早压缩。

只是具体配置不同（vllm vs gguf、窗口/maxTokens 数值不同），病因和药方完全相同。

已经修好并验证：PR #301（分支 2026-09-05_issue207-headroom-cap，commit b1b1273）——reserved = min(maxTokens, outputHeadroomMaxPct × window)，新配置键 outputHeadroomMaxPct 默认 0.25（0 禁用预留，≥1 回退旧全额行为）。typecheck ✓ / 466 tests ✓ / build ✓。#207 算例：effective 131072 → 196608（窗口 75%），75% 带触发点 ~37.5% → ~56.25%。日志也消歧了（[turn] 加 fullWindow、output-headroom 加 cap）。

我上一条给 #333 提的方案（把预留 cap 到窗口比例）和 PR #301 是同一个思路，所以不需要再开新 PR。

唯一卡点：PR #301 还没合并（合并是人工操作，系统规则禁止我合）。合并后 closes #207 自动关闭 #207，#333 的问题一并解决。

建议：

1. 直接合并 PR fix(overflow): cap output-headroom reservation at a fraction of the window (closes #207) #301：fix(overflow): cap output-headroom reservation at a fraction of the window (closes #207) #301
2. 频繁触发压缩，导致缓存一直掉 #333 作为 输出预留(output headroom)按最大输出能力全额预留,输入预算被砍半,75% 强制压缩过早触发 #207 的重复关闭（我这边没有关 issue / 打标签的权限，需要 owner 操作；合并 PR 后一并处理即可）。

想先本地验证再合并：

git checkout 2026-09-05_issue207-headroom-cap
npm run build
cp dist/index.js ~/.pi/agent/npm/node_modules/billion-context-pi/dist/index.js
# 重启 Pi

[ranxianglei]

合并了,发新版本pr

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 已发新版本 PR：#334

release v0.1.60（0.1.59 → 0.1.60）

• 基于最新 master e3a5bc3（即 PR fix(overflow): cap output-headroom reservation at a fraction of the window (closes #207) #301 合并后的 master，含 headroom cap 修复）
• 包含两个修复：
  • PR fix(overflow): cap output-headroom reservation at a fraction of the window (closes #207) #301（fix 输出预留(output headroom)按最大输出能力全额预留,输入预算被砍半,75% 强制压缩过早触发 #207）：output-headroom 封顶，新增 outputHeadroomMaxPct 配置（默认 0.25）—— 就是 频繁触发压缩，导致缓存一直掉 #333 的根因修复
  • PR fix(state): keep in-memory subagent compress state across turns (issue #322) #323（fix [Bug] in-memory 子代理压缩状态未写回 cache，导致 152 次重复压缩 #322）：in-memory 会话压缩后状态不再丢失
• acp-kernel 保持 0.0.56 不变（fix(overflow): cap output-headroom reservation at a fraction of the window (closes #207) #301 没动它）
• CHANGELOG 补了 [Bug] in-memory 子代理压缩状态未写回 cache，导致 152 次重复压缩 #322 条目（输出预留(output headroom)按最大输出能力全额预留,输入预算被砍半,75% 强制压缩过早触发 #207 条目 PR fix(overflow): cap output-headroom reservation at a fraction of the window (closes #207) #301 已加）

验证（本地已跑，CI 合并时会再跑一遍）：

• npm run typecheck ✓
• npm test ✓（632 total / 629 pass / 0 fail / 3 skipped）
• npm run build ✓（dist/index.js 728.83 KB，acp-kernel 0.0.56 内联）

下一步：你合并 PR #334 后，CI 会自动 publish 0.1.60 到 npm。合并后我可以帮你确认 npm view billion-context-pi version 是否已更新到 0.1.60。

⚠️ 按系统规则 PR 合并是 human-only（我不能 merge），需要你手动合并：#334