Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openclaw 2026.4.5 When multiple providers expose the same model id but with different contextWindow / contextTokens, OpenClaw may persist the wrong context limit into the session store.

Steps to reproduce

 In my case, several providers exposed the same model id, but one provider had a larger configured context window than the others.  After switching the session to the provider with the larger context window, /status still showed the smaller limit, and the persisted session entry contained:  { "contextTokens": 200000 }  Even though the active runtime model was using a provider configuration with a larger context window.  This appears to be caused by some context token lookup / cache paths still using the bare model id rather than a provider-qualified key.  Why this matters  This is not just a /status display issue.  A wrong persisted contextTokens value can affect:

• /status context usage display
• session metadata correctness
• compaction / safeguard thresholds
• memory flush / headroom decisions
• long-running conversation behavior  If a larger real context window is persisted as a smaller one, OpenClaw may become overly conservative and trigger compaction / flush earlier than necessary. Config setup Use multiple providers with the same model id but different context windows.  For example:
• provider A: same model id, smaller context window
• provider B: same model id, larger context window  Steps

1. Start with a session using a provider whose model has the smaller context window.
2. Switch the session to another provider exposing the same model id but with a larger context window.
3. Send at least one normal message so the session metadata gets updated.
4. Run /status.
5. Inspect the session store entry in sessions.json.  Observed

• Active runtime model is the provider with the larger context window
• /status may still show the smaller context window
• persisted session entry may still contain something like:  { "contextTokens": 200000 }

Expected behavior

• /status should show the correct context window for the active runtime provider/model
• persisted sessionEntry.contextTokens should match the resolved context window for the active provider/model
• same bare model ids across providers should not contaminate each other

Actual behavior

When multiple providers expose the same model id but with different contextWindow / contextTokens, OpenClaw may persist the wrong context limit into the session store.  In my case, several providers exposed the same model id, but one provider had a larger configured context window than the others.  After switching the session to the provider with the larger context window, /status still showed the smaller limit, and the persisted session entry contained:  { "contextTokens": 200000 }  Even though the active runtime model was using a provider configuration with a larger context window.  This appears to be caused by some context token lookup / cache paths still using the bare model id rather than a provider-qualified key.

Root cause analysis  From tracing the compiled runtime, there appear to be mixed lookup strategies.  Some paths correctly resolve by provider + model There are paths using something like:  resolveContextTokensForModel({ cfg, provider, model, ... })  which can correctly prefer provider-qualified resolution.  But some paths still use bare model lookups. Examples found in the distributed build include logic equivalent to:  lookupCachedContextTokens(model) lookupContextTokens(modelUsed) lookupContextTokens(resolved.model)  where only the bare model id is used.  One especially problematic path is equivalent to:  contextTokens: agentCfg?.contextTokens ?? lookupCachedContextTokens(model) ?? 2e5  If the cache is keyed or reused by bare model id, then one provider's context value can leak into another provider's session metadata.

OpenClaw version

2026.4.5

Operating system

debian12

Install method

No response

Model

glm5、minimax-m2.7

Provider / routing chain

openclaw-minimax

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Additional concern  I also found that /status tends to prefer persisted session values in some cases, so once a wrong contextTokens value gets written into the session entry, it can continue to override or distort later display.  So the problem seems to be a combination of:

1. bare-model context lookup / cache collisions
2. incorrect session persistence
3. status/runtime precedence rules that keep showing the stale value