Problem

In a long session (200+ turns, lots of tool calls), three Vecs grow unbounded:

• app.history (HistoryCell) — every user / assistant message + every tool result rendered in the transcript.
• app.api_messages (Message) — every message that gets sent to the LLM next request.
• app.tool_log (Vec) — every tool invocation logged for debugging.

Each grows linearly with turn count. On a 4-hour coding session with 500 tool calls, this can climb past 1GB resident memory before the user notices.

The compaction flow trims api_messages for LLM-bound context, but history and tool_log aren't bounded.

Proposed solution

A few independent measures:

1. Bound history. Cap at N entries (default 5000). When exceeded, drop oldest 500 entries; replace with a synthetic "[N earlier messages truncated — use /sessions to load full history]" cell.

2. Bound tool_log. Ring buffer at 500 entries. Older entries archived to ~/.deepseek/sessions/<id>/tool-log.jsonl if the user wants to grep them later.

3. Working-set summary should be persisted, not held in memory. The working_set summary computation already exists (fix(cache): drop volatile fields from working_set summary block (#280) #287) but the input data is held forever. After cutoff, drop the input and keep only the rendered summary.

4. Bench. Add a stress test: simulate 1000 turns and measure RSS. Pin it as a regression test.

Acceptance criteria

• history, tool_log cap behavior implemented and tested.
• ~/.deepseek/sessions/<id>/tool-log.jsonl written on cap-evict.
• Stress test in crates/tui/tests/ simulates 1000 turns and asserts RSS stays below a configurable ceiling (e.g., 256 MB).
• User-facing message when truncation kicks in (en + zh-Hans).

Related

• crates/tui/src/compaction.rs — existing context-compaction mechanism.
• crates/tui/src/working_set.rs — working-set summarization.