Skip to content

fix: cap effective session context window by known model limit#152

Open
BingqingLyu wants to merge 11 commits into
mainfrom
fork-pr-39859-fix-status-context-window-cap
Open

fix: cap effective session context window by known model limit#152
BingqingLyu wants to merge 11 commits into
mainfrom
fork-pr-39859-fix-status-context-window-cap

Conversation

@BingqingLyu

@BingqingLyu BingqingLyu commented Apr 27, 2026

Copy link
Copy Markdown
Owner

Fixes openclaw#39857

Summary

  • Problem: resolveContextTokensForModel() could return an override value even when OpenClaw already knew the selected model's smaller context window.
  • Why it matters: that inflated value could be persisted into session metadata and surfaced in /status, so OpenClaw would over-report the effective context window for the active model.
  • What changed: when both values are known, the effective window is now min(override, modelWindow); provider aliases are also normalized before reading configured model windows.
  • What did NOT change: if the model window is unknown, override behavior stays the same; this does not change provider-side request limits or widen any model window.

Problem

This was a correctness bug in the effective context-window resolver, not just a display nit.

Before this PR, the resolver could treat agents.defaults.contextTokens (or another context override) as authoritative even when the selected model's real window was already known and smaller.

That meant OpenClaw could persist and report a context window that the active model does not actually have.

Affected paths include places that read the resolved contextTokens, such as:

  • session store metadata
  • /status
  • other callers that rely on persisted/effective session context

Example

If a user sets:

  • agents.defaults.contextTokens: 1048000

and then uses a model whose known context window is smaller, OpenClaw could previously keep reporting 1048000 instead of the model's real effective limit.

The correct result is the smaller effective window.

Fix

The functional change is intentionally narrow:

  • if an override exists and the selected model window is also known, return the smaller value
  • if the model window is unknown, preserve the previous override behavior
  • when reading configured model windows from cfg.models.providers, normalize provider names first so aliases like bedrock still match configured entries like amazon-bedrock

Why this is safe

This is fail-safe and correctness-preserving:

  • it only removes overstatement
  • it never increases an effective context window
  • it does not change behavior when OpenClaw does not know the model's real window

Validation

  • bunx vitest run src/agents/context.test.ts src/agents/models-config.merge.test.ts
  • bunx vitest run src/plugins/loader.test.ts
  • pnpm check

Scope note

A few later commits in this PR are CI-only follow-ups caused by main moving during review. The product fix itself remains limited to effective context-window resolution and regression coverage for that bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Status/session context window can over-report the selected model's actual window

2 participants