Summary

resolveContextTokensForModel() can over-report the effective context window for the selected model.

If an override such as agents.defaults.contextTokens is larger than the model's known context window, OpenClaw can persist and display the larger override instead of the model's real effective limit.

This is a correctness bug, not just a wording/UI issue.

Why this is a bug

When OpenClaw already knows both:

• an override value, and
• the selected model's actual window,

then the effective session context window should be the smaller of the two.

Today the override can win even when it is larger, so OpenClaw ends up storing/reporting a value the model does not actually have.

User-visible impact

This can mislead both users and downstream logic that relies on resolved contextTokens, including:

• /status
• persisted session metadata
• follow-up/tooling paths that read the stored effective session window

So the bug is not that a config value is large by itself; the bug is that OpenClaw can treat that larger override as the model's effective window even when the model limit is already known and smaller.

Concrete example

1. Set agents.defaults.contextTokens: 1048000.
2. Use a model whose known context window is lower than that.
3. Run a turn and inspect /status or session metadata.

Actual

OpenClaw can persist/report the larger override value as contextTokens.

Expected

When both values are known, effective context should be:

• min(override, modelWindow)

In other words, agents.defaults.contextTokens should behave like a ceiling on effective context, not a forced replacement for a smaller known model limit.

Scope boundary

This issue is about effective window resolution and reporting/persistence correctness.

It is not claiming that OpenClaw should invent a model limit when none is known, and it is not asking to change provider-side request limits beyond using the correct effective window once it is already known.