Problem
The interactive CLI synchronously rewrites the complete retained conversation after every successful turn before the loop can accept the next prompt.
In v0.0.213:
src/mainloop.zig:645-648 calls session.saveSession(...) after every turn.
src/session.zig:219-272 allocates a fresh output buffer, serializes root.messages in full, calculates context information, and calls writeFile with the entire snapshot.
The cost of one autosave is therefore O(total retained history), not O(the new turn). Across a growing conversation this creates increasing CPU, allocation, and filesystem work specifically between the final visible answer and next-prompt readiness.
This is not an argument against continuous persistence. The issue is putting a full-history rewrite on every turn's synchronous readiness path.
Expected behavior
Preserve crash-safe continuous persistence without making next-prompt latency scale with the complete session size.
Possible designs:
- append-only per-turn journal/WAL plus periodic atomic snapshots;
- coalesced background snapshot writes with sequence numbers and atomic rename;
- retain a small synchronous durable append, but move full consolidation off the prompt-readiness path.
Clean exit should drain the latest pending persistence operation, and recovery should ignore a torn final journal record/snapshot.
Suggested benchmark / acceptance criteria
Measure final assistant delta -> next prompt accepting input for fixed-size new turns against sessions containing, for example, 100 KiB, 1 MiB, and 10 MiB of retained messages.
The per-turn durability operation should scale primarily with newly appended state; full snapshot consolidation should not block the next prompt.
Scope
Zig CLI/core only; unrelated to the GUI.
Problem
The interactive CLI synchronously rewrites the complete retained conversation after every successful turn before the loop can accept the next prompt.
In v0.0.213:
src/mainloop.zig:645-648callssession.saveSession(...)after every turn.src/session.zig:219-272allocates a fresh output buffer, serializesroot.messagesin full, calculates context information, and callswriteFilewith the entire snapshot.The cost of one autosave is therefore O(total retained history), not O(the new turn). Across a growing conversation this creates increasing CPU, allocation, and filesystem work specifically between the final visible answer and next-prompt readiness.
This is not an argument against continuous persistence. The issue is putting a full-history rewrite on every turn's synchronous readiness path.
Expected behavior
Preserve crash-safe continuous persistence without making next-prompt latency scale with the complete session size.
Possible designs:
Clean exit should drain the latest pending persistence operation, and recovery should ignore a torn final journal record/snapshot.
Suggested benchmark / acceptance criteria
Measure
final assistant delta -> next prompt accepting inputfor fixed-size new turns against sessions containing, for example, 100 KiB, 1 MiB, and 10 MiB of retained messages.The per-turn durability operation should scale primarily with newly appended state; full snapshot consolidation should not block the next prompt.
Scope
Zig CLI/core only; unrelated to the GUI.