Bug: SessionSummary runs on every processor finish-step and repeatedly loads full session history

[sjawhar]

Bug Description

Tool-using sessions can freeze the TUI and drive multi-GB RSS growth because SessionSummary.summarize(...) is invoked on every assistant finish-step, and summarize() loads the full session history (Session.messages({ sessionID })) every time.

This creates a hot loop during multi-step agent execution:

1. prompt loop re-enters for normal tool-assisted execution
2. processor finish-step fires for each assistant model turn
3. processor calls SessionSummary.summarize(...)
4. summarize loads the full session history and hydrates all parts
5. memory spikes and repeats on every turn

Root Cause

Primary trigger

packages/opencode/src/session/processor.ts

Inside the finish-step event handler, the processor unconditionally calls:

SessionSummary.summarize({
  sessionID: ctx.sessionID,
  messageID: ctx.assistantMessage.parentID,
})

That means summary runs once per assistant model turn, not once per overall user prompt.

Expensive operation

packages/opencode/src/session/summary.ts

summarize() calls:

const all = yield* sessions.messages({ sessionID: input.sessionID })

With no limit, this hydrates the full message history every time.

Evidence

Live diagnostic repro with labeled binary:

• prompt loop entry: 4
• summary start: 4
• summary loaded messages: 4
• prompt loop summary trigger: 1
• prune start: 0
• session messages full: 10
• message hydrate: 45

This proves:

• prompt loop re-entry is happening during normal multi-step execution
• repeated full-history loads are coming from summary, not prune
• processor-side summary calls explain the count gap beyond the one prompt-loop trigger

User Impact

• standalone TUI freezes / becomes unresponsive
• process RSS grows into multi-GB territory
• likely contributes to shared serve memory drift under long-running tool sessions

Proposed Fix

1. Remove the processor-side SessionSummary.summarize(...) call from finish-step
2. Keep summary responsibility at the prompt-loop level instead of per-step
3. Add a cheap guard in summary.ts to skip work if the target user message already has summary.diffs

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: Session loop performance — doom loop in-memory, summary debounce, parallel plugin events #20302: Feature request that explicitly proposes running SessionSummary.summarize() only on the first step to avoid redundant per-step summary computation — same root fix as proposed here
• [FEATURE]: Session loop performance — message cache, tool cache, doom loop optimization, summary debounce, parallel plugin events #20285: Broader session loop performance proposal that includes the same "summary debounce" fix (run summarize only on first step) as well as the related full-history load problem
• perf: prompt loop loads entire conversation history into memory on every step #18136: Bug report covering the same symptom of the full session history being loaded into memory on every step during multi-step agent execution

[sjawhar]

Re: possible duplicates (#20302, #20285, #18136)

These are closely related, but not clean duplicates of #21761:

• [FEATURE]: Session loop performance — doom loop in-memory, summary debounce, parallel plugin events #20302 and [FEATURE]: Session loop performance — message cache, tool cache, doom loop optimization, summary debounce, parallel plugin events #20285 are broader performance feature/proposal issues. They explicitly suggest a "summary debounce" / "summarize only on first step" optimization, which is the same remediation direction as the fix here. But they cover a bundle of loop-performance ideas rather than this specific traced production bug.
• perf: prompt loop loads entire conversation history into memory on every step #18136 is a related performance bug about the prompt loop loading the full conversation history on every step. That is a different hot path. Bug: SessionSummary runs on every processor finish-step and repeatedly loads full session history #21761 is narrower: the processor-side finish-step handler calls SessionSummary.summarize() on every assistant turn, and summarize() does a full sessions.messages({ sessionID }) load each time.

So #21761 is the concrete root-cause bug report for one specific repeated full-history load path we traced with live diagnostics.

PR with fix: #21762