OpenClaw Adds a Claude Context-Window Switch for Claude Code Models

Claude Code models expose two context windows — a 200K standard tier and a 1M extended tier selected through a [1m] model-id suffix and an environment toggle — but until this merge OpenClaw had no way to express that choice. Every Claude session ran at whatever the runtime defaulted to, and operators paying attention to cost versus capacity had no control surface. PR #127951, merged to main on August 22, 2026, closes that gap with a generic mechanism rather than a Claude-specific hack.

What actually landed

Three pieces shipped together:

1. A generic catalog surface. Model catalog entries gain optional contextWindows plus a contextWindowDefault, normalized through the same pipeline that already handles thinking levels. Any provider plugin can declare selectable windows; Anthropic’s plugin happens to be the first consumer.
2. Protocol and validation. The Gateway protocol carries the selection, and session create/patch endpoints validate it, so a window choice is a first-class piece of session state rather than an undocumented string convention.
3. A Control UI switch. The model picker shows a 200K/1M selector for Claude CLI 5-series models. The mapping is explicit: choosing 1M selects the [1m] model-id variant, with the documented disable-toggle honored when set in the runtime environment.

Why the design matters

Interpretation: the important word in the changelog is declared. Because windows are plugin-declared catalog data, a future model or provider with different tiers slots into existing UI and validation instead of growing another bespoke code path. For operators, that means the switch you learn today is the same one you’ll use for whatever tiers land next.

It also moves context-window choice from ambient configuration to per-session state. Two sessions on the same agent can now run different windows deliberately — which cuts both ways.

Operator actions

1. Decide your default posture before upgrading. If you run mostly short interactive sessions, standard 200K remains the sane default; the 1M tier exists for long-context work like whole-repo analysis or very large document sets.
2. Treat the 1M tier as a cost decision, not just a capability. Extended-context requests price differently; a stray click in the picker can move a session onto a materially more expensive path. Check how your billing surfaces the difference after switching.
3. Audit automation that creates sessions programmatically. Anything calling sessions.create/patch should either pin the window explicitly or tolerate users changing it in the UI.
4. Verify on your build. This is a main merge with a compatibility-flag from upstream review; confirm your deployment contains commit 041938b before expecting the picker switch to appear, especially if you run a pinned release line.

Limits worth stating plainly

This change governs selection of the window. It does not change what happens when a session approaches its chosen limit — compaction and truncation behavior remain as they were. It also does not add 1M support to models whose underlying runtime lacks it; the switch appears for Claude CLI 5-series models because their runtime supports both tiers.

Bottom line

If you run Claude Code models through OpenClaw, you finally get explicit control over the 200K/1M tradeoff, validated at session level instead of encoded in model-name folklore. Upgrade when the build reaches your channel, look at the picker once, and make sure whoever pays the API bill knows the bigger number is now one click away.