Everything runs fine for short conversations. Then you hit a longer session and OpenClaw stops with this:
This is not a normal rate limit. A real rate limit would also hit your short sessions. This 429 fires only when a session grows long enough to use Anthropic’s 1 million token context path, and your credential is not eligible for that path. It is a context eligibility error wearing a rate limit costume. Here is what is happening and the three ways to fix it.
Before you chase the wrong fix, confirm you have the long-context variant and not an ordinary quota hit. A plain Anthropic 429 means your rate limit or usage cap for the current window is exhausted, on every session, short or long, until the window resets or you raise the limit in the Anthropic Console. The long-context variant is the one with the specific wording above, and it is selective: short sessions are untouched. If you see the exact phrase Extra usage is required for long context requests, keep reading. If you see a plain rate limit message on everything, the fix is quota, not context configuration: check your usage window and plan.
Why it only happens on long sessions
Claude models with a 1M context window are now GA on several models: Opus 4.6, 4.7, and 4.8, plus Sonnet 4.6 (and the Sonnet 5 family models). OpenClaw detects these models and sizes them for the 1M window automatically. Requests that need more than the standard window go down Anthropic’s long-context path, and Anthropic enforces that path at the credential level: your API key or subscription must be eligible for long-context usage. If it is not, Anthropic answers with the 429 the moment a request tries to use that path.
Short sessions never trigger it because they fit inside the standard context window and never reach the long-context path. Only longer sessions cross the threshold, which is why the error feels random and session-dependent.
One piece of history worth knowing if you are reading older guides: earlier OpenClaw versions had a params.context1m: true flag that sent a beta header to enable this path, and older advice was to toggle it. That mechanism is retired. OpenClaw no longer sends the context-1m-2025-08-07 beta header, the flag is a harmless no-op on GA 1M models, and OpenClaw drops the retired header from older config automatically. If you still have context1m: true in a config entry for an older, non-GA model, removing it just stops that model from being treated as 1M capable. The eligibility requirement on the credential is unchanged either way.
Step 1: Confirm what is active
Check the logs for the 429, then look at which model is the default and what your fallback chain looks like:
Two useful facts live in this output. The Default line names the model every normal session uses; if it is a 1M-capable Claude model, long sessions will try the 1M path. The Fallbacks line shows the chain OpenClaw tries when the primary model is rejected, which is exactly the safety net this error calls for. Your model entries live under agents.defaults.models in config, and the fallback chain under agents.defaults.model.fallbacks:
# Where the pieces live in ~/.openclaw/openclaw.json agents: { defaults: { models: { "anthropic/claude-opus-4-6": {} }, model: { fallbacks: ["anthropic/claude-sonnet-5", "openai/gpt-5.4"] } } }
Fix option 1: Use the standard context window
The simplest fix is to stop using the 1M path for everyday work. Switch the default model to one with a standard window, or, if an older config entry still carries params.context1m: true on a model that is not GA-capable for 1M, remove the flag. For most personal setups the standard window is more than enough, and you keep the 1M models around for the rare sessions that genuinely need them.
Fix option 2: Use an eligible credential
If you genuinely need the 1M path, the credential attached to the model must have long-context access enabled on your Anthropic account. New setups should use an Anthropic API key rather than OAuth subscription tokens when long context matters: subscription token auth keeps its required beta headers, but eligibility is still enforced per credential. Confirm long-context access on your account before pointing OpenClaw at a 1M model.
Fix option 3: Configure model fallbacks
Fallbacks are the belt-and-suspenders fix and they cost nothing when everything works. If the primary model answers with a 429, OpenClaw retries the same request on the next model in the chain, and your session continues instead of dying mid-thought. The example above shows the shape; on this author’s machine the chain reads deepseek/deepseek-v4-flash, moonshot/kimi-k2.6, ollama/llama3.2 behind the default. Pick a sensible order: a strong model you trust for most work, then a cheaper or more available one for the fallback. The diagram shows how the three options fit together:
Step 2: Apply and verify
After any model change, restart the gateway and re-check the chain:
Then reproduce the condition that failed before: open a long session, or run the task that hit the 429, and watch the logs. A clean run means the request either stayed on the standard window or the fallback absorbed the rejection. If the 429 still appears on the default model with no fallback kicking in, confirm the fallback list is on the agent actually running the session; per-agent model.fallbacks overrides the defaults chain.
One more check that catches people with multiple agents: model fallbacks can be overridden per agent. The defaults chain at agents.defaults.model.fallbacks applies everywhere unless a specific agent under agents.list carries its own model.fallbacks entry, in which case that agent ignores the defaults chain entirely. If the agent that hit the 429 has its own model block, edit that agent’s entry, not the defaults. On this author’s machine every agent inherits the shared three-model chain, which is the simpler setup to maintain.
Quick reference
# See the 429 and what triggered it openclaw logs --follow # Check default model and fallback chain openclaw models status openclaw config get agents.defaults.models # Apply model changes openclaw gateway restart
Related fixes
Model behavior is config, so if edits do not seem to stick, check CLI vs gateway config mismatches, and if the trouble started right after an update, roll back safely. For the full picture of how models, memory, and token use fit together, see The Complete OpenClaw Guide.
Not Ready to Self-Host? Try ClawTrust
Building agents locally is powerful, but managing infrastructure, security, and scaling takes effort. ClawTrust provides managed OpenClaw hosting: your agents run securely in the cloud with automatic scaling, no DevOps overhead, and 24/7 monitoring.
This post contains affiliate links. If you buy through them, I may earn a small commission at no extra cost to you.
About The Author
