fix(cli): prefer per-session cached token count in /context - #12066

Review — approved

核对基线：head dc5a7bc6（base 9dd689f048，3 个文件，+68/-11）。

Scope

• llm-chat.ts：新增 lastCachedContentTokenCount 字段，始终镜像 usage metadata（含零值），新增 getLastCachedContentTokenCount() 方法，retain/restore 路径同步
• contextCommand.ts：优先读 activeChat.getLastCachedContentTokenCount()，仅在无 chat 时 fallback 到全局 singleton
• contextCommand.test.ts：回归测试——foreign global cache 64,653 不能把 65,267 token 会话的 messages 压到 ~614

结论：无阻塞问题

1. 与 #5763 的修复模式一致：lastPromptTokenCount 已做了相同的 per-chat 镜像，本次扩展到 cachedContentTokenCount
2. 零值镜像正确：旧代码 if (cachedContentTokenCount && ...) 跳过零值，导致会话 B 保留会话 A 的缓存计数。新代码无条件赋值，零值也是有效数据
3. telemetry 仍同步更新：telemetryService?.setLastCachedContentTokenCount(...) 保持全局镜像（其他消费者仍可用），但 /context 不再依赖它
4. 可选链 ?. 保护测试 mock：activeChat?.getLastCachedContentTokenCount?.() 兼容不提供此方法的 mock 对象，生产环境 LlmChat 始终有此方法
5. retain/restore 路径覆盖：adoptTokenCountsForRoute 恢复 retained.cachedContentTokenCount，路由切换不会丢 per-session 计数

Code LGTM — verified the per-session cached-count fix end to end:

• lastCachedContentTokenCount is now mirrored on the chat on every usage report (including zero, deliberately), so a later /context in this session cannot inherit a foreign session's cache hit.
• Route retain/restore/reset all carry the per-chat value; the previous snapshot code read the process-global singleton, which was itself a cross-session leak — good catch fixing that at the same time.
• contextCommand falls back to the global only when no chat exists, with optional chaining for older chat objects.
• The test's behavioral assertion (foreign 64_653 must not collapse messages toward ~614) proves the fix at the observable level rather than mocking internals.

Note: the open CHANGES_REQUESTED from qwen-code-ci-bot is the PR-body template gate (stage=1a), not a code issue — it stays until the body is restructured per the template (## What this PR does / ## Why / ## Reviewer Test Plan / ## Risk & Scope / ## Linked Issues + Chinese details). Once the body matches, the bot will run its full gate. My approval covers the code only.

Critical-only review at dc5a7bc6, base 9dd689f0.

Verdict: APPROVE — no merge-blocking correctness, security, data-loss, regression, or compatibility defect found.

Historical blocking issues

The outstanding CHANGES_REQUESTED on this PR is a PR-template/description request, not a code defect, and the body now carries the template's sections. No code-level blocking issue has ever been raised against this head: the follow-up review at this same commit records "no blockers" with all four of its findings at Suggestion severity, and there are no review threads claiming a correctness, security, data-loss, regression, or compatibility defect. The four open threads are all Suggestions, which are out of scope for this pass and do not gate approval.

What I verified against the head code

The value written into the new slot can never be undefined or non-finite. cachedContentTokenCount at the usage site comes from coerceUsageCount, which returns a number on every path — it accepts only a finite value >= 0 and coerces anything else to 0 with a warning. So the change from a truthiness-guarded telemetry write to an unconditional this.lastCachedContentTokenCount = cachedContentTokenCount cannot introduce undefined or NaN into a number-typed field, and the retained record and usage record both declare the field as number.

The unconditional mirror is the actual fix, and it is safe. Writing zero as well as nonzero is what stops a later /context in this session from subtracting another session's cache hit. On the consumer side apiCachedTokens is only used under if (apiCachedTokens > 0), so a legitimate zero now falls through to the scaledOverhead branch instead of applying a foreign cache figure.

No negative or inverted tier can result. The single subtraction is messagesTokens = Math.max(0, totalTokens - apiCachedTokens), clamped at zero. Even in the stale-count case the open Suggestion thread describes — where a non-API writer rewrites the prompt count while the cached count still describes an earlier prompt — the worst outcome is a messages figure floored at 0, not a negative or NaN value. The headline total and tier derive from apiTotalTokens, which this PR does not change. That same skew already existed at base, where the global cached count was mixed with a per-chat total; sourcing both from the same chat is what restores the cached <= prompt invariant the API guarantees.

The new getter adopts the route correctly when called with no argument. collectContextData calls activeChat?.getLastCachedContentTokenCount?.(), and adoptTokenCountsForRoute resolves an absent key via targetRouteKey ??= this.currentRouteKey() after its zero-count fast path. The call therefore behaves like the sibling prompt-count read directly above it rather than defaulting to a wrong route.

Slot lifecycle is complete across all three sites. The retain path records cachedContentTokenCount: this.lastCachedContentTokenCount, the restore path assigns it back from the retained record, and the route-reset path zeroes it alongside lastPromptTokenCount and lastOutputTokenCount. There is no path that restores or resets the prompt count while leaving the new slot pointing at a foreign route's value.

The optional-call fallback preserves the previous behaviour when no chat exists. activeChat?.getLastCachedContentTokenCount?.() ?? uiTelemetryService.getLastCachedContentTokenCount() falls back to the process-global singleton only when there is no active chat, which is the pre-existing read, and ?? rather than || means a legitimate per-session 0 is not discarded in favour of the global value.

CI on this head is green across all 205 checks with no failures, including the ubuntu test lane, lint and static checks, and the no-AK integration lane.

Reviewed the current head d49dcae2b3 (base 9dd689f048). The second commit only adds the zero-cache regression case; the two production files are byte-identical to dc5a7bc6. The new test is useful and correctly pins ?? rather than ||.

I found no additional diff-level defect beyond the four existing open threads, but I would not treat all of them as cosmetic:

• R1-3 is reproducible on this exact head with a real LlmChat. After a streamed usage report writes prompt=65,267 / cached=64,653, setLastPromptTokenCount(10,000) leaves cached at 64,653, so the /context formula yields messages = 0. Repeating with /compress-fast produced total=62,767 / cached=64,653, again yielding messages = 0. This existed in the single-session baseline, but the new per-chat source makes the stale value stable instead of allowing another daemon session to overwrite it accidentally. The new cached slot should be invalidated alongside non-API prompt-count writes, and the hard-rescue snapshot/rollback should carry it deliberately.
• R1-1 therefore remains important: the current CLI tests mock the getter and do not exercise the new core slot, zero reset, or route retain/restore lifecycle.
• R1-2 is still accurate; the retain-path comments describe the removed telemetry read.
• R1-5 is still unaddressed. More fundamentally, a published deferred/provisional serve session can have no initialized chat, and that path still reads the process-global prompt and cached counts. That is pre-existing behavior, not a regression from this PR, but it means the session-ownership fix is incomplete during bootstrap.

All completed CI checks on this head are green. The remaining CHANGES_REQUESTED review is the earlier PR-template gate; the body now follows the template, so that review state appears operationally stale rather than a current code objection.

LGTM. Per-chat lastCachedContentTokenCount plus ?? (not ||) on the /context read stops a foreign session's cache hit from collapsing this session's messages. The 0 vs global-64653 cases are load-bearing.

APPROVE

核对基线：head 32805a7954bfbbabc4d986a344f6a8553e747ff5（base 9dd689f048，3 commits，4 个文件 +214/-56）。required 档全部完成且成功：Test (ubuntu-latest, Node 22.x)、Lint & Static、Integration Tests (no-AK, No Sandbox)、web-shell E2E Smoke、TUI parity snapshots、OpenTUI no-flicker gate。

上一轮那份「核心侧失效纪律不完整 + 核心侧无测试」的意见，在这两个 commit 里已经落地，我是按 head 的代码逐条复验的，不是看 thread 的 resolved 标记：

• setLastPromptTokenCount（llm-chat.ts:2595-2600）与 compression 成功路径（:2886-2894）现在成对清零 lastCachedContentTokenCount 并同步 telemetry 镜像；hard-rescue 回滚把 cached 也纳入了快照与恢复（:3139-3145、:3243-3266）。读侧 contextCommand.ts:313-314 是 Math.max(0, total - cached)，这正是我之前担心的「压缩后 messages 塌成 0」的那条路径。
• seedResumeTokenCounts（:2624-2644）没清 cached 是对的：它只在 startChat 之后、刚建好的 chat 上调用（client.ts:595-604、:625-632），槽按构造就是 0，不存在外来值。
• retainCurrentTokenCounts 上方那条描述已删表达式的过时注释也去掉了。
• 核心侧补了 llm-chat.test.ts：通过 sendMessageStream 喂真实 usageMetadata 再断言 chat.getLastCachedContentTokenCount()（存 42 → 换 route 归 0 → 换回仍 42 → 缺字段清 0），另有一条专测非 API 写入点的清零。这是真正跑到 LlmChat 的用例，不是 cli 侧 vi.fn() 桩。

我自己另核过三点，都成立：写入值恒为数字（llm-chat.ts:6007 的 coerceUsageCount），所以读侧 ?? 全局 不会被 undefined 悄悄打开；GeminiChat 就是 LlmChat 的导出别名（llm-chat.ts:6760），新 getter 不是空挂的可选调用；total 与 cached 两条读法的 route 参数一致，配对的仍是同一条 route。

记录（不阻塞）：R1-5 与 R2-1 两条在 head 上仍开着——我确认 contextCommand.test.ts 里没有 ci-bot 建议的 expect(data.breakdown.messages).toBeLessThan(data.totalTokens)，也没有「无 chat 且全局 cached 非 0」的用例，所以 contextCommand.ts:313 的 > 写成 >=、或回退腿被换成 ?? 0，都不会有测试变红。两处各是一行断言的事，属于变异加固而非现存缺陷（生产行为我上面已核过是对的），按本项目约定缺测试记 Suggestion。建议直接采纳 ci-bot 给的两条断言收口。