Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.
After changing my compaction settings on an older OpenClaw build, auto-compaction says it cannot recover the turn. The session shows about 440,000 tokens used in a model advertised with a one-million-token context. My config keeps 100,000 recent tokens, and the diagnostic discussion mentions a reserve floor.
On the older build in this conversation, keepRecentTokens controlled how much recent history survived compaction, while reserveTokensFloor represented working headroom for the next turn, system prompt, tools, and summary generation. Increasing that reserve did not enlarge the model context.
OpenClaw 2026.9.3 no longer exposes reserveTokensFloor as an authored configuration setting. It computes the required reserve internally. Before changing current compaction controls, validate the effective context and reproduce the event with openclaw logs --follow. The displayed session estimate may differ from the provider’s accepted request size.
So what did reserveTokensFloor mean on that older build, and what should I configure now?
It was a lower bound for the headroom left outside retained history, so increasing it could make compaction happen earlier. On 2026.9.3, leave that retired key out of the config. keepRecentTokens remains available when you need to protect more immediate history, while OpenClaw calculates the working reserve itself.
Then why would compaction start around 440,000 tokens on a model advertised with a one-million-token context?
At that usage level, the event may be overflow recovery rather than normal proactive compaction. A provider can reject the full request because of a lower effective limit, large tool results, attachments, or model metadata that does not match the endpoint. Capture whether the trigger says overflow, budget, or preflight. OpenClaw’s internally calculated reserve alone would not explain compaction around 44 percent.
Now /compact says the session was already compacted recently, and removing my custom settings did not clear it. I cannot continue the conversation.
That is a per-session guard state. Configuration changes do not erase it. Start /new as a standalone command to create a fresh conversation without deleting the old transcript. Leave the compaction block at defaults for the first test. If the new session again compacts far below its effective budget, collect the overflow lines and model metadata for a separate provider or context-limit investigation.