A troubleshooting guide showing how changing OpenClaw's contextInjection setting from 'always' to 'continuation-skip' fixes prompt cache reloading on every turn when using llama-server, resulting in a 100x speed improvement for long sessions.
Long story short: my OpenClaw sessions were getting slower as they grew. At 90k+ tokens, every reply took over 2 minutes. I thought it was a llama.cpp issue. It was not. It was an OpenClaw setting that was silently invalidating the prompt cache on every single turn. **The setup** - Qwen3.6-27B-Q8_0 on dual RTX 3090s (tensor parallel) - llama-server with `--cache-prompt`, `--ctx-size 400000`, `--parallel 2` - OpenClaw connecting over LAN - Everything was fast until sessions grew past ~90k tokens **The symptoms** llama-server logs showed this on every turn: ``` forcing full prompt re-processing due to lack of cache data erased invalidated context checkpoint (pos_min = 57172) erased invalidated context checkpoint (pos_min = 60139) erased invalidated context checkpoint (pos_min = 91076) prompt eval time = 130511 ms / 91403 tokens ``` 91k tokens re-processed from scratch. 130 seconds. Every. Turn. The cache was enabled. The checkpoints existed. But llama.cpp kept finding zero matches and falling back to full re-processing. **What I checked first (and was not the issue)** - `--ctx-size` was fine (raised it from 320k to 400k anyway) - `--cache-prompt` was enabled - `--cache-reuse` and `--ctx-checkpoints` were set - VRAM was not the bottleneck (dual 3090s, plenty of headroom) - Model quantization was solid (Q8_0) - GPU performance was normal (~25 tok/s generation, ~700 tok/s prompt processing) Nothing on the llama.cpp side was broken. The server was doing exactly what it was told. **The actual culprit** OpenClaw has a setting called `contextInjection`. Default value is `always`. This means OpenClaw re-injects all workspace bootstrap files (AGENTS.md, SOUL.md, USER.md, TOOLS.md, MEMORY.md, HEARTBEAT.md, roughly 15kb of text) into the system prompt on every single turn. Including continuation turns after a completed assistant response. llama.cpp prompt cache works by matching the exact token sequence. If the prefix changes even slightly, the cache cannot be reused. By re-injecting bootstrap files every turn, OpenClaw was changing the system prompt structure each time. Timestamps shifted. Dynamic context changed. The token sequence no longer matched the cached checkpoint. llama.cpp correctly refused to use stale cache and re-processed everything. The cache was not broken. It was being fed a different prompt each turn. **The fix** ``` openclaw config set agents.defaults.contextInjection continuation-skip --merge ``` Then restart the gateway. `continuation-skip` means: only inject bootstrap files on new user messages. Skip them on continuation turns. The prompt stays stable. The cache stays valid. **The results** Before: - 91,403 tokens re-processed per turn - 130 seconds prompt eval time - 0% cache reuse - 2+ minutes per reply in long sessions After: - 513 new tokens per turn (just the actual new content) - 1.3 seconds prompt eval time - 99.7% cache reuse - ~5 seconds per reply 100x faster. Same hardware. Same model. One config line. **Why this matters** If you are running OpenClaw with a local llama.cpp backend and your long sessions feel slow, check your llama-server logs for `forcing full prompt re-processing`. If you see it, the issue is likely on the client side, not the server side. The default `contextInjection: always` makes sense for cloud APIs where each call is independent. It does not make sense for local servers with persistent KV caches. This is probably the single most impactful setting for anyone running OpenClaw with llama.cpp. **Other things we tuned (not the root cause but worth doing)** - Raised `--ctx-size` from 320k to 400k (200k per session instead of 160k) - Set OpenClaw contextTokens to 200k to match - Lowered memoryFlush.softThresholdTokens from 30k to 10k for later memory flush These are good improvements but the cache fix was purely the contextInjection change. **How to diagnose this yourself** ```bash ssh your-server "journalctl -u llama.service --no-pager -n 50 | grep -iE 'cache|re-process|checkpoint'" ``` Broken cache: - `forcing full prompt re-processing due to lack of cache data` - `erased invalidated context checkpoint` (repeated many times) - Prompt processing over 30 seconds Healthy cache: - `restored context checkpoint` - `f_keep = 0.99+` - `graphs reused =` (large number) - Prompt processing under 5 seconds Hope this saves someone the hours of debugging it took us to figure out.
This article details a critical bug in llama-server where restored KV cache is immediately discarded due to missing checkpoint metadata, and presents a 117-line fix using a sidecar file to persist checkpoints across restarts, achieving a ~720x speedup in prefill time.
User reports that Qwen3.6 models running on llama.cpp server become significantly less capable after ~2 weeks of continuous operation, and restarting sessions does not resolve the issue.
A user shares their experience with llama.cpp server's model offloading, noting performance trade-offs and quiet operation, and asks for resources to understand how the tool manages memory across VRAM and system RAM.
A setting in llama.cpp's webUI re-sends generated tokens to the KV cache to significantly reduce prompt processing latency, improving responsiveness for long generations or tool calls without apparent trade-offs.
User seeks advice on preventing llama.cpp from offloading KV cache to swap before RAM is fully exhausted, sharing their configuration on an M2 Max with 96GB RAM and a large Qwen model.