Context limit exceeded.

[static root]

Please try again.

To prevent this, increase your compaction buffer by setting agents.defaults.compaction.reserveTokensFloor to 20000 or higher in your config.

What is this, why and how exactly do I set agents.defaults.compaction.reserveTokensFloor to 20000 or higher in my config. Which file exactly and what is the exact syntax and location in the file.

[snow pendant]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[fickle lily]

That message means the session got close enough to the model's context limit that OpenClaw tried to compact/summarize the conversation, but there still wasn't enough token headroom left to finish cleanly. reserveTokensFloor is the minimum token buffer OpenClaw keeps free during compaction so the summarizer/reply has room to breathe.

First check your version, because config/schema details can move:

openclaw --version

The config file is normally:

~/.openclaw/openclaw.json

OpenClaw config is JSON5, so this exact shape is valid. Put compaction under agents.defaults:

[fickle lily]

{
  agents: {
    defaults: {
      compaction: {
        reserveTokensFloor: 20000,
      },
    },
  },
}

If you already have an agents or defaults block, don't duplicate it; merge the compaction block into the existing one. Example:

{

[fickle lily]

  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace",
      compaction: {
        reserveTokensFloor: 20000,
      },
    },
  },
}

Safer CLI way, which avoids hand-editing the file:

openclaw config set agents.defaults.compaction.reserveTokensFloor 20000 --strict-json

[fickle lily]

openclaw config validate

The Gateway watches ~/.openclaw/openclaw.json and usually hot-reloads it. If it keeps behaving the same way after validation passes, restart the gateway and try the conversation again.

Docs: https://docs.openclaw.ai/gateway/configuration and https://docs.openclaw.ai/gateway/configuration-reference

[static root]

I asked OpenClaude to edit the config for me as it should be able to since I have loaded docker.sock and set all permissions to Full. But still it reports:
I tried to apply that change via the gateway config.patch tool, but OpenClaw blocks it as a protected config path:

• gateway config.patch cannot change protected config paths: agents.defaults.compaction.reserveTokensFloor

Right now the gateway tool only allows mutating a small allowlist of paths (mostly prompt/model/mention-visibility settings), and reserveTokensFloor isn’t on it.

[fickle lily]

That error is expected. Docker socket access / “Full” tool permissions do not bypass the Gateway’s protected config-path checks. config.patch is a control-plane API and it deliberately blocks some config paths even for capable agents.

For this specific setting, use the local CLI or edit the config file on the machine running the Gateway, not the agent’s gateway config.patch tool.

Run on the Gateway host:

openclaw --version
openclaw config set agents.defaults.compaction.reserveTokensFloor 20000 --strict-json
openclaw config get agents.defaults.compaction.reserveTokensFloor
openclaw config validate

The file this writes is normally:

[fickle lily]

~/.openclaw/openclaw.json

If you’re using a custom config path or Docker, confirm the active path with:

openclaw gateway status

or check whether the service/container sets OPENCLAW_CONFIG_PATH.

If you want OpenClaude to do it, ask it to run the shell command above on the host/container that owns the real config file, or to directly edit ~/.openclaw/openclaw.json. Asking it to use config.patch will keep hitting the protected-path guard.

Docs: https://docs.openclaw.ai/gateway/configuration and https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultscompaction

[static root]

Now I have set agents.defaults.compaction.reserveTokensFloor to 20000 and restarted OpenClaw, but still on the next dialog I get Context limit Exceeded again and I am again advised to set agents.defaults.compaction.reserveTokensFloor to 20000...... ?!

[fickle lily]

That’s frustrating, but the repeated advice does not prove the setting was ignored. That error text is generic; it still says “set reserveTokensFloor to 20000” even if you already did.

Most likely causes:

1. The running Gateway is not using the config file you edited. Check the active config path and the live value:

openclaw --version
openclaw gateway status
openclaw config get agents.defaults.compaction.reserveTokensFloor
openclaw config validate

If config get does not print 20000, you edited the wrong file/path. In Docker/custom setups, look for OPENCLAW_CONFIG_PATH.

2. The existing session is already too large/wedged. The reserve helps future compactions happen earlier; it may not rescue a session that is already past the failure point. In the affected chat/session, start fresh with:

[fickle lily]

/reset

or use /new for a new session. That drops the current session context, so only do it when you’re okay losing that conversation history.

3. 20000 may still be too low for your model/history/tool output. The docs example uses 24000; for a session that keeps failing, I’d try more headroom:

openclaw config set agents.defaults.compaction.reserveTokensFloor 40000 --strict-json
openclaw config validate

If it still fails after confirming the live value and trying a fresh session, paste the output of:

[fickle lily]

openclaw --version
openclaw gateway status
openclaw config get agents.defaults.compaction
openclaw logs --tail 120

Docs: https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultscompaction

[static root]

{
"mode": "safeguard",
"reserveTokensFloor": 20000
}
But what exactly is this "Context" which is limited to 20000? Is 20000 words or 20000 tokens or 20000 seconds, what?

[fickle lily]

It’s tokens, not words or seconds.

“Context” means the chunk of text the model can see at once: system prompt, AGENTS/SOUL instructions, current conversation, tool results, file snippets, logs, images metadata, and the model’s own reply budget. Every model has a maximum context window.

reserveTokensFloor: 20000 does not mean “limit the conversation to 20,000 tokens.” It means: when OpenClaw compacts old conversation history, keep at least ~20,000 tokens of free headroom so the next model call has space for the summary, tool output, and reply.

Rough scale: 1 token is about 3-4 English characters, or around 0.75 words on average. So 20,000 tokens is roughly 15,000 words, but code/logs/JSON can tokenize differently.

Why it still matters: if your active session already contains a very large transcript or huge tool/log outputs, compaction can still fail even with a 20k reserve. In that case, start a fresh session with /new or reset the current one with /reset, then the reserve helps prevent the next session from getting wedged the same way.

[static root]

This feels like stupid limitation. What is the "cost" of just setting the limit to 200000 immediately?

[fickle lily]

Yeah, it feels dumb when you hit it. The catch is that reserveTokensFloor is not the context limit and setting it huge does not give the model more memory.

It is reserved empty space. So setting it to 200000 means “keep 200k tokens free for the next call.” The costs are:

• If your model context window is around 200k, reserving 200k leaves basically no room for conversation/history, so OpenClaw may compact constantly or fail earlier.
• It can make the assistant remember less, because more of the window must stay empty.
• It can increase latency/cost because compaction may run more often.
• It still will not save a session that is already too large or full of giant logs/tool outputs.

Practical range: try 24000, 40000, maybe 60000 if you keep hitting this. I would not jump to 200000 unless you are deliberately using a much larger-context model and understand that you’re trading retained history for headroom.

The real fixes are usually: start a fresh session with /new or /reset, avoid pasting huge logs wholesale, and use a model/config with a context window that matches the kind of long session you’re running.

[static root]

But isn't it so that everytime I use /reset or /new then I loose context and continuity in the dialog? Or is OpenClaw still able to pick up the context and continue an ongoing job the was interrupted when the context limit was exceeded?

[fickle lily]

Yes. /reset or /new loses the active conversation context for that session. OpenClaw does not magically keep full continuity after a reset.

What survives:

• Files changed on disk / repo state / Docker containers / external services
• Durable memory files, if the agent wrote anything there
• Config, auth, workspace files, logs, etc.
• The Discord thread itself is still visible to humans, but the fresh agent session may not have the whole prior transcript in its model context

What does not survive as reliable agent context:

• The detailed back-and-forth reasoning
• Tool outputs already seen by the old session
• The exact task state unless it was written somewhere durable

Normally, compaction is the mechanism that preserves continuity by summarizing old context. But if you hit “context limit exceeded” during/around compaction, that continuity path may already have failed. At that point a reset/new session is often the practical recovery, but you should seed it with a short handoff.

[fickle lily]

Best pattern before long work:

Please write a concise handoff note: goal, current state, files changed, commands run, remaining steps, blockers.

Then start /new and paste that handoff. If you’re already wedged, manually start the new session with a short recap plus any relevant file/log snippets. That’s annoying, but it’s much more reliable than trying to resurrect a session that can no longer fit enough context to compact.

[static root]

I see. One final comment; The job I'm asking the agent to run now, has been run several times earlier when I was using OpenClaw v2026.4.21 and I never ever ran into any Context Limit Exceeded errors! Now it happens all the time. What's changed? Why are thing so much more restricted after I updated to v2026.5.0 ?

[fickle lily]

Short answer: it is probably not intentionally “more restricted”; 5.x changed a lot of context/compaction plumbing, and some of that made OpenClaw more honest about context pressure. There have also been several 5.x fixes after the early 5.0-ish builds for repeated/failed compaction behavior.

The big categories that changed since 2026.4.21:

• Token accounting got stricter/more accurate. Older builds could undercount or carry stale token snapshots, so a job might appear fine until the provider/runtime eventually choked.
• Compaction paths changed. 5.x has more native/context-engine/Codex compaction handling, plus more guards around oversized transcripts and tool results.
• Some runtimes have smaller effective context than the marketing/model max. Especially Codex/native app-server style sessions: the runtime’s usable window can be smaller than the provider model’s theoretical window, so OpenClaw now tries to compact earlier.
• Early 5.x had bugs that caused repeated compaction pressure. The changelog after 5.0 includes fixes for things like repeated auto-compaction after every message, stale post-compaction token snapshots, oversized native threads surviving compaction, and wrong context-window budgeting.

So my recommendation is: don’t debug this forever on exactly 2026.5.0. Update to the newest stable/beta you’re comfortable with first, then retest with a fresh session:

openclaw --version
openclaw update
openclaw gateway restart

[fickle lily]

Then start a fresh job with /new and keep:

{
  agents: {
    defaults: {
      compaction: {
        mode: "safeguard",
        reserveTokensFloor: 40000,
      },
    },
  },
}

If it still reproduces on a current build, that’s worth a GitHub issue because “same workload worked on 2026.4.21, fails constantly on 2026.5.x” is actionable regression data. Include:

[fickle lily]

openclaw --version
openclaw config get agents.defaults.compaction
openclaw config get agents.defaults.model
openclaw config get agents.defaults.contextTokens
openclaw logs --tail 200

Issue tracker: https://github.com/openclaw/openclaw/issues

[static root]

Why is it that when I type openclaw config get agents.defaults.compaction I get:
{
"mode": "safeguard",
"reserveTokensFloor": 20000
}
But when I edit the file openclaw.json it says:
"workspace": "/home/node/.openclaw/workspace",
"contextTokens": 32000,
"compaction": {
"mode": "safeguard",
"reserveTokensFloor": 10000
},

[fickle lily]

That mismatch usually means you are not comparing the same layer/path.

openclaw config get ... reads the active config as OpenClaw resolved it. The file you opened may be:

• a different openclaw.json than the CLI is using
• the host copy while the Gateway/CLI is using the Docker container copy, or vice versa
• an included/source file while the active config path is somewhere else
• a stale file that was not actually loaded after restart

The /home/node/.openclaw/workspace path is a strong hint this is Docker/container-side config. Make sure the command and editor are looking at the same filesystem.

Run these from the same place you run openclaw config get:

openclaw config file
openclaw gateway status

[fickle lily]

echo "$OPENCLAW_CONFIG_PATH"
openclaw config get agents.defaults.compaction
openclaw config get agents.defaults.contextTokens

Then edit the exact file printed by openclaw config file. If you’re using Docker, run the commands inside the OpenClaw container or inspect the bind-mounted host file that maps to that container path.

Also: your shown config has:

"contextTokens": 32000

That is a small effective context budget. With reserveTokensFloor: 20000, you are leaving only about 12k tokens for prompt/history before compaction pressure. With 10000, you leave about 22k. So for a 32k context setup, pushing the reserve higher can make compaction happen much earlier. The better fix may be raising the model/runtime context window, not only raising the reserve.

If openclaw config file points to the same file and the file really says 10000 while config get still says 20000, paste the output of those commands plus your openclaw --version; that would be worth investigating as a config resolution bug.

[static root]

So how do I raise the model/runtime context window while keeping the reserveTokensFloor at 20000?

[fickle lily]

You raise the effective runtime context cap, but only up to what the selected model/provider actually supports.

In your config you showed:

"contextTokens": 32000

That is the immediate cap I’d change first. Keep reserveTokensFloor at 20000, and raise contextTokens:

openclaw config set agents.defaults.contextTokens 128000 --strict-json
openclaw config set agents.defaults.compaction.reserveTokensFloor 20000 --strict-json
openclaw config validate
openclaw gateway restart

[fickle lily]

Then verify:

openclaw config get agents.defaults.contextTokens
openclaw config get agents.defaults.compaction

Important: agents.defaults.contextTokens is an OpenClaw runtime budget/cap. It does not make a 32k model become a 128k model. If the actual model or local server only supports 32k, requests above that will still fail.

If you are using a custom/OpenAI-compatible/local provider and the model entry itself has contextTokens: 32000, update that model entry too. The relevant fields are under:

models.providers.<providerId>.models[].contextWindow
models.providers.<providerId>.models[].contextTokens

contextWindow is the model’s native window metadata. contextTokens is the effective runtime cap. For local/Ollama-style servers, you may also need to raise the server-side context setting for the model; OpenClaw cannot exceed what the server was launched/configured to allow.

[fickle lily]

Useful checks:

openclaw config get agents.defaults.model
openclaw config get agents.defaults.contextTokens
openclaw models status

For picking which model/provider gives you a larger real context window, use the docs and #models rather than guessing: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

Config reference: https://docs.openclaw.ai/gateway/configuration-reference

[static root]

So is ContextToken = 32000 and reserveTokensFloor = 20000 a well balanced combination using openai/gpt-5.2 ?

[fickle lily]

No, that is not well balanced.

With:

contextTokens = 32000
reserveTokensFloor = 20000

you are reserving ~62% of the whole runtime window as empty headroom. That leaves only about 12k tokens for system prompt + workspace context + conversation history + tool results before compaction pressure starts. For a tool-heavy OpenClaw job, that is tight and will compact/fail much sooner than you expect.

For a 32k effective context, I’d use something closer to:

openclaw config set agents.defaults.contextTokens 32000 --strict-json
openclaw config set agents.defaults.compaction.reserveTokensFloor 8000 --strict-json

[fickle lily]

or maybe 10000 if the job produces lots of tool output.

If you want to keep reserveTokensFloor = 20000, raise the effective context cap substantially, assuming your selected model/runtime really supports it:

openclaw config set agents.defaults.contextTokens 128000 --strict-json
openclaw config set agents.defaults.compaction.reserveTokensFloor 20000 --strict-json

Rule of thumb: reserve should be meaningful headroom, not most of the window. Around 20-30% reserve is a more reasonable starting point than 60%+.

Also, don’t rely only on the model name here. Check what OpenClaw is actually using:

openclaw config get agents.defaults.model
openclaw config get agents.defaults.contextTokens

[fickle lily]

openclaw models status

Model/context docs: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/gateway/configuration-reference

[static root]

That doesn't make sense. I had contextTokens = 32000 and reserveTokensFloor = 10000 originally until I began getting Context limit exceed error messages with recommendations to increase the floor to 20000 (or more)! Now you're saying I should reduce it to 8000 instead to get a better balance!

[fickle lily]

You’re right to call out the contradiction. The missing piece is that the warning text is generic and assumes a reasonably large context window. With your effective window capped at 32k, “raise reserve to 20k” is not automatically good advice.

Think of it as a tradeoff:

• Reserve too low: compaction may start too late, leaving no room to summarize/retry.
• Reserve too high: most of the 32k window is kept empty, so the agent has too little room for the actual task and compacts constantly.

So with 32k context, reserveTokensFloor: 10000 was already a reasonable-ish reserve. If you still hit context limit there, the real problem is probably not “reserve too low”. It’s more likely one of these:

1. The job simply does not fit well in a 32k effective context.
2. The existing session was already too large/wedged.
3. You’re on an early 5.x build with compaction/token-accounting regressions.
4. Tool/log output is blowing up the transcript.

For openai/gpt-5.2, I would not intentionally cap OpenClaw at 32k unless you have a reason. Better target:

[fickle lily]

openclaw config set agents.defaults.contextTokens 128000 --strict-json
openclaw config set agents.defaults.compaction.reserveTokensFloor 20000 --strict-json
openclaw config validate
openclaw gateway restart

That combination is much more coherent: ~20k reserve, ~108k usable prompt/history/tool space.

If you must keep contextTokens: 32000, then I’d keep reserve around 8000-10000, not 20000. But that may still fail for long tool-heavy jobs because 32k is just tight for agentic work.

[static root]

How can I verify that setting contextTokens to 128000 is valid?

[fickle lily]

There are two different “valid” checks:

1. Config validity: will OpenClaw accept the setting?
2. Runtime validity: will the selected model/provider actually tolerate that much context?

For config validity:

openclaw config set agents.defaults.contextTokens 128000 --strict-json
openclaw config validate
openclaw config get agents.defaults.contextTokens

If validation passes and config get prints 128000, the config is syntactically valid.

For runtime/model validity, check what model you’re actually using and what OpenClaw reports:

[fickle lily]

openclaw config get agents.defaults.model
openclaw models status
openclaw status --all

Then do a practical smoke test in a fresh session:

/new Please reply with a short OK after checking your current runtime/status context.

If the model/provider can’t handle the larger effective window, you’ll usually see provider errors in:

openclaw logs --tail 200

[fickle lily]

Important caveat: openclaw config validate can prove “this config key/value is allowed.” It cannot prove the upstream provider truly supports 128k. That depends on the selected model, auth path, provider adapter, and sometimes server-side settings for local/OpenAI-compatible providers.

[static root]

OpenClaw does not recognize option "--tail"

[fickle lily]

You’re right, my command was wrong. The logs command uses --limit, not --tail.

Use:

openclaw logs --limit 200

or to watch live logs:

openclaw logs --follow

For JSON logs:

[fickle lily]

openclaw logs --limit 200 --json

If the Gateway RPC is down, use the raw file fallback from the docs:

tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Sorry for the bad flag there.