[BlueKingMuch]

A conversation that was restored and is parked again keeps its unchanged K/V pages and appends the new ones (92a3d5f, from #189). The appended segment also reserves room for later turns, growing geometrically up to 16 MiB, and it does that in every K/V buffer of the image: k, v, their scales and the indexer rows of each QSA layer, and the draft layer's. With Qwen3.8-Flash-Next (IQ3_S, int8 K/V) that came to 0.4 to 0.5 GiB of unused capacity per conversation parked again, about half the image on top. The cache counts capacity against --conversation-cache-mib, so the reserve decides which conversations get evicted.

This bounds the reserve by an eighth of what the buffer held before the append (at least 64 KiB, and at most 16 MiB as before). Turns still fill the reserve instead of adding a restore transfer each: the 4096-append test keeps its bound, and 256 turns of 1 MiB onto a 16 MiB buffer take 28 segments instead of 17.

The docs said parking falls back to a full capture when the reserve would evict another conversation. 6cd29d9 removed that check, since a fresh capture never evicts less - which did not hold with this reserve: below, the images parked again are about 1.5x the fresh size. With the reserve bounded, the two differ by at most an eighth of the K/V, and the docs now say what the reserve is instead.

Measured

On 0.1.40.1, this commit against v0.1.40.1. RTX 4080 SUPER 32 GB, Ryzen 7 5800X3D, 96 GB DDR4, Windows 11, IQ3_S, 262K context, --conversation-cache-mib 2816 --conversation-cache-slots 3, a fixed expert placement (--adapt-every 1000000 --expert-cache 8031), greedy, 64-token answers. A main agent P (30,000 tokens) and two subagents S1 and S2 with the same system prompt (15,000 each) take turns for two rounds, and every return adds 2,300 tokens: P1 S1 P2 S2 S1b S2b P3 S1c S2c P4.

Parked images from the engine log, against (1 + checkpoints) x 0.11 GiB + 14.9 KiB per token:

conversation parked again	v0.1.40.1	this PR	computed
P at S2 (32,429 tokens, 3 checkpoints)	1.38 GiB	0.92 GiB	0.90 GiB
S2 at P3 (17,429 tokens, 3 checkpoints)	1.08 GiB	0.69 GiB	0.69 GiB
P at S1c (34,791 tokens, 4 checkpoints)	1.49 GiB	1.09 GiB	1.04 GiB

What that does to the turns (prompt tokens read, time to first token):

	v0.1.40.1	this PR
S1c, subagent 1 in the second round	17,242, 5.5 s (S1 evicted at P3)	2,300, 2.9 s
S2c, subagent 2 in the second round	17,242, 5.4 s	2,369, 2.9 s
all ten requests	116,147 read, 49.9 s	86,332 read, 44.6 s
evicted	3	1

(S2c in v0.1.40.1 loses S2 another way: S1c, reading from the shared system prompt, moves S2's checkpoint into the session and overwrites S2. That is the next PR: #1164)

With the cache on and the fixed placement, the main agent's four answers equal a run without subagents, in both runs. conversation_cache_test passes on Windows (its new checks fail on v0.1.40.1 without the change), as do conversation_snapshot_test (with CUDA) and conversation_file_test.

cc @jeremiahritchey - the reserve came with your incremental capture; I kept its shape and only bounded it.

[Niko1221]

Thank you, this is in for 0.1.45 with your authorship. The unit tests pass on CUDA sm_86 and sm_60. At 12K tokens the snapshots are the same size as before (the reserve only exceeds 1/8 once a K/V buffer is over 16 MiB), so the saving shows from about 30K tokens.

[Niko1221]

Thanks for the pull request.

Your change is already in main for 0.2.0-beta, with your credit, so there is nothing left for you to do here. We're closing it because we're resetting the tracker for 0.2.0-beta: there are more than 1,300 open issues and pull requests, and we're closing everything that isn't being worked on right now.

If part of your work did not make it in and you want it considered, open a new pull request on top of main that follows CONTRIBUTING.md, or comment /reopen after fixing the title area prefix and the template.