fix(vscode): keep concurrent Agent Manager streams responsive

[marius-kilocode]

Agent Manager receives every CLI SSE event through the VS Code extension host. The SSE adapter also logged every non-heartbeat event, including high-frequency message.part.delta traffic. With several sessions running concurrently, one line of diagnostic logging became one additional extension-host console message for every stream event. VS Code then serialized and forwarded those messages to the renderer alongside the actual Agent Manager updates.

This removes only the per-event log from the SSE hot path. Connection, reconnect, heartbeat timeout, shutdown, and error diagnostics remain available. Event delivery, foreground/background scheduling, and inactive-session state updates are unchanged. A regression test drives 100 events through the adapter and verifies that all events are delivered without producing an event log for each one.

Measured impact

The before and after captures used the same Agent Manager scenario:

• Four local sessions running sustained, read-only codebase audits concurrently
• All four sessions confirmed busy throughout each capture
• The same foreground session visible in Agent Manager
• A 25-second Chrome trace and CPU profile after the workload reached steady state
• No worktrees, terminals, inline diff, or review UI involved
• The only implementation difference between captures was removal of the per-event log

Signal	Before	After	Change
Trace script time	1,719.55 ms	814.51 ms	52.6% lower
Chromium ScriptDuration	185 ms	66 ms	64.4% lower
Chromium TaskDuration	3.93 s	3.34 s	15.0% lower
Renderer process time	6.72 s	5.96 s	11.4% lower
Trace events	431,872	382,785	11.4% lower
Mojo messages handled	12,813	9,591	25.1% lower
Renderer run tasks	94,864	77,981	17.8% lower
Maximum foreground timer gap	63 ms	18.4 ms	70.8% lower
Foreground timer gaps above 32 ms	5	0	Eliminated in capture

The most direct result is that the webview spends roughly half as much traced time running JavaScript during concurrent streaming, while the overall renderer process uses about 11% less time. The foreground responsiveness signal also improves: the worst observed scheduling gap falls below one 60 Hz frame interval plus normal timer variance, and no gap exceeds 32 ms after the change.

The reduction in Mojo messages and renderer tasks confirms that this was not only console formatting cost inside Node.js. Removing the log also avoids transporting and processing those messages through VS Code's extension-host logging pipeline.

These figures describe this four-session steady-state workload rather than a universal percentage for every machine or model. The benefit scales with SSE event volume: a single idle session sees little difference, while multiple token and tool streams avoid one console message per incoming event.

The remaining profile cost is primarily webview style recalculation and paint from large live transcripts, plus normal background-session store processing. Those are separate rendering concerns and are intentionally unchanged here to avoid stale inactive tabs or delayed tool state.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

The change is surgical and correct. The removed four lines extracted the event type solely for a console.log that fired on every non-heartbeat SSE event — a significant source of extension-host serialization overhead at scale. All diagnostic logs for connection lifecycle, reconnect, heartbeat timeout, and error paths are preserved. The test correctly verifies the hot-path log is gone while confirming all 100 events still reach subscribers, and properly restores console.log in finally.

Files Reviewed (3 files)

• packages/kilo-vscode/src/services/cli-backend/sdk-sse-adapter.ts
• packages/kilo-vscode/tests/unit/sdk-sse-adapter.test.ts
• .changeset/quiet-concurrent-streams.md

---

_{Reviewed by claude-4.6-sonnet-20260217 · 368,674 tokens}

_{Review guidance: REVIEW.md from base branch main}