@qwen-code /triage

Thanks for the PR!

Template looks good ✓

On direction: this is a real bug — qwen serve sessions sharing a process-global token count means /context and /context-usage report wrong numbers for every session except the most recent one. The per-session chat already tracks the correct value, so reading it there is the obvious fix. Clearly aligned with the project. CHANGELOG has no direct reference to this specific issue, but multi-session serve correctness is squarely in scope.

On approach: the change is minimal — 12 lines of production code, 42 lines of tests covering both the happy path (per-session chat initialized) and the fallback (not yet initialized). No scope creep, no drive-by refactors. The optional chaining on config.getGeminiClient?.() and isInitialized?.() is appropriate defensive coding since the Config type parameter in collectContextData is imported and may be implemented by different classes. The comment explaining why cached-content tokens stay on the global singleton is helpful context for future readers.

Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

Code Review

Clean fix. The approach — prefer per-session chat token count, fall back to global singleton — is the obvious and correct solution. I would have written the same code.

Reviewed the production change in contextCommand.ts:

• Optional chaining on config.getGeminiClient?.() and geminiClient?.isInitialized?.() is appropriate — Config is a broad type and not every implementation guarantees these methods.
• The getChat() call is safe because it's guarded by the isInitialized() check, which tests this.chat !== undefined (the same condition getChat() throws on).
• Cached-content tokens correctly stay on the global singleton, with a clear comment explaining why.

No correctness issues, no security concerns, no regressions. The diff is minimal and focused — exactly what the stated goal needs, nothing more.

Tests

Both new tests pass (9/9 total in contextCommand.test.ts):

• Per-session path: verifies getChat().getLastPromptTokenCount() wins over the global 999K value, and that the tier reflects the per-session 50K (safe, not hard).
• Fallback path: verifies the global singleton is used when isInitialized() returns false and getChat() throws.

 ✓ src/ui/commands/contextCommand.test.ts (9 tests) 30ms

 Test Files  1 passed (1)
      Tests  9 passed (9)

Real-Scenario Testing

This bug only manifests in qwen serve with multiple concurrent sessions — the global singleton stores whichever session most recently completed a turn, so all other sessions report wrong numbers. A single-session CLI /context call produces identical output before and after this fix (the PR description explicitly notes this). Reproducing the bug in tmux would require standing up two serve sessions with real LLM API calls and comparing their /context-usage responses, which isn't feasible in this CI environment.

Verified the dev build runs correctly:

$ npm run dev -- -p 'what is 2+2? reply with just the number'
4

The unit tests adequately cover the logic change. The serve-mode integration scenario is best verified manually per the Reviewer Test Plan in the PR description.

— Qwen Code · qwen3.7-max

This is a textbook bugfix PR: real bug, minimal change, clear tests, honest description of tradeoffs.

The uiTelemetryService singleton was always going to be wrong in serve mode — it's a process-level object pretending to be a session-level metric. The fix reads from the right place (the per-session chat) with a sensible fallback for the uninitialized case. The cached-content token read correctly stays on the global singleton with a comment explaining why, which is the kind of future-reader thinking I want to see.

The diff is 12 production lines. No abstractions, no helper functions, no "while I'm here" refactors. Two focused tests that prove the fix works and that the fallback isn't broken. If every PR looked like this, maintainers would have a lot less to do.

LGTM. ✅

— Qwen Code · qwen3.7-max

✅ Local verification — per-session /context token total in qwen serve

Verified end-to-end on a real built daemon (npm ci && npm run build, head df30f5d03, isolated worktree, Linux). Booted qwen serve under tmux against a deterministic mock OpenAI server, drove it with the real TypeScript SDK DaemonClient, and A/B'd against the merge-base 83caca65e.

Setup

• Daemon — qwen serve --workspace <ws> --port … --token …; env points the model at a mock OpenAI server. The bridge runs one qwen --acp child per workspace and multiplexes all sessions onto it (bridge.ts), so uiTelemetryService is genuinely shared across sessions — exactly the condition Multi-session /context-usage reports a process-global token count instead of the per-session value #5763 describes.
• Mock — reports usage.prompt_tokens = N parsed from a TOKENS=N marker in the prompt, so each session records a distinct per-session total.
• Two sessionScope:'thread' sessions. A completes its turn first (records 11111), then B last (records 222222) so the process-global singleton ends on B's value.

1) Serve GET /session/:id/context-usage — A/B

Before — both sessions report the last-completed-turn's global value; session A's own 11111 is lost:

[A] context-usage: totalTokens=222222 tier=hard
[B] context-usage: totalTokens=222222 tier=hard
RESULT: globalBugReproduced=true, perSessionCorrect=false

After — each session reports its own value (and its own tier):

[A] context-usage: totalTokens=11111  tier=safe
[B] context-usage: totalTokens=222222 tier=hard
RESULT: perSessionCorrect=true, globalBugReproduced=false

2) CLI /context unchanged (test-plan step 5)

Single TUI session, prompt TOKENS=12345, then /context:

█ Used                12.3k tokens (9.4%)
  Current tier                  safe

Headline total (12.3k = 12345) is the per-session chat value — single-session CLI /context is behaviorally correct/unchanged (the global and chat values coincide there).

Verdict

The fix holds end-to-end on a real daemon: concurrent serve sessions each report their own /context-usage prompt-token total and tier instead of the last-completed-turn's global value, while single-session CLI /context is unchanged. LGTM for merge.

_{Verified by @wenshao on Linux via a real built daemon + mock OpenAI server driven over the TS SDK (head df30f5d03 vs merge-base 83caca65e).}

✅ Local runtime verification (real qwen serve daemon via tmux + deterministic A/B)

Built two real bundles from this PR's head (df30f5d03) — one with the fix, one with contextCommand.ts reverted to the merge-base — and verified collectContextData both through a live qwen serve daemon (tmux, mock OpenAI model) and a deterministic unit A/B.

Architecture (the bug condition, confirmed)

qwen serve --http-bridge binds one workspace and multiplexes N sessions onto a single qwen --acp child (confirmed: one --acp child process, QwenAgent holds a Map<string, Session>). Every session's GeminiChat lives in that one process and mirrors its prompt-token count to the shared module-level uiTelemetryService singleton — so the singleton holds whichever session most recently completed a turn (#5763).

Cross-session divergence — deterministic A/B (authoritative)

packages/cli/src/ui/commands/contextCommand.test.ts reproduces the exact daemon condition: a "wrong" session's global value (999_000) vs this session's chat value (50_000).

• PR → both new tests pass.
• base → the per-session test fails: expected "spy" to be called at least once — base reads uiTelemetryService directly and never consults the per-session chat, so a stale cross-session total (and a wrong hard tier) leaks through.
• Full contextCommand.test.ts on PR: 9/9, no regression.

Live daemon E2E (the fix is wired into the real route)

Real qwen serve (PR bundle, tmux) + mock model that returns a controllable usage.prompt_tokens:

POST /session/:id/prompt  {prompt:[{type:"text",text:"PTOK=50000 hi"}]}
  → mock reports prompt_tokens=50000
GET  /session/:id/context-usage
  → usage.totalTokens = 50000, breakdown.currentTier = "safe"

This exercises the full path GET /session/:id/context-usage → bridge → ACP child → collectContextData → geminiClient.getChat().getLastPromptTokenCount() — i.e. the fix is live on the route that actually mattered (#5763).

Single-session parity (PR claim: CLI /context unchanged)

Same prompt on the base daemon vs the PR daemon → both report totalTokens=50000, tier=safe. In a single session the chat value and the global coincide, so single-session /context behavior is unchanged, as the PR states.

Note on a live 2-session A/B

A single daemon can't host two concurrent distinct sessions over HTTP (it binds one workspace and coalesces same-cwd POSTs; a foreign cwd returns workspace_mismatch; fork is an agentic sub-agent, too noisy to measure cleanly). The two-session bleed is therefore reproduced deterministically by the unit A/B above (which models the shared-singleton condition exactly), while the live daemon E2E confirms the route reads the per-session chat. Together they cover both the bug's manifestation and the fix's wiring.

Verdict

The fix sources the /context headline total from the per-session chat (with a correct fallback to the global when no chat exists yet), proven by a deterministic A/B and confirmed live on the real qwen serve route, with no single-session regression. LGTM. ✅

POST /session/:id/prompt  {prompt:[{type:"text",text:"PTOK=50000 hi"}]}
  → mock 返回 prompt_tokens=50000
GET  /session/:id/context-usage
  → usage.totalTokens = 50000, breakdown.currentTier = "safe"

✅ Independent re-verification — the live 2-session serve A/B is reproducible

Re-ran this on a fresh build to settle the one point the two verification notes above disagree on: whether a single daemon can host two concurrent distinct sessions and show the cross-session leak live. It can — via the SDK's documented sessionScope:'thread' override — so the #5763 bleed reproduces live on the real GET /session/:id/context-usage route, not only in the unit A/B.

Setup

• Fresh worktree at head df30f5d0, npm ci && npm run build, Linux.
• Real qwen serve --workspace <ws> --port 0 --token … --hostname 127.0.0.1 booted in tmux; model env points at a local fake OpenAI server.
• One daemon ⇒ one qwen --acp child, both sessions multiplexed onto it, so they share the module-level uiTelemetryService singleton — the exact Multi-session /context-usage reports a process-global token count instead of the per-session value #5763 condition.
• Fake server returns usage.prompt_tokens/total_tokens keyed off a marker in the prompt: A → 11111, B → 77777.
• Driver (real TS SDK DaemonClient): create A (sessionScope:'thread'), create B (sessionScope:'thread') → two distinct session IDs; prompt A, then prompt B (so the shared singleton ends on B's 77777); then GET …/context-usage for both.
• A/B toggles only contextCommand.ts between the PR (HEAD) and its parent ac1e4737 (pre-fix), rebuilding just @qwen-code/qwen-code — identical daemon harness on both runs.

Result — GET /session/:id/context-usage → usage.totalTokens

Raw driver output (RESULT: lines, abbreviated):

AFTER : {"distinctSessions":true,"observed":{"A_totalTokens":11111,"B_totalTokens":77777},"A_isolated":true, "A_leaked_B":false}
BEFORE: {"distinctSessions":true,"observed":{"A_totalTokens":77777,"B_totalTokens":77777},"A_isolated":false,"A_leaked_B":true}

The discriminator is session A: before the fix it reports 77777 (B's count — the most-recently-completed turn); after the fix it reports its own 11111. B reads 77777 either way (correct by luck, since it ran last).

Note (reconciling the two notes above)

Two concurrent distinct sessions on one daemon are reachable — via POST /session with sessionScope:'thread' (the SDK's per-request override, CreateSessionRequest.sessionScope: "forces a distinct session for this call"). No workspace_mismatch, no fork sub-agent, no same-cwd coalescing. So the cross-session bleed is observable live on the route that actually mattered, complementing the deterministic unit A/B.

Verdict

Confirms the fix end-to-end on a real daemon: concurrent serve sessions each report their own /context-usage prompt-token total instead of the last-completed-turn's global value. LGTM for merge.