Why

When the model fans out into parallel tool calls, today's UI shows only mechanical information — which tool ran, with what argument, whether it succeeded. There is no synthesis of why the batch was run.

• Compact mode (Ctrl+O) — the group collapses to a single Tool × N header plus the last tool's description. For Grep × 3 + Read × 2 you only see the tail tool's name; the intent is lost entirely. This is the primary target of the PR.
• Narrow / SDK UIs (mobile, sidebars, pending SDK consumers) — the one-line cell is the whole signal, and the generic header says almost nothing. Same motivation as above.
• Full mode (ui.compactMode: false, the default) — individual tool lines are already visible, so the improvement is scenario-dependent: significant for batches that are large or heterogeneous, marginal for small same-type batches where the tool names already tell the whole story. See When the label actually helps for the honest breakdown. Full-mode rendering exists so the feature does not silently disappear for users who leave compact mode off.

A short semantic label after each batch — "Read 4 text files", "Searched in auth/", "Fixed NPE in UserService" — closes the gap where it actually exists without hiding the tool details.

What

After each tool batch finalizes, fire a fast-model call that returns a short git-commit-subject-style label. Both full and compact modes now surface the label so the feature works under the default ui.compactMode: false:

Full mode (default) — label appears inline below the tool group:

╭──────────────────────────────────────────────╮
│ ✓  ReadFile a.txt (pages 1)                  │
│ ✓  ReadFile b.txt (pages 1)                  │
│ ✓  ReadFile c.txt (pages 1)                  │
│ ✓  ReadFile d.txt (pages 1)                  │
╰──────────────────────────────────────────────╯

 ● Read 4 text files

Compact mode — label replaces the generic Tool × N header:

╭──────────────────────────────────────────────╮
│✓  Read txt files  · 4 tools                  │
│Press Ctrl+O to show full tool output         │
╰──────────────────────────────────────────────╯

How

• Generation runs fire-and-forget from handleCompletedTools in useGeminiStream, keyed on the turn's abort signal. It overlaps with the next turn's API stream so the ~1s fast-model roundtrip adds no perceived latency.
• On resolve, a tool_use_summary history item is added with the label and the batch's precedingToolUseIds. The history item appends cleanly to Ink's append-only <Static>, so the label shows up even though the tool_group itself is already frozen.
• In full mode, HistoryItemDisplay renders the tool_use_summary as its own dim ● <label> line — natural flow below the tool group.
• In compact mode, MainContent builds a callId → summary lookup and passes the label to CompactToolGroupDisplay as a compactLabel prop. The component renders Summary · N tools in place of the default header. The standalone summary line is hidden in compact mode to avoid duplication.
• mergeCompactToolGroups treats tool_use_summary as hidden-in-compact so two consecutive batches still merge across it; the merged group takes the first contributing batch's label.
• Force-expand groups (errors, confirmations, focused shell, user-initiated) bypass the compact path entirely — same as before — and their inline summary line still renders in full mode.

When the label actually helps

The benefit is not uniform across all batches — being honest about where this earns its keep:

The Read × 4 example used in this PR's screenshots and the tmux transcript is deliberately in the low-benefit cell — the label ("Read 4 text files") is almost redundant with the individual tool lines. The point of showing it there was to prove the plumbing works end-to-end under a reproducible setup, not to argue that it is especially valuable for that specific shape. Users whose workflows are dominated by small same-type batches and who are running in full mode may want to set experimental.emitToolUseSummaries: false to avoid the per-batch cost — the escape hatch is part of the design.

Compact mode (and anything downstream of the SDK) is where this PR pays off most consistently; the full-mode inline render exists so the feature does not silently disappear when a user toggles ui.compactMode: false (the default), not because it's revelatory for every batch.

Configuration

Compared to the upstream inspiration, which only exposes a same-named env gate (no settings layer, default off), this PR adds a persistent settings toggle and defaults on — rationale and trade-offs covered in the design doc (see Deviations).

Failure modes (all silent)

• No fastModel configured → skipped, no history item added.
• Aborted turn → the generation promise drops on the floor; the summarySignal.aborted check prevents stale addItem.
• API error / empty model output / rejected label (prefixed Error:, I cannot …, etc. — filtered by cleanSummary) → no history item, UI shows the default view.

Cost / compat

• One fast-model call per qualifying tool batch. Prompt is ~300 input tokens × (number of tools) capped at 300 chars/field, output is ~20 tokens. At typical fast-model pricing, roughly $0.001 per batch.
• tool_use_summary items are not persisted via ChatRecordingService; resuming a session loses labels but tool groups render normally (no user-visible difference beyond label absence).
• Non-interactive CLI paths (runNonInteractive) are unchanged. The trigger lives in the interactive stream hook only.
• No breaking changes. Existing users see labels appear automatically if they have a fastModel set; others see the current behavior unchanged.

Not in scope

The message factory createToolUseSummaryMessage and ToolUseSummaryMessage type are exported from core so a future PR can wire them into the SDK stream / non-interactive output. This PR only consumes the generated summary in the interactive CLI.

Live tmux verification

Reproducible end-to-end proof against a real fastModel. Both runs use the same 4 scratch files; only ui.compactMode differs.

Setup (both runs)

mkdir -p /tmp/qwen-summary-test
cd /tmp/qwen-summary-test
printf 'line one\nline two\n'                 > a.txt
printf 'hello from b\n'                       > b.txt
printf 'contents of c\n'                      > c.txt
printf 'd has four lines\nfoo\nbar\nbaz\n'    > d.txt

# project-scoped settings (global settings.json provides fastModel: gpt-5.4)
mkdir -p .qwen
cat > .qwen/settings.json <<JSON
{ "ui": { "compactMode": false },
  "experimental": { "emitToolUseSummaries": true } }
JSON

# launch inside a tmux pane
tmux new-session -d -s qwentest -x 220 -y 50 -c /tmp/qwen-summary-test
tmux send-keys -t qwentest "node /path/to/qwen-code/packages/cli" Enter
# (wait for banner, then send the prompt and an Enter):
tmux send-keys -t qwentest "Read a.txt b.txt c.txt d.txt using pages=1 then summarize in one sentence." Enter
tmux send-keys -t qwentest Enter

Full mode (default — ui.compactMode: false)

Raw tmux capture-pane -p output, turn end state:

  > Read a.txt b.txt c.txt d.txt using pages=1 then summarize in one sentence.

  ✦  think I need to figure out how to handle file reading. For a trivial single task, it might not be
    necessary to use todo. Now, I want to read absolute files, and I'm wondering if I can use the pages
    argument for PDFs, although I might face errors or it could be ignored. The user mentioned using
    pages = 1, so I should comply, just in case. Plus, I need to read four files, maybe in parallel.


  ╭──────────────────────────────────────────────────────────────────────────────────────────────────────╮
  │ ✓  ReadFile a.txt (pages 1)                                                                          │
  │                                                                                                      │
  │ ✓  ReadFile b.txt (pages 1)                                                                          │
  │                                                                                                      │
  │ ✓  ReadFile c.txt (pages 1)                                                                          │
  │                                                                                                      │
  │ ✓  ReadFile d.txt (pages 1)                                                                          │
  ╰──────────────────────────────────────────────────────────────────────────────────────────────────────╯

   ● Read 4 text files

  ✦ 四个文件分别包含一些简短文本：a.txt 有两行普通内容，b.txt 和 c.txt 各有一行说明文字，d.txt 则有
    四行以 "d has four lines" 开头的内容。

Key signal: the dim ● Read 4 text files line below the tool group — emitted after tools complete, flowed in naturally once the fast-model call resolved. This is the label reviewers should look for.

Compact mode (ui.compactMode: true, or toggle with Ctrl+O)

Same prompt, compactMode: true. Raw capture (the earlier retry batch stays force-expanded because it contains errors; the successful retry collapses to a single compact row):

  ╭──────────────────────────────────────────────────────────────────────────────────────────────────────╮
  │ x  ReadFile {"file_path":".../a.txt", ... , "pages":""}                                              │
  │    Invalid pages parameter: ''. Use formats like '5' or '1-10'.                                      │
  │ x  ReadFile {... b/c/d ...}                                                                          │
  │    ⚠️ RETRY LOOP DETECTED: ...                                                                        │
  ╰──────────────────────────────────────────────────────────────────────────────────────────────────────╯

  ╭──────────────────────────────────────────────────────────────────────────────────────────────────────╮
  │✓  Read txt files  · 5 tools                                                                          │
  │Press Ctrl+O to show full tool output                                                                 │
  ╰──────────────────────────────────────────────────────────────────────────────────────────────────────╯

  ✦ 四个文件分别包含：a.txt 的两行示例文本、b.txt 的一行问候语、c.txt 的一行内容说明，以及 d.txt 的
    四行简单占位文本。

Key signals:

• The second box's header is the generated label Read txt files, not the generic ReadFile × 5.
• Error group is untouched (force-expand bypass — same as before).
• 5 tools rather than 4 because mergeCompactToolGroups folded the earlier first attempt in; that's expected merge behavior and unaffected by this PR.

Files

Docs

• docs/users/features/tool-use-summaries.md — user-facing guide (rendering, triggers, fast-model requirement, cost, failure modes).
• docs/users/configuration/settings.md — register experimental.emitToolUseSummaries alongside other fast-model-driven settings.
• docs/users/features/_meta.ts — add the new feature page to the sidebar.
• docs/design/tool-use-summary/tool-use-summary-design.md — design doc (competitive analysis, flow, key files, Ink <Static> append-only rationale, deviations, limitations, future work).

Core

• packages/core/src/services/toolUseSummary.ts — system prompt, truncateJson, cleanSummary, generateToolUseSummary, createToolUseSummaryMessage factory + ToolUseSummaryMessage type.
• packages/core/src/config/config.ts — getEmitToolUseSummaries() with env override.

CLI

• useGeminiStream.ts — fires generation in handleCompletedTools, lifts history to a ref so the callback stays stable.
• HistoryItemDisplay.tsx — renders tool_use_summary as a standalone inline ● label line (gated on !compactMode).
• MainContent.tsx — callId → summary lookup, passes compactLabel down to HistoryItemDisplay for the compact-mode header replacement.
• ToolGroupMessage / CompactToolGroupDisplay — propagate and render the compact-mode label.
• mergeCompactToolGroups.ts — treat tool_use_summary as hidden-in-compact.
• settingsSchema.ts — experimental.emitToolUseSummaries, default true, visible in settings dialog.

Test plan

• toolUseSummary.test.ts — 27 tests: truncation, cleaning (including CJK, error-message rejection, length cap), UUID + timestamp, model invocation + prompt contents, abort handling, JSON serialization edge cases.
• useGeminiStream.test.tsx — 4 new integration tests: disabled gate / missing fast model / success path / empty model result, each asserting on whether addItem saw a tool_use_summary payload.
• CompactToolGroupDisplay.test.tsx — 5 tests for the label-vs-default rendering branches (plus 3 pre-existing timeout tests from feat(cli): combine elapsed + timeout in shell time indicator QwenLM/qwen-code#3512).
• HistoryItemDisplay.test.tsx — new test verifying tool_use_summary renders as a dim ● <label> line in full mode.
• mergeCompactToolGroups.test.ts — 1 new case: two batches separated by a tool_use_summary still merge into one group.
• Full core suite: 6036 tests pass.
• Full CLI suite: 4384 tests pass.
• tsc --noEmit on both packages: clean.
• Live tmux verification in full + compact mode against a real fastModel (dashscope gpt-5.4) — transcripts above.

CodeQL

cleanSummary's quote-strip regex was flagged as polynomial ReDoS because the input is LLM-produced. Fix in 2nd commit bounds the quantifier to {1,10} (ten opening/closing quotes is well past anything a real label produces); alert auto-closed as fixed.