Fold-host resident state during long high-reasoning drafts is a significant share of a 128 MB DO isolate — bounding/spill options?

Environment: @flue/[email protected], one-shot draft agent in a Cloudflare Durable Object (128 MB isolate limit).

Observation

While investigating a production OOM crash-loop on a long, high-reasoning draft (large thinking deltas over many turns), heap snapshots attributed ~21% of retained memory to ConversationRecordWriter and its pinned conversation fold host (getConversationFoldHost → cached reducedState). The majority (~79%) was our own observability adapter's queue — separate issue, fixed on our side (braintrustdata/braintrust-sdk#2353) — but the fold-host share alone is meaningful against a 128 MB budget once conversations get long.

We can see the design already bounds much of this deliberately: non-retain-set records downgrade to ConversationRecordStub at application, and streaming-record stubs are released when the message materializes. What remains resident for the writer's lifetime appears to be the materialized entries (including completed reasoning block bodies) and the retain-set record bodies — plus, while a message is in progress, its accumulated blocks.

Asks / questions

1. Is there (or could there be) an option to drop completed reasoning/thinking block bodies from resident reduced state when the harness does not re-send thinking to the model? For reasoning-heavy models these bodies dominate entry size.
2. A windowed or spillable fold host — reconstruct older entries from the log on demand — for agents whose conversations outlive what a 128 MB isolate can comfortably keep resident.
3. Failing either, documented guidance on expected resident-memory shape per conversation size, so consumers can set compaction/abort budgets against it.