Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from September 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.
My local Qwen model runs through llama.cpp with a large configured context, but OpenClaw starts disruptive recovery or compaction behavior much earlier than I expect. Long turns can sit for many minutes without producing a visible answer.
Verify three separate limits: the context actually allocated by llama.cpp, the model entry’s contextWindow and contextTokens, and the session’s effective budget. OpenClaw compacts before the absolute limit to reserve room for instructions, tools, and output.
Check /status, /context detail, and the Gateway log around the event. Use a fresh session after changing a model definition because an existing session can retain older routing state.
The model entry declares the large context in both fields and uses the OpenAI-compatible llama.cpp endpoint. Compaction is in safeguard mode, mid-turn precheck is enabled, and the model preserves its hidden thinking.
That makes the configured window less likely to be the only problem. Test one variable at a time. Remove legacy compaction tuning and start with the current effective default, safeguard, while leaving midTurnPrecheck.enabled disabled, which is also the current default. Confirm the provider API is the compatible completions route, restart the Gateway, and use /new. If safeguard summarization itself appears incompatible with this provider, test mode: "default" only as a controlled exception.
The decisive log fields are the effective context budget, the preflight reserve, and the model’s finish reason.
Could OpenClaw be misreading token usage because the provider entry does not explicitly name the OpenAI-compatible API? I tested a direct non-streaming request, and llama.cpp returned normal prompt_tokens, completion_tokens, and total_tokens.
That rules out a missing non-streaming usage field. Normal agent runs stream, so streaming usage is still a separate check. Even when the backend reports exact usage afterward, OpenClaw must estimate the next prompt before sending it, so tokenizer or chat-template differences can still affect preflight behavior.
The session later reached a much larger context without compacting, but the original behavior returned: repeated model requests without semantic progress, with stream chunks arriving but no visible answer. Would raising maxTokens help the model finish?
A larger output budget might prevent an immediate finish_reason: length when hidden reasoning consumes the same token allowance, but it is not guaranteed to produce visible text. It also increases generation time, resource use, and the prompt-plus-output reserve. Raise it only as a controlled test, keep the context unchanged, and compare the finish reason.
Current references: local models and compaction.