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.
My provider starts struggling when a session gets close to 175k tokens. I would like compaction to start sooner, but manual compaction also gives up after a few minutes because the provider is slow. Can I lower the effective context limit and give compaction more time without changing the general agent timeout?
Yes. A provider model entry’s contextTokens value lowers the effective context budget for that model, and compaction.timeoutSeconds controls the compaction watchdog separately from the general agent timeout.
First inspect the configured model entries and identify the correct provider and array index:
openclaw config get models.providers.PROVIDER_ID.models
Replace PROVIDER_ID and index 0 below with the entry you actually use, then set a starting cap below the provider’s trouble point and give compaction more time:
openclaw config set 'models.providers.PROVIDER_ID.models[0].contextTokens' 160000 --strict-json
openclaw config set agents.defaults.compaction.timeoutSeconds 600 --strict-json
openclaw config get 'models.providers.PROVIDER_ID.models[0].contextTokens'
openclaw config get agents.defaults.compaction.timeoutSeconds
Check openclaw --version as well, because older builds used a shorter default watchdog.
I checked the redacted log and version. The provider opens a streaming response successfully, but compaction is aborted after about 180 seconds with a missing terminal response event. The provider transport itself has a much longer timeout, so that does not look like the limit being hit.
That log separates the two limits. The roughly 180-second line is OpenClaw’s compaction watchdog. The much larger transport timeout is not stopping this run. The missing terminal event appears after OpenClaw aborts the still-open stream.
Set the watchdog to 600 seconds, confirm the value, and keep the selected provider model entry’s context cap at 160000. If the request still hangs for the full ten minutes, the compatibility endpoint may not be completing its streaming response correctly.
Both settings were written successfully. The selected provider model entry now reports contextTokens: 160000, and the compaction timeout reads 600. The CLI says the Gateway needs a restart before they apply.
Restart the Gateway and retry compaction. If the slow endpoint still stalls while safeguard mode performs its additional passes, try the simpler default compaction mode:
openclaw config set agents.defaults.compaction.mode default
openclaw gateway restart
Then run compaction again. If it still fails, the useful evidence is the final compaction diagnostic line and a redacted view of the terminal streaming event.
That worked. Compaction completed successfully after I changed the mode to default.
Great. That points to the extra work in safeguard mode as the practical issue for this slow provider path. The working combination was a 160k cap on the selected provider model entry, a 600-second compaction timeout, and default compaction mode.