Problem
Automatic context compaction (65% trigger) runs synchronously inside the turn loop — up to 3 summarizer attempts + a re-compaction pass, each a non-streaming provider.complete over most of the window. The code itself documents the window: "next 10-60s produce zero streaming chunks" (compact_context, compaction.rs). Worst case is minutes of total silence on the chat surface.
During that window Telegram shows nothing textual: the ProgressEvent::Compacting arms in progress.rs + resume.rs only refresh the typing action. The other channels already surface it — Slack/Discord/WhatsApp all emit "⏳ Compacting context..." — Telegram does not. The only life signs are the typing dots and the frozen flow block's ticking clock, which reads to users as a stuck session. In production this matters more now because compaction can genuinely stall (#1255): a visible "compacting" signal is the difference between "working as expected" and "dead".
History — the gap was seen before and left open
#527 (closed, fix 35c5891f) documented the same compaction silence on Telegram and fixed the claude-cli "Working on" header, but explicitly closed without a visible compaction message ("no separate visible compaction message was added, per the request"). The 4s typing pinger spans the window, but there is still no textual signal anywhere on the Telegram flow surface. This issue asks to close that gap.
Proposed design (two slots, both wanted)
A — merged-footer segment. While compaction runs, the live footer (the line under the flow block: ⚙️ <activity> • <working-on> • N tool calls • ctx • ⏱ M:SS) leads with the compaction state in place of the activity segment:
⏳ Compacting context (68% full) • 14 tool calls • ⏱ 3:42
It disappears by itself on the next tick after compaction finishes — no cleanup event needed.
B — standalone entry in the processing log. One line inside the expandable flow block, same shape as the existing RetryAttempt / ProviderSwitched intermediate entries:
⏳ Compacting context — 68% full (≈10–60s)…
plus an optional completion pair when the post-compaction count lands:
✅ Context compacted (68% → 26%)
Slot B also covers the "compaction fires before any flow block exists" case (turn start, no tools yet): the entry simply opens the block, exactly like the first tool line does. And because Telegram's collapsed expandable shows header + most recent content line, the entry stays visible even collapsed.
Implementation seams (verified at a487008)
usage_pct is already computed in enforce_context_budget right before the event fires — ProgressEvent::Compacting is payload-free today and needs one field (usage_pct: f64); mechanical update of the ~6 match arms (slack/whatsapp/discord/telegram progress+resume/cli/tui).ProgressEvent::CompactionSummary { summary } already exists and has TUI/CLI consumer arms but is never emitted — emitting it on successful compaction gives the completion line its → 26% number with no new event type.- Rendering is Telegram-side only (
progress.rs / resume.rs / flow.rs / flow_chrome.rs); the agent side gains only the event payloads.
Filed under owner sanction for the compaction class (field report #1255 on this tracker; follow-ups on that class may continue upstream). Related: #1255 (stall watchdog — the reason the signal matters), #527 (history), #909 (pressure nudge — model-side only, invisible to the user).
Problem
Automatic context compaction (65% trigger) runs synchronously inside the turn loop — up to 3 summarizer attempts + a re-compaction pass, each a non-streaming
provider.completeover most of the window. The code itself documents the window: "next 10-60s produce zero streaming chunks" (compact_context, compaction.rs). Worst case is minutes of total silence on the chat surface.During that window Telegram shows nothing textual: the
ProgressEvent::Compactingarms inprogress.rs+resume.rsonly refresh the typing action. The other channels already surface it — Slack/Discord/WhatsApp all emit "⏳ Compacting context..." — Telegram does not. The only life signs are the typing dots and the frozen flow block's ticking clock, which reads to users as a stuck session. In production this matters more now because compaction can genuinely stall (#1255): a visible "compacting" signal is the difference between "working as expected" and "dead".History — the gap was seen before and left open
#527 (closed, fix
35c5891f) documented the same compaction silence on Telegram and fixed the claude-cli "Working on" header, but explicitly closed without a visible compaction message ("no separate visible compaction message was added, per the request"). The 4s typing pinger spans the window, but there is still no textual signal anywhere on the Telegram flow surface. This issue asks to close that gap.Proposed design (two slots, both wanted)
A — merged-footer segment. While compaction runs, the live footer (the line under the flow block:
⚙️ <activity> • <working-on> • N tool calls • ctx • ⏱ M:SS) leads with the compaction state in place of the activity segment:It disappears by itself on the next tick after compaction finishes — no cleanup event needed.
B — standalone entry in the processing log. One line inside the expandable flow block, same shape as the existing
RetryAttempt/ProviderSwitchedintermediate entries:plus an optional completion pair when the post-compaction count lands:
Slot B also covers the "compaction fires before any flow block exists" case (turn start, no tools yet): the entry simply opens the block, exactly like the first tool line does. And because Telegram's collapsed expandable shows header + most recent content line, the entry stays visible even collapsed.
Implementation seams (verified at a487008)
usage_pctis already computed inenforce_context_budgetright before the event fires —ProgressEvent::Compactingis payload-free today and needs one field (usage_pct: f64); mechanical update of the ~6 match arms (slack/whatsapp/discord/telegram progress+resume/cli/tui).ProgressEvent::CompactionSummary { summary }already exists and has TUI/CLI consumer arms but is never emitted — emitting it on successful compaction gives the completion line its→ 26%number with no new event type.progress.rs/resume.rs/flow.rs/flow_chrome.rs); the agent side gains only the event payloads.Filed under owner sanction for the compaction class (field report #1255 on this tracker; follow-ups on that class may continue upstream). Related: #1255 (stall watchdog — the reason the signal matters), #527 (history), #909 (pressure nudge — model-side only, invisible to the user).