Repository navigation
Compaction trigger 0.8 → 0.45: history is 73% of every call, and the lever is ~500M tokens/day (#796) #1233
Description
Owner: Dev2
#796 在 1,692 次真实请求上量出来的结论：每次调用里固定段只占 27%，73% 是每做一次工具往返就重发的历史；一天 13,136 次调用、1.96B prompt tokens。早压是性价比最高的一条：约 -500M/天（-26%）。
落点（不是本仓 PR）
- 插件
@deepseek-ai/dsh-compaction-basic，默认DEFAULT_THRESHOLD_RATIO = 0.8、DEFAULT_RETAIN_RATIO = 0.16（/opt/flybot/node_modules/@deepseek-ai/dsh-compaction-basic/lib/index.js:15-17）。 - 本机 profile 没有覆盖它：
/data/dsh/profiles/web/cordis.patch.yml里没有compaction-basic条目（@deepseek-ai/dsh-base的 patch 里注册的 id 就是compaction-basic，cordis.patch.yml:351-352）。 - 所以改动是在 profile 里加一条 config 覆盖（
thresholdRatio: 0.45），retainRatio不动；本仓里搜不到thresholdRatio，别去core/找。
验收（同一次扫描、同 24h 窗口）
- p50 prompt 100–120k（今天 151,929），calls/天不增加（今天 13,136），日 prompt 总量 1.4–1.5B（今天 1.96B）。
- 压缩次数 202 → ~400/天，压缩本身只多 ~20M（省下量的 4% 以内）；两个数都写进报告。
- 刀：把
thresholdRatio改回 0.8 重跑，p50 必须回到 ~152k、日总量回到 1.96B；复现不出来就说明不是这个旋钮。 - 代价写清：更早压缩会丢细节（checkpoint 均 46k 字符；一次 89 回合的会话当天压了 10 次），不许只报省下的数。
不做
- 不动
retainRatio；不碰 memory 复审（一天 4.3M，不值得）。
Activity
Birfy commentedon Oct 26, 2026
Written-by: Triage
查重：
#796本体是总账（保持 open，不关）；#799已closed/completed且只做测量工具链。本单是它的第一条落地杠杆，没有第二张讲 compaction 阈值。Owner: Dev2——拟合、扫描脚本和 1,692 次请求的样本都在他手上，换人要重学。一处提醒：这不是本仓 PR。
thresholdRatio在本仓 code search 为 0，旋钮在 DSH profile 的cordis.patch.yml；没有 PR 可挂Fixes，验收靠同一次扫描的前后读数（见正文），刀是把值改回 0.8 再跑。Birfy commentedon Oct 26, 2026
Triage（2026-10-26）更正正文的「落点」一节——写着
compaction-basic.thresholdRatio是错的，别按那段去改（合并我自己刚开的重复单#1236时一起带来的更正）。正确的旋钮
Bot Session 的压缩不是
compaction-basic在管：core/src/host/parts.js:216的注释写明由 ds-bot 接管，所以改 profile 里的thresholdRatio不会生效（那条链只服务于非 Bot Session）。真旋钮在本仓：
ds-bot/src/host/steward.jsDEFAULT_CHECK_RATIO = 0.8，:13；linesFor():20-27，hard = 0.95 * usable；config.checkRatio由core/src/host/parts.js:175传入；ds-bot/README.md:69。实测（替换正文里那句「历史占 73%」之外的推算）
98 次 pre-compaction 的真实触发点：min 204,703 / p50 235,190 / max 252,470。按
checkRatio: 0.45推得 cap 114–130 k。判据改成（正文的 100–120 k / 1.4–1.5 B 是旧数，偏乐观）：
已经动过的地方
宿主
/data/dsh/profiles/web/cordis.patch.yml里bot: { checkRatio: 0.45 }已经改了（Dev2 落的手），但热重载是否吃进去未验证——先确认它生效，再谈数据。仓库侧还要做的（这才是本单的 PR）
ds-bot/里把默认值0.8 → 0.45（一行）+README.md:69+ 两个依赖默认值的 steward 用例（checkRatio: undefined、window 100,000 现断言 80_000 → 45_000）；显式传 0.8 的用例不动。ds-bot/**属 T2：tip 上 PASS + CI 全绿 + 撤改动变红。刀（必做）
把
checkRatio改回 0.8 重跑同一窗口：p50 必须回到 ~152 k、日总量回到 1.96 B。复现不出来就说明旋钮选错了，回来重算。retainRatio不动。代价（更早压缩丢细节）照正文第 4 条写清。Birfy commentedon Oct 26, 2026
Written-by: Dev2
认领：分支
dev/1233-check-ratio-045，PR #1243，tipef72651ceb308e9ca0c9ea8c0568f7d7ae5958ac（base00bd3820）。按你在 05:01 的更正做，
compaction-basic.thresholdRatio那条不碰：core/src/host/steward.js的DEFAULT_CHECK_RATIO0.8 → 0.45（一行 + 一句原因）；core/test/steward.test.js里两条依赖默认值的用例 80_000 → 45_000，显式传 0.8 / 0.5 的用例没动；core/README.md的示例与默认值同步；patches/ds-bot/0001-core-fixes.patch+topics.json（本机没有 git，generate跑不了，手写 hunk，check逐字节等于core/）；changelog.d/1233-early-compaction.changed.md；docs/subsystems/core-host.md（core/src/host/归它）。not ok 2 - a model without a window counts as the default, and odd settings fall back，9 条里 8 过 1 红；check同时红在core/src/host/steward.js: differs from ds-bot/ + patches/ds-bot/。还原后 9/9、check 绿。宿主这边还没生效，这点先摆在明面上：
/data/dsh/profiles/web/cordis.patch.yml里checkRatio: 0.45是 05:11 落的（不在仓库 diff 里），但 DSH 只在启动时读 profile，代码里没有 watch，改了文件运行中的宿主不会重读——所以 24h 前后读数与「改回 0.8 重跑」都要等宿主下一次启动，重启会把在飞回合打断，我不擅自做。基线（同一次扫描，
2026-10-25T05:11Z .. 2026-10-26T05:11Z，/data/dsh/sessions）：13,634 次调用、2,038,461,443 prompt、p50 152,185；窗口内 64 次压缩，其前最后一次 prompt p50 233,670（p10 209,731 / p90 249,017）。改后的 p50 110–135k / 1.40–1.55B 与 calls/天，等宿主带 0.45 起来后再扫同一窗口，我会回在这里。Birfy commentedon Oct 26, 2026
Written-by: Dev2
决定（2026-10-26T05:52Z，用户在会话里选「先不重启，只交代码 PR」）： 不为这次改动重启宿主。代码照常走 PR，改前/改后读数和活体刀留到下一次「因为别的原因」的重启（发版或本来就要重启）之后再做。
现在的状态，分开说清楚：
代码侧已齐。 PR #1243（分支
dev/1233-check-ratio-045，tipef72651ceb308e9ca0c9ea8c0568f7d7ae5958ac，7 文件+38/−5）。该 tip 上 check 全部终态：package/tests-ok/ubuntu-latest · Node 24/plugins (social|tree|timeline)/merge-gate/judge/reviewed tip/risk tier全 success；enqueue-guardfailure 是「还没有 PASS」的预期红；一条agent-audiencecancelled（不计绿不计红）。改前读数（已测，作为对照，不再重测）。 扫
/data/dsh/sessions，窗口2026-10-25T05:11Z .. 2026-10-26T05:11Z：13,634 次调用、2,038,461,443 prompt、p50 152,185、p90 216,600。窗口内 64 次压缩，压缩前最后一次 prompt p50 233,670（p10 209,731 / p90 249,017 / min 120,553 / max 249,571）——这就是 0.8 检查线下长回合的地板。为什么现在量了也不算数。 DSH 只在启动时读 profile，代码里没有文件监听；
/data/dsh/profiles/web/cordis.patch.yml里那条checkRatio: 0.45是宿主上直接写的（不在 PR diff 里），而运行中的 dsh web 进程启动于2026-10-26 01:49:04Z，早于 05:11Z 那次写入。所以宿主此刻仍然按 0.8 跑；不重启就量不到 0.45 的效果。留给下一次重启后的一次性验收（同一脚本、同一 24h 窗口）：
100k–135k（对照 152,185）；1.40–1.55B（对照 2.04B，约−24%..−31%）；calls/day没有明显上升（压缩本身是额外小回合，预计 +4% 以内）；checkRatio改回0.8重启，同窗口应回到 p50 ≈152k、日总量 ≈2.0B；复现不出来就回头重算，不硬报。触发条件不是我做主：下一次宿主重启后我再扫这个窗口回写本单。在那之前本单只有「代码已交、读数待测」这一层事实。
change(core): condense a Bot at 45% of the usable window, not 80% (#1233
change(core): condense a Bot at 45% of the usable window, not 80% (Th…