Issue after compaction

[charly1r]

I will type this issue by hand since people that use AI frown upon using AI when posting, I can only use AI to do the same things they do(but idk what they do) lol.

The problem is not model specific, I tried several models and context sizes.

The problem that sometimes I see is that after a compression it starts reading the project files again and it seems another compression
triggers but the session is too small to compress again and the session cannot be recovered regardless of what you type.

The CPP log shows the last 2 steps goes from task 21081 ,n_tokens = 5405 to task 21105, n_tokens = 61194

 tg =  36.13 t/s, tg_3s =  36.01 t/s
43.53.848.644 I slot print_timing: id  0 | task 20369 | n_decoded =   2559, tg =  36.11 t/s, tg_3s =  35.59 t/s
43.56.852.217 I slot print_timing: id  0 | task 20369 | n_decoded =   2667, tg =  36.10 t/s, tg_3s =  35.96 t/s
43.57.213.935 I slot print_timing: id  0 | task 20369 | prompt eval time =    1672.30 ms /   123 tokens (   13.60 ms per token,    73.55 tokens per second)
43.57.213.941 I slot print_timing: id  0 | task 20369 |        eval time =   74230.87 ms /  2677 tokens (   27.73 ms per token,    36.06 tokens per second)
43.57.213.942 I slot print_timing: id  0 | task 20369 |       total time =   75903.17 ms /  2800 tokens
43.57.213.943 I slot print_timing: id  0 | task 20369 |    graphs reused =      20469
43.57.213.947 I slot print_timing: id  0 | task 20369 | draft acceptance = 0.99307 ( 2005 accepted /  2019 generated), mean len =  3.98
43.57.215.086 I slot      release: id  0 | task 20369 | stop processing: n_tokens = 70222, truncated = 0
43.57.366.994 I slot get_availabl: id  0 | task -1 | selected slot by LCP similarity, sim_best = 1.000 (> 0.100 thold), f_keep = 1.000
43.57.367.839 I slot launch_slot_: id  0 | task 21046 | processing task, is_child = 0
44.01.703.330 I slot print_timing: id  0 | task 21046 | prompt eval time =     773.54 ms /    35 tokens (   22.10 ms per token,    45.25 tokens per second)
44.01.703.336 I slot print_timing: id  0 | task 21046 |        eval time =    3561.82 ms /    96 tokens (   37.10 ms per token,    26.95 tokens per second)
44.01.703.337 I slot print_timing: id  0 | task 21046 |       total time =    4335.36 ms /   131 tokens
44.01.703.338 I slot print_timing: id  0 | task 21046 |    graphs reused =      20500
44.01.703.343 I slot print_timing: id  0 | task 21046 | draft acceptance = 0.65625 (   63 accepted /    96 generated), mean len =  2.97
44.01.704.461 I slot      release: id  0 | task 21046 | stop processing: n_tokens = 70352, truncated = 0
44.01.844.826 I slot get_availabl: id  0 | task -1 | selected slot by LCP similarity, sim_best = 0.995 (> 0.100 thold), f_keep = 1.000
44.01.845.632 I slot launch_slot_: id  0 | task 21081 | processing task, is_child = 0
44.01.902.664 W slot create_check: id  0 | task 21081 | erasing old context checkpoint (pos_min = 5404, pos_max = 5404, n_tokens = 5405, size = 170.843 MiB)
44.05.997.392 I slot print_timing: id  0 | task 21081 | prompt eval time =    1887.59 ms /   367 tokens (    5.14 ms per token,   194.43 tokens per second)
44.05.997.398 I slot print_timing: id  0 | task 21081 |        eval time =    2264.07 ms /    65 tokens (   34.83 ms per token,    28.71 tokens per second)
44.05.997.399 I slot print_timing: id  0 | task 21081 |       total time =    4151.66 ms /   432 tokens
44.05.997.400 I slot print_timing: id  0 | task 21081 |    graphs reused =      20519
44.05.997.405 I slot print_timing: id  0 | task 21081 | draft acceptance = 0.76667 (   46 accepted /    60 generated), mean len =  3.30
44.05.998.538 I slot      release: id  0 | task 21081 | stop processing: n_tokens = 70785, truncated = 0
44.06.105.801 I slot get_availabl: id  0 | task -1 | selected slot by LCP similarity, sim_best = 0.990 (> 0.100 thold), f_keep = 1.000
44.06.106.712 I slot launch_slot_: id  0 | task 21105 | processing task, is_child = 0
44.06.106.856 W slot create_check: id  0 | task 21105 | erasing old context checkpoint (pos_min = 61193, pos_max = 61193, n_tokens = 61194, size = 389.832 MiB)
44.11.831.470 I slot print_timing: id  0 | task 21105 | prompt eval time =    3030.07 ms /   691 tokens (    4.39 ms per token,   228.05 tokens per second)
44.11.831.476 I slot print_timing: id  0 | task 21105 |        eval time =    2694.58 ms /    85 tokens (   31.70 ms per token,    31.54 tokens per second)
44.11.831.477 I slot print_timing: id  0 | task 21105 |       total time =    5724.65 ms /   776 tokens
44.11.831.478 I slot print_timing: id  0 | task 21105 |    graphs reused =      20542
44.11.831.483 I slot print_timing: id  0 | task 21105 | draft acceptance = 0.84722 (   61 accepted /    72 generated), mean len =  3.54
44.11.832.666 I slot      release: id  0 | task 21105 | stop processing: n_tokens = 71561, truncated = 0

The session looks healthy but at the end there seems to be a compression pending the session says the context is too small but the CPP logs show n_tokens = 71561

Has anyone observe red similar behavior?

llama-server-2026-07-13_17-14-57.log

[Qm-jmz]

I have encountered similar problems:
Error: Compaction failed: Nothing to compact

[itayinbarr]

Fixed in v1.11.0 — thank you Carlos, and @Qm-jmz for confirming it wasn't model-specific.

You nailed the root cause in your description: after a mid-run compaction the run resumes, starts re-reading the project files, context climbs back over the threshold, and a second compaction fires — but by then the only summarizable slice left is the tiny post-compaction tail, so pi throws Compaction failed: Nothing to compact. And because pi's compact() aborts and disconnects the agent before that check runs, the failed second compaction leaves the session dead — nothing you type brings it back. That matches exactly the two-step jump you saw in the CPP log (task 21081 n_tokens = 5405 → task 21105 n_tokens = 61194): the tail re-inflating right after a compaction.

The proper fix — detect the incompressible tail and elide-rescue before giving up — lives inside the pi runtime itself (little-coder is a thin wrapper over it), and the same failure mode has been traced in the wider pi ecosystem, so I've flagged it upstream. But little-coder doesn't have to sit and wait for that: the wedge only happens because the watchdog loops, so v1.11.0 breaks the loop from the wrapper side:

• The context-watchdog now measures each compaction's actual effect. If usage is still hovering near the threshold afterward (it freed too little), it pauses automatic compaction and tells you — context still at N% after compaction — automatic compaction paused to avoid a loop — instead of firing the doomed second compact(). It re-arms on its own once usage drops back below the threshold band (a /clear, a /compact, or a genuinely smaller turn).
• A compaction that outright errors (a "Nothing to compact" that still slips through) now pauses the same way rather than silently retrying.
• The mid-run resume message now explicitly tells the model not to re-read files it already read — that re-scan was what re-inflated context in the first place.

Net effect: on a context window that's just too small for the task, you now get a clear "paused — free space or use a larger-context model" notice and a still-usable session, instead of an unrecoverable one.

If you can, please give v1.11.0 a spin on the same workloads that reproduced it and let me know if you still hit a wedge. And if you're routinely near the ceiling, a larger -c window (or a bigger-context model) remains the real headroom fix. Thanks again for the precise report — the log excerpt made this much faster to pin down.