[Bug]: Paragraph streaming stores every full reasoning snapshot as a permanent event (OpenCode: 93k rows, 2.2 GB in one day) #23365

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Related: #20443 (closed; asked for database growth from a live OpenCode session), #21154 (closed; asked for a new issue covering only the turn-item.updated / OpenCode per-chunk part), #19780 and #20990 (compacting intermediate turn-item snapshots after the fact).

Area

apps/server

Steps to reproduce

1. Leave responseStreamingMode at its default, "paragraph".
2. Run OpenCode threads on a model that writes long reasoning (we used local models served through Ollama).
3. On a copy of statev2.sqlite, count streamed reasoning snapshots per item:

SELECT json_extract(payload_json, '$.id') AS item,
       count(*) AS streaming_rows,
       sum(length(payload_json)) AS bytes
FROM orchestration_events
WHERE event_type = 'turn-item.updated'
  AND json_extract(payload_json, '$.type') = 'reasoning'
  AND json_extract(payload_json, '$.streaming') = 1
GROUP BY item
ORDER BY bytes DESC;

Expected behavior

The durable event log stores a bounded number of rows for a streamed reasoning item, so its storage cost grows roughly with the final text length, not with its square.

Actual behavior

In paragraph mode, makeAssistantStreamingFilter (apps/server/src/orchestration-v2/assistantStreaming.ts) passes one streaming turn_item.updated snapshot per item at most every 400 ms, whenever a new paragraph is ready. RunExecutionService hands each passed event to ProviderEventIngestor.ingestNormalized, so each snapshot becomes a permanent turn-item.updated row holding the full cumulative text. A reasoning block that streams for several minutes writes hundreds of rows, each larger than the last.

Measured read-only on a copy of one macOS install's statev2.sqlite (about 24 GiB, 3.76 M events), for one day (2026-10-20 UTC) in paragraph mode:

• OpenCode reasoning averaged 17.5 turn-item.updated rows per item that day. Every other provider and item type stayed at 1.22 or less.
• The largest single item was one reasoning block: 612 rows, 69 MB. The next four were 448 rows (50 MB), 484 (43 MB), 416 (36 MB) and 392 (33 MB).
• The top 10% of streamed OpenCode reasoning items hold 86% of those bytes. p50 final reasoning length was about 1.7 k characters and p99 about 77 k.
• Total event payload that day was 2.78 GB, against 0.5 to 1.2 GB on other days.
• After switching the same install to responseStreamingMode: "turn", the next day stored 0 streaming reasoning rows and 0.6 GB of event payload in total.

The 400 ms throttle decides how many rows are stored. The gap between consecutive stored snapshots of one item was p10 0.43 s, p50 0.53 s, p90 0.99 s. So adapter-side delta coalescing at the 50 ms interval the Claude, Codex and ACP adapters use would not change the stored row count. OpenCode stands out because its reasoning streams long and in many paragraphs. It is not because those adapters persist less. Claude reasoning goes through the same filter but is short, so it stays small.

Background compaction (#19435) does not remove these rows, because turn-item.updated is outside its scope (#19780). #20990 would remove them on a later pass, but they are still written: on this install, 2.2 GB a day of writes on the single writer connection, then the page churn.

assistantStreaming.ts, the OpenCode v2 adapter's text path and ProjectionMaintenance.ts are unchanged in this respect between v0.1.1 and main at a49d18c.

Impact

Major degradation or frequent failure

Version or commit

v0.1.1 (desktop); the code paths above are unchanged on main at a49d18c.

Environment

macOS, T3 Code desktop v0.1.1, OpenCode provider with local Ollama models, plus Claude and Codex on the same install for comparison.

Logs or stack traces

2026-10-20 UTC, turn-item.updated, type in (reasoning, assistant_message)
opencode   reasoning          items 5656  rows 98751  streaming rows 93095  payload 2188 MB
opencode   assistant_message  items 14581 rows 17362  streaming rows 2781   payload 28 MB
claude     reasoning          items 4769  rows 5602   streaming rows 833    payload 8 MB
codex      assistant_message  items 1976  rows 2417   streaming rows 441    payload 5 MB
codex      reasoning          items 969   rows 972    streaming rows 3      payload 2 MB
gap between stored streaming snapshots of one opencode reasoning item: p10 0.429 s, p50 0.531 s, p90 0.989 s (n = 89,568)

Counts and sizes only. No thread content was read beyond $.id, $.type and $.streaming.

Workaround

Set responseStreamingMode to "turn". That stops live paragraph streaming for every provider. On this install it brought streaming reasoning rows to zero and daily event payload from 2.78 GB to 0.6 GB.

Possible directions for maintainers to choose from (no PR opened, since this changes how streamed text is persisted):

1. Deliver intermediate streaming snapshots to live clients without making each one a durable event. Store only the first snapshot (for item position) and the final one.
2. Bound intermediate persistence per item, for example a minimum interval that grows with text length, or a byte budget per item.
3. Land the compaction in fix(server): compact superseded turn-item snapshots #20990 so these rows are at least removed after a pass. That bounds what is retained but not what is written.