[PR] fix: compressed thinking reclamation (#651) default changed to be uniformly deactivated with collapse, eliminating the once-per-turn cache seam (Refs #3198) | [PR] fix: 压缩思考回收(#651)默认改为随折叠统一下线,消除每轮一次的缓存接缝 (Refs #3198) by ranxianglei · Pull Request #3311 · ranxianglei/billion-context

ranxianglei · 2026-10-15T16:23:20Z

(ai: zhipuai-lb/glm-5.3)

坏了什么

长会话里每完成一轮压缩工具调用,下一轮请求就会少一段思考内容(#651 机制)。这是对历史消息字节的修改:上游前缀缓存从修改点开始全部失效——每轮关闭一次、每次几千到上万 token 重新计费(实测样本:99%→91%,3.3K 重付;#3198 报告里 13–17K 的样本同源)。账本之前把它记成"未知缓存接缝",正是 #3198 的恐慌来源。

根因

drop 的时机:轮次一关闭就立刻把该轮 reasoning 从请求里删掉。几十上百轮的会话,每轮一次 mid-history 重写 = 每轮一次缓存 miss。

修法(flush:"fold" 默认)

已关闭轮次的 reasoning 不再立刻下线,两次折叠之间冻结在线上(wire 字节稳定);
下一次折叠落地时在同一请求里统一下线——字节变化被折叠自身的重计费区间覆盖,不再新开接缝;
64KB 待回收量上限兜底从不折叠的会话(每次越限触发一次、单独归因);
compress.reasoning.flush:"close" 保留旧时序(默认关闭;开启即接受每轮一次接缝,适合本地无所谓 miss 的端点);
重启后 applied 集清空,reasoning 回到线上一次(重启重计费已有归因臂)。

依赖(stack,合并顺序)

#3196(签名 thinking 闸门修复,作者 @sorinirimies 的 3 个 commit 原样保留)→ #3300(账本归因)→ 本 PR。下层合并后 GitHub 会自动收敛本 PR 的 diff。

config surface

新增 compress.reasoning.flush: "fold" | "close",默认 "fold";CONFIGURATION.md / CONFIGURATION.zh-CN.md 已同步(en+zh)。既有配置无需迁移(缺省即新默认)。方案在 #3198 处理过程中由 owner 批准(2026-10-16)。

kernel-change

无(全部在 src/ 与文档;不触 kernel/)。

证据

tests/reasoning-flush-fold.test.ts 6 项:fold 冻结+折叠冲刷 / close 旧时序 / 64KB 兜底 / 闸门复位 / 重启语义 / 非法值回退;
reasoning 家族 126/126、cache 家族 27/27、归因套件 10/10、typecheck 干净;
e2e codex 套件(管线变更要求)本地运行中,合并判定以远端 CI 为准。

每个压缩回合关闭时,reasoning-drop 会把该回合的思考内容从出站视图移除——这是一次已知的中段历史改写,每次回合恰好重计费一次。此前账本把这笔 miss 记成「⚠ CACHE SEAM(疑似中段前缀断裂)」, #3198 排查正是被这个无归因桶吓出来的。现在 prepare-* 在 planReasoningDrop 之后上报计划 (noteReasoningDropPlan):计划增长=有回合新关闭,下一个大残差 miss 归因为 prov="reasoning" 的新桶,并在 /acp-cache 输出「℞ COMPRESS-REASONING ROUND-CLOSE」一节(含 compress.reasoning. drop=false 的关闭方法),网页轨迹图同步新增该颜色桶。进程内首次观测只做基线(重启后视图已稳定,不误借归因);打点消费一次即失效, 120 秒窗口兜底。

默认时序从"轮次关闭即剥离"改为 flush:"fold":已关闭轮次的 reasoning 在两次折叠之间保持在线(wire 字节稳定),下一次折叠落地时随折叠自身的重计费区域一并回收;从不折叠的会话由 64KB 待回收量上限兜底(每次越限一次、账本归因)。compress.reasoning.flush:"close" 保留旧时序(默认关闭,开启即接受每轮一次接缝,适合本地端点)。restart 语义:applied 集仅存内存,重启后 reasoning 回到线上(重启重计费已有归因)。

github-actions · 2026-10-15T16:35:09Z

📦 Built Package Artifact

Branch: 2026-10-16_reasoning-flush-fold (0ec0bf1)

Option A — Install this exact build (recommended)

npm install -g billion-context@0.0.3933-pr.3311.dbba0be

This exact version is immutable and reproducible. The rolling pr tag tracks the newest test build across all PRs.

Option B — Download artifact

Download the artifact from the Actions run
Extract the tarball and install:

tar xzf billion-context-pr3311.tgz
npm install -g package

Install instructions are refreshed on each push.

…ng is a live i18n key The #3300 change added CAUSE_COLOR.rd / CAUSE_KEY.rd and the prov==='reasoning' cause mapping but never pushed a legendItem() for the new bucket, so the purple segment rendered unlabeled AND the i18n dead-key guard (#1024) failed because t("det.leg_reasoning") was never referenced. Add the swatch mirroring its siblings (color matches CAUSE_COLOR.rd = #8250df).

#3300 adds reasoningDropMisses/reasoningDropMissed to the cache-ledger agg, which persists inside session.metadata, so the digest-based storage-render snapshots drift (only the metadata section hash changes; state/blockContents/ stats unchanged). Regenerate via scripts/update-storage-render-goldens.ts. Additive, zero-default, backward-compatible fields (backfilled on load); no persistence version bump.

Sync master (incl. #3266 image-precompression removal) into the PR branch. Conflict only in tests/golden/storage-render/*.json (both sides regenerated since base): resolved by taking master's fixtures and re-running scripts/update-storage-render-goldens.ts on the merged tree so the snapshots match post-#3266 code plus #3300's two new persisted ledger counters. Verified on this tree: typecheck clean; golden-storage-render + web-i18n + cache-seam-* + cache-ledger suites 81/81 green.

…generation keeps the rows (#3198)

…det.leg_reasoning was a dead i18n key (#3198) The /acp-cache detail page paints the 'rd' cause (#8250df) on the chart and names it in the tooltip, but the unattributed family's sub-legend never rendered a row for it, so the catalog key #3300 added was referenced by no rendered surface (tests/web-i18n.test.ts dead-key gate). Add the conditional row alongside the other seam sub-causes.

ranxianglei · 2026-10-15T19:27:44Z

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

查重: 不重复——本 PR 是 #3198 处理流中 owner 已批准的第三个交付物(#3196→#3300→本 PR 的 stack,无并列修复项)。但审核中发现的 CI 测试分片红与已有跟踪项重复,不另立 issue:金标漂移 = #3313/#3314(在途修复)、T5 liveness = #3315 子缺陷 2/#3317(在途修复)、AC12 = #3315 子缺陷 3(我补了证据,见下)。

审核做了什么(独立于前两轮 review)

本地环境与 CI 逐字节对齐验证:用 golden-storage-drive 的 dumpStateTo 在 merge-base(6ee4a2a)与 PR head 各跑一次 chat wire,本地 base 摘要(7bd74bdd…)与 master CI 实际失败摘要完全一致——后续所有本地判定可直接采信。
通读本 PR 主机制 diff(settleReasoningDropPlan,src/server.ts:1651-1706 + 四条 wire 的接入点):fold 判定用 processTurn 前后 blockId 集合差;applied 集只在「本请求落了折叠 / 64KB 待回收量越限 / 闸门打开(candidate 空)」三个时刻生长或复位;flush:"close" 分支逐字节回到旧时序。四条 wire(openai/anthropic/responses/google)接入一致。机制成立。
定向测试:reasoning 家族 30/30(flush-fold 6 项 + drop + cache-seam)、web-i18n 10/10、typecheck 干净。
CI 红的逐项根因(head 67351e1,run 38777606375;shard 3 全绿、shard 1/2 在全部平台×node 组合确定性挂):

失败	归属	处置
`web-i18n` dead key `det.leg_reasoning`(shard 1)	本 stack 引入(#3300 加了桶和目录键,但 /acp-cache 详情页的 seam 子图例没渲染这一行)	已修并推送 `b71283e`:子图例补一行条件渲染(`seam.reasoningDrop.count > 0` → `#8250df` 图例行),与图表着色/tooltip 同源;本地 10/10
`golden-storage-render` ×4(shard 1)	两层叠加:① master 自身过期——#3295 的 `5bcc345` 删掉 3 个死 image-stats 字段后没重生成金标(#3313/#3314 在途);② 本 stack 的 #3300 向持久化 metadata 新增 2 个账本字段(`agg.reasoningDropMisses/Missed`,本次会话中均为 0)	A/B dump 证实 base↔PR 唯一差异就是这 2 个字段。不现在重生成(避免与 #3314 双重基线互相踩):等 #3314 合入 → rebase 本 PR → 补一个金标重生成 commit(届时理由收窄为「#3300 的两个新账本字段」),写进 PR 描述
`#1086 T5 liveness`(shard 2)	master 回归,与本 PR 无关:master run 38767006158 同样挂;#3289 的输出护栏(text-run ≥200 中止流)打中假上游的 `"x".repeat(360)` 填充,确定性失败	#3317 在途修复,不重复做
`AC12 lineage-reconcile-boot`(shard 2)	master 回归,且不再是偶发:#3315 原判 flake(仅 1 次样本);现 master CI、本 PR CI、本地 master 树三处确定性复现(`assert.notStrictEqual(true,true)`)	已在 #3315 补证据评论,建议按真回归 bisect

结构化八问

是什么问题:长会话里每关闭一轮压缩工具调用,下一轮请求就少一段思考内容(Protected-message exemption inflates the incompressible context floor: per-compression reasoning is never reclaimable (~83.5% of measured residual) #651),每轮一次 mid-history 字节重写 = 每轮一次前缀缓存失效、几千到上万 token 重新计费;本 PR 把默认时序改为随折叠统一下线消除这个接缝。
什么原因导致的:drop 时机——轮次一关闭就立刻从出站视图剥离该轮 reasoning;几十上百轮的会话每个轮次关闭都改写一次历史中段。
影响范围与严重程度:所有开 compress.reasoning.drop(默认开)且有压缩轮次的长会话;计费层面每次接缝重付几千~1.7万 token(实测 99%→91%),功能无损。属「特定条件下持续多付费」,非不可用。
怎么修复的:已关闭轮次的 reasoning 在两次折叠之间冻结在线(wire 字节稳定),下一次折叠落地时在同一请求里随折叠自身的重计费区域一并回收;从不折叠的会话由 64KB 待回收量上限兜底(每次越限一次、单独归因);applied 集仅存内存,重启后回到线上(重启重计费已有归因臂)。
是否有回归问题:审过的既有行为——flush:"close" 路径逐字节保留旧时序(有测试钉住);闸门打开时 applied 集复位,行为回到本机制引入之前;四 wire 接入一致;reasoning 家族 30/30。注意:本 PR 当前 CI 红不是代码回归,是上述 master 存量红 + 金标未随 [PR] fix: re-billing for compacted thinking reclamation (#651) was misreported as an unknown cache seam; now attributed separately (#3198) | [PR] fix: 压缩思考回收(#651)的重计费被误报为未知缓存接缝,改为单独归因 (#3198) #3300 重生成(处置见上表)。
是否破坏缓存:这正是本 PR 要修的——旧默认每轮一次缓存接缝;新默认把接缝并入折叠自身(折叠本来就要重计费该区间)。重启会一次性让冻结中的 reasoning 回线上,已有 restart 归因臂覆盖。
是否改了设计方向:不改架构;只改 Protected-message exemption inflates the incompressible context floor: per-compression reasoning is never reclaimable (~83.5% of measured residual) #651 的下线时序策略并加一个开关。账本侧([PR] fix: re-billing for compacted thinking reclamation (#651) was misreported as an unknown cache seam; now attributed separately (#3198) | [PR] fix: 压缩思考回收(#651)的重计费被误报为未知缓存接缝,改为单独归因 (#3198) #3300)新增的归因桶与持久化 agg 字段是配套可观测性,不改变既有桶语义。
是否引入了新的配置:compress.reasoning.flush: "fold" | "close",默认 "fold";env 覆盖 BILI_REASONING_FLUSH;CONFIGURATION.md en+zh 已同步;缺省即新默认,无需迁移。(审核顺手修的一处 UI:web-i18n 子图例行,纯展示。)

合并判定:代码本身可合(机制正确、测试有牙、配置面合规)。CI 转绿的前置链:先合 #3314 + #3317(+ #3315 子缺陷 3 的 AC12 修复) → 本 stack rebase → 我在本 PR 补金标重生成 commit(仅覆盖 #3300 两个新字段)→ 全绿。stack 内顺序维持 #3196 → #3300 → 本 PR(或直接先合本 PR,GitHub 自动收敛下层 diff)。

…uckets (#3198) detailSeam() tolerates servers predating each attribution bucket by defaulting absent fields to zero — #3300's legend row reads seam.reasoningDrop.count without that tolerance, so any payload whose seam lacks the field (test fixtures, older server builds) throws during loadDetail and the trajectory never binds (#2489 brush tests time out in waitFor). Add the missing normalization line; behavior for current server payloads is unchanged.

…the stack merge dropped them (#3198) The merge of master into this branch silently took master's stale storage-render goldens instead of #3300's regeneration (7e5708e), so the digest-based snapshots failed on all four wires even though this tree's persisted state matches #3300's digests exactly (verified by A/B dumpStateTo against merge-base: only metadata.cacheLedger.agg differs, and those two fields are what 7e5708e pinned). Restore the four files verbatim from 4dee7e9; no re-run of the regen script was needed because the digests already agree with this tree.

…uckets (#3198) detailSeam() tolerates servers predating each attribution bucket by defaulting absent fields to zero — the legend row added in 491d52a reads seam.reasoningDrop.count without that tolerance, so any payload whose seam lacks the field (test fixtures, older server builds) throws during loadDetail and the trajectory never binds (#2489 brush tests time out in waitFor). Add the missing normalization line; behavior for current server payloads is unchanged.

ranxianglei · 2026-10-15T19:50:57Z

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

更正 + 补完我上一条 review 里的 CI 根因表——继续挖之后发现 web-i18n 与 golden 两行其实是同一事件,且验证时暴露了第三个缺陷。已修并推送 2 个 commit(分支头 b71283e → 3b51931)。

真相:stack merge 误丢 #3300 的两个 commit

把三个 head 的金标文件逐字节对比后确认:本分支合并 master 时,静默丢掉了 #3300 分支上的两个修复:

491d52a6d(渲染 ℞ legend 行,使 det.leg_reasoning 成为活键)——丢了 → web-i18n dead-key 红;我上一条的 b71283e 已把它补回(与 [PR] fix: re-billing for compacted thinking reclamation (#651) was misreported as an unknown cache seam; now attributed separately (#3198) | [PR] fix: 压缩思考回收(#651)的重计费被误报为未知缓存接缝,改为单独归因 (#3198) #3300 原行逐字节一致);
7e5708ebf(storage-render 金标重生成)——丢了 → 四 wire 金标全红(取的是 master 的过期金标)。

第三个缺陷:legend 行本身会炸旧载荷(两个 PR 都有)

本地复现发现:补回 legend 行后,#2489 brush 测试反而确定性超时(master 上 3/3 过、本分支 2/3 挂)。根因:detailSeam()(src/web/client.ts:1073)对所有归因子桶做防御式缺省(providerTtl/providerSide/rewinds/client 缺字段→0),但 #3300 加的 reasoningDrop 漏了这个归一化——任何 seam 里没这个字段的载荷(web 测试 fixture、旧版 server)走到 seam.reasoningDrop.count(client.ts:1505)直接抛 TypeError,loadDetail 中断,轨迹图永远绑不上 = waitFor 超时。这正是 #3300 CI 在 u24s1 挂两个 #2489 测试的原因(我此前只核对了它的 shard-1 日志,现在对上了)。

已推送的修复

commit	内容	本地证据
`32c0bbb`	`detailSeam()` 补 `reasoningDrop` 防御式归一化(与兄弟桶同一模式一行)	brush 3/3、web-i18n 10/10
`3b51931`	从 `4dee7e9` 原样恢复 4 个 storage-render 金标(无需重跑 regen 脚本:digest 已与本树实际输出完全一致;且本树保留 #3300 的两个 agg 字段,未来 rebase 后该金标仍然有效)	golden-storage-render 4/4

reasoning 家族 30/30、typecheck 干净。同样的 normalizer 一行也推到了 #3300 分支(97ce469,已在 #3300 留言)——两处重复修同一行,符合「宁可大家都修得一样」。

更新后的合并判定不变且更稳:代码可合;CI 剩余红全部是 master 存量(T5=#3317 在途、AC12=#3315 子缺陷 3 待 bisect、#3313/#3314 金标基线),与本 stack 无关。等 master 侧修复合入后 rebase 即可全绿。

ranxianglei · 2026-10-16T00:53:32Z

冲突了

ranxianglei · 2026-10-16T00:55:26Z

冲突

…ed by regen on the merged tree (#3198)

# Conflicts: # tests/golden/storage-render/anthropic.json # tests/golden/storage-render/chat.json # tests/golden/storage-render/google.json # tests/golden/storage-render/responses.json

ranxianglei · 2026-10-16T01:03:54Z

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

冲突已解决,push 完成(merge commit eba8b94ef,普通 push 无 force-push),GitHub 已确认 mergeable。

冲突原因:master 在此期间合入了 pi-inline 功能(#3284)并重新基线了 storage-render 黄金快照(#3314,#3295 删掉死 image-stats 字段后重钉 digest);本分支之前也重新生成过同一批快照(为 #3300 的 reasoning-drop 归因桶)。两边都改了 tests/golden/storage-render/*.json 这 4 个文件,git 无法自动合并。源码部分(src/server.ts、CONFIGURATION 等)全部自动合并干净——master 侧贡献仅是 pi-inline 新功能文件组 + createEngineContext 抽取,与本分支的 fold-flush 改动零交集。

解法:把 master merge 进分支(分支叠在 #3196/#3300 之上,沿用分支既有的 merge-master 模式,不 rebase);4 个黄金文件用官方脚本 scripts/update-storage-render-goldens.ts 在合并后的树上重新生成。regen 结果与本分支原有版本逐字节一致(stateDigest e546b76a…)——即合并树在该 fixture 上的行为与分支侧一致,pi-inline 改动不影响该 fixture 的状态字节,master 侧重基线差异只是 digest 漂移,取合并树实测值为准。

结构化八问:

是什么问题:PR 与 master 产生合并冲突(dirty),不可合并。
什么原因导致的:两条工作线同时改了同一批测试黄金快照文件(master 重基线 vs 本分支为 [PR] fix: re-billing for compacted thinking reclamation (#651) was misreported as an unknown cache seam; now attributed separately (#3198) | [PR] fix: 压缩思考回收(#651)的重计费被误报为未知缓存接缝,改为单独归因 (#3198) #3300 重生成),JSON 快照无法自动三方合并。
影响范围与严重程度:仅影响本 PR 的合并状态,无任何用户面影响;不解决则 PR 一直不可合。
怎么修复的:merge master 进分支;源码自动合并;黄金快照按「以合并树实际行为为准」用官方 regen 脚本重新生成,不做手工拼 JSON。
是否有回归问题:无。typecheck 干净;定向测试 48/48 通过——覆盖 golden-storage-render、storage-engine-proofs(wire == 提交黄金)、reasoning-flush-fold(本 PR 核心语义:flush=fold 默认 / flush=close 旧行为 opt-in)、cache-seam-reasoning-drop([PR] fix: re-billing for compacted thinking reclamation (#651) was misreported as an unknown cache seam; now attributed separately (#3198) | [PR] fix: 压缩思考回收(#651)的重计费被误报为未知缓存接缝,改为单独归因 (#3198) #3300)、pi-inline/pi-native(master 侧新功能)。全量回归交给 CI。merge commit 不含任何超出「两侧原变更之并集」的代码改动。
是否破坏缓存:不涉及——未触碰缓存/重试/增量游标逻辑,黄金 regen 只是测试快照更新。
是否改了设计方向:不涉及。
是否引入了新的配置:本 merge 未引入;(pi.inline / BILI_PI_INLINE 是 Port billion-context-pi's no-server mode: inline in-process compression lane for pi #3284 自身已在 master 的内容,非本次引入)。

提醒:本 PR 叠在 #3196 → #3300 之上,两者仍 open——建议先合那两个,再合本 PR,顺序上最干净。等 CI 全绿后即可合并(合并动作留给你)。

ranxianglei · 2026-10-16T01:07:29Z

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

这条「冲突了」是上一轮冲突事件的重复转发——原冲突(4 个 storage-render 黄金文件)已在 eba8b94ef 解决并确认 mergeable。复查时发现 master 又前进了一个提交(#3312 host-plugin 提示措辞收窄),顺手把它也并进来了:

自动合并完全干净,零冲突:唯一触碰的重叠文件是 src/web/i18n.ts,且只是 fix: narrow dsh-context host-plugin notice to segment composition/timeline (#3303) #3312 自己的 hostplug.desc 中英措辞更新,与本分支的 i18n 新增无交集。
push 完成:eba8b94ef → 714db14e3(普通 push)。
GitHub 当前状态:mergeable: true,base 已是最新 master(00ea555b3);state 显示 blocked 只是因为新 head 的 CI 检查还在跑,不是冲突。

分支现在与 master 尖端完全同步,等 CI 全绿即可合并(合并留给你;叠在下面的 #3196/#3300 仍建议先合)。

…ution' into 2026-10-16_reasoning-flush-fold

… into 2026-10-16_reasoning-flush-fold

…; flush docs kept; goldens regen)

ranxianglei · 2026-10-16T03:07:09Z

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

冲突已再次解决,push 完成(0ec0bf130),GitHub 确认 mergeable: true(base 已是最新 master d8c0e50e7,state blocked 仅为 CI 检查在跑)。

这一轮的情况和上两轮不同:master 在前次解决后前进了约 30 个提交——#3196(栈底)已合入,另有 #3298/#3305(CI 三层流水线)/#3308/#3309(remove-absorb)/#3318 等。同时另一位 worker 已在本分支上做了大部分工作:把 #3300 的内容直接并进本分支(commit 2652c4fb1)、合入了当时的 master、并在合并树上重新生成了黄金快照(0858d4e11)。我接手后核对发现只剩 #3318(opencode-native 超窗拒收) 一个增量未进分支,将其合入——零冲突(涉及文件与本分支无任何重叠),并做了定向验证。

结构化八问:

是什么问题:master 持续前进后,PR 分支与 master 再次产生合并冲突(dirty)。
什么原因导致的:长命分支 + 高频主干合并的叠加效应;本 PR 又叠在尚未独立合入的 [PR] fix: re-billing for compacted thinking reclamation (#651) was misreported as an unknown cache seam; now attributed separately (#3198) | [PR] fix: 压缩思考回收(#651)的重计费被误报为未知缓存接缝,改为单独归因 (#3198) #3300 之上,主干每动一次就需要一轮 merge + 黄金快照重生成。本轮冲突面实际只剩 fix(opencode-native): proxy 不可用时超窗请求本地拒发，不再静默直连撞上游 400 #3318 的文件组,且无重叠。
影响范围与严重程度:仅影响本 PR 的合并状态,无用户面影响;不处理则 PR 不可合。
怎么修复的:先同步远端分支最新 tip(尊重另一 worker 已完成的 [PR] fix: re-billing for compacted thinking reclamation (#651) was misreported as an unknown cache seam; now attributed separately (#3198) | [PR] fix: 压缩思考回收(#651)的重计费被误报为未知缓存接缝,改为单独归因 (#3198) #3300 并入 + 重生成),再只补合剩余 master 增量(fix(opencode-native): proxy 不可用时超窗请求本地拒发，不再静默直连撞上游 400 #3318);不做 rebase(分支是叠层结构,rebase 会破坏与 [PR] fix: re-billing for compacted thinking reclamation (#651) was misreported as an unknown cache seam; now attributed separately (#3198) | [PR] fix: 压缩思考回收(#651)的重计费被误报为未知缓存接缝,改为单独归因 (#3198) #3300 的历史关系)。
是否有回归问题:无。定向验证全绿:opencode-native 39/39(fix(opencode-native): proxy 不可用时超窗请求本地拒发，不再静默直连撞上游 400 #3318 新功能)、golden-storage-render + reasoning-flush-fold 12/12(确认分支上的黄金快照在本次合并后依然有效,fix(opencode-native): proxy 不可用时超窗请求本地拒发，不再静默直连撞上游 400 #3318 只动 agent 侧文件不影响状态序列化)。全量回归交给 CI(注意 CI 改三层:PR 默认只跑核心矩阵,全量改为 30 分钟智能定时 + ci:full 标签 #3305 起 CI 已改三层流水线,PR 跑 core matrix)。
是否破坏缓存:不涉及——本次 merge 无代码改动,纯历史合并。
是否改了设计方向:不涉及。
是否引入了新的配置:不涉及。

栈状态更新:#3196 ✅ 已合入 master;#3300 的内容已被本分支完整吸收(其头部新提交只是「merge master + 重生成黄金」,无独有内容)——#3311 合入后 #3300 可直接关闭为已吸收(关闭动作留给你);本 PR 现在与 master 尖端完全同步,等 CI 绿即可合并。

ework-agent added 3 commits October 15, 2026 22:56

merge #3300 attribution branch (stack: #3196 -> #3300 -> fold-flush)

0dc09ee

This was referenced Oct 15, 2026

fix(server): redacted_thinking arms the #651 reasoning-drop gate #3196

Merged

A/B experiment: ACP_RENDER_NONE=1 (renderTags=none) eliminates dsh render seams — hit rate 85.6% -> 91.2% #3198

Closed

awork added 6 commits October 16, 2026 00:38

Merge remote-tracking branch 'origin/master' into HEAD

95196d6

docs: add missing compress.reasoning.flush seed entry so docs-sync re…

67351e1

…generation keeps the rows (#3198)

ranxianglei mentioned this pull request Oct 15, 2026

CI 测试 lane 出现与代码改动无关的失败:存储渲染快照漂移 + 两个偶发用例 #3315

Closed

awork added 3 commits October 16, 2026 03:47

ranxianglei added the 严重 label Oct 16, 2026

awork added 2 commits October 16, 2026 09:02

merge master into reasoning-flush-fold; storage-render goldens resolv…

eba8b94

…ed by regen on the merged tree (#3198)

Merge remote-tracking branch 'origin/master' into conflict-3300-r2

b0a9431

# Conflicts: # tests/golden/storage-render/anthropic.json # tests/golden/storage-render/chat.json # tests/golden/storage-render/google.json # tests/golden/storage-render/responses.json

awork added 2 commits October 16, 2026 09:04

Merge remote-tracking branch 'origin/master' into conflict-3300-r2

faa38f7

merge master (#3312) into reasoning-flush-fold — clean, no conflict

714db14

ranxianglei mentioned this pull request Oct 16, 2026

[cache] Similar cache seams still detectable after #1548 / #1551 / #1554: v0.1.197, 21 samples / 1.14M tok | [cache] #1548 / #1551 / #1554 之后仍可测到同类缓存接缝：v0.1.197，21 样本 / 1.14M tok #3307

Open

Merge remote-tracking branch 'origin/2026-10-15_reasoning-drop-attrib…

2652c4f

…ution' into 2026-10-16_reasoning-flush-fold

ework-agent and others added 4 commits October 16, 2026 09:53

Merge remote-tracking branch 'origin/2026-10-16_reasoning-flush-fold'…

a13515f

… into 2026-10-16_reasoning-flush-fold

merge: master into reasoning-flush-fold (remove-absorb follows master…

74d53cd

…; flush docs kept; goldens regen)

test: regen storage-render goldens on merged tree

0858d4e

Merge commit 'd8c0e50e7' into 2026-10-16_reasoning-flush-fold

0ec0bf1

ranxianglei mentioned this pull request Oct 16, 2026

197-master range review | 197-master区间审查 #3331

Closed

ranxianglei mentioned this pull request Oct 20, 2026

[PR] fix: snapshot-render — covered rows no longer accept signature binds (#4052) #4057

Merged

Navigation Menu

Repository navigation

[PR] fix: compressed thinking reclamation (#651) default changed to be uniformly deactivated with collapse, eliminating the once-per-turn cache seam (Refs #3198) | [PR] fix: 压缩思考回收(#651)默认改为随折叠统一下线,消除每轮一次的缓存接缝 (Refs #3198) - #3311

ranxianglei commented Oct 15, 2026

Uh oh!

github-actions Bot commented Oct 15, 2026 •

edited

Loading

Uh oh!

ranxianglei commented Oct 15, 2026

Uh oh!

ranxianglei commented Oct 15, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

ranxianglei commented Oct 15, 2026

坏了什么

根因

修法(flush:"fold" 默认)

依赖(stack,合并顺序)

config surface

kernel-change

证据

Uh oh!

github-actions Bot commented Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📦 Built Package Artifact

Option A — Install this exact build (recommended)

Option B — Download artifact

Uh oh!

ranxianglei commented Oct 15, 2026

审核做了什么(独立于前两轮 review)

结构化八问

Uh oh!

ranxianglei commented Oct 15, 2026

真相:stack merge 误丢 #3300 的两个 commit

第三个缺陷:legend 行本身会炸旧载荷(两个 PR 都有)

已推送的修复

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

ranxianglei commented Oct 16, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

github-actions Bot commented Oct 15, 2026 •

edited

Loading