Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bug: contextTokens/status can use wrong context window when same model id exists across providers [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#49355•Fetched 2026-04-08 00:56:02
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
cchen7cchen7
Participants
cchen7cchen7Hollychou924Hollychou924
Timeline (top)
cross-referenced ×2commented ×1referenced ×1

When the same bare model id exists under multiple providers with different contextWindow values, OpenClaw can persist the wrong contextTokens / status denominator for sessions.

In our local setup:

  • azure/gpt-5.4 had contextWindow: 1000000
  • github-copilot/gpt-5.4 had contextWindow: 400000

Actual runtime/model selection for the session used azure/gpt-5.4, but newly created sessions under the main agent still persisted contextTokens: 400000, and /status showed .../400k.

Root Cause

Suspected root cause

A context-window cache path appears to use the bare model id as the cache key instead of a provider-qualified key.

Fix Action

Workaround

We fixed it locally by removing the unused duplicate model entry (github-copilot/gpt-5.4). After that, new sessions correctly showed .../1000k.

PR fix notes

PR #61860: fix(context): make session context-window lookup provider-aware

Description (problem / solution / changelog)

What changed

This makes session context-window lookup provider-aware in the remaining runtime paths that still resolved by bare model id.

Changed paths:

  • src/auto-reply/reply/directive-handling.persist.ts
  • src/auto-reply/reply/agent-runner.ts
  • src/auto-reply/reply/followup-runner.ts
  • src/auto-reply/reply/memory-flush.ts
  • src/auto-reply/reply/agent-runner-memory.ts

Why

OpenClaw can be configured with the same model id under multiple providers, for example:

  • litellm/gpt-5.4
  • openai-codex/gpt-5.4

When some session/runtime paths look up context windows by the bare model id (gpt-5.4) instead of the provider-qualified identity, they can pick up the wrong provider's context window.

That can corrupt session state and compaction decisions. In our production repro, a litellm/gpt-5.4 session could inherit the openai-codex/gpt-5.4 context window.

Root cause

resolveContextTokensForModel(...) already exists and is provider-aware, but a few reply/session paths were still using:

  • lookupCachedContextTokens(model)
  • lookupContextTokens(modelUsed)
  • lookupContextTokens(modelId)

Those calls lose provider identity and can mis-handle same-named models across providers.

Related issue

  • #49355

Validation

Passed targeted tests:

  • pnpm exec vitest run src/auto-reply/reply/directive-handling.model.test.ts src/auto-reply/reply/reply-state.test.ts

I also tried full-repo typecheck / pre-commit checks, but upstream main currently has unrelated existing type failures in other areas (commands/status*, discord, security, etc.), so this PR keeps validation focused on the touched invariant.

Scope intentionally excluded

This PR does not include the later local follow-ups around:

  • post-compaction snapshot persistence
  • /status stale pre-compaction totals
  • /new or /reset usage/cache cleanup

Those are separate issues and should be reviewed independently.

Changed files

  • src/auto-reply/reply/agent-runner-memory.ts (modified, +6/-2)
  • src/auto-reply/reply/agent-runner.ts (modified, +7/-2)
  • src/auto-reply/reply/directive-handling.model.test.ts (modified, +34/-0)
  • src/auto-reply/reply/directive-handling.persist.ts (modified, +9/-2)
  • src/auto-reply/reply/followup-runner.ts (modified, +10/-3)
  • src/auto-reply/reply/memory-flush.ts (modified, +11/-2)
  • src/auto-reply/reply/reply-state.test.ts (modified, +23/-0)
RAW_BUFFERClick to expand / collapse

OpenClaw Issue Draft

Title

Bug: contextTokens/status can use wrong context window when same model id exists across providers

Body

Summary

When the same bare model id exists under multiple providers with different contextWindow values, OpenClaw can persist the wrong contextTokens / status denominator for sessions.

In our local setup:

  • azure/gpt-5.4 had contextWindow: 1000000
  • github-copilot/gpt-5.4 had contextWindow: 400000

Actual runtime/model selection for the session used azure/gpt-5.4, but newly created sessions under the main agent still persisted contextTokens: 400000, and /status showed .../400k.

User-visible symptoms

  • /status for new sessions shows 400k even though the active model is effectively 1M.
  • If the real conversation grows past 400k tokens, /status percentage can become >100% even before the model actually hits its real limit.
  • This affects newly created sessions (DM + channel sessions), not just one stale historical session.

Suspected root cause

A context-window cache path appears to use the bare model id as the cache key instead of a provider-qualified key.

Relevant behavior we observed in the built code:

  • configured/discovered context windows are cached by model.id
  • later providers can overwrite earlier providers for the same bare id
  • session usage persistence later does lookupContextTokens(modelUsed) where modelUsed is the bare model id (gpt-5.4)

So if two providers both expose gpt-5.4, whichever one is written later can win, even when the active session provider is different.

Why this seems inconsistent

Other paths still resolve the model correctly with provider context:

  • openclaw models list showed azure/gpt-5.4 as 1000000
  • openclaw status overview also showed default gpt-5.4 (1000k ctx)
  • but session /status and persisted sessions.json entries showed 400000

So there appear to be at least two resolution paths:

  1. provider-aware path (correct)
  2. bare-model cache path (wrong)

Workaround

We fixed it locally by removing the unused duplicate model entry (github-copilot/gpt-5.4). After that, new sessions correctly showed .../1000k.

Suggested fix

Use provider-qualified cache keys for context-window lookup/persistence paths, e.g.:

  • azure/gpt-5.4
  • github-copilot/gpt-5.4

instead of bare gpt-5.4.

This should make session status and persisted contextTokens align with the actual active provider/model.

extent analysis

Fix Plan

To resolve the issue, we need to update the cache key for context-window lookup and persistence paths to use provider-qualified model IDs.

Steps:

  • Update the lookupContextTokens function to use the provider-qualified model ID instead of the bare model ID.
  • Modify the cache key generation to include the provider name, e.g., azure/gpt-5.4 instead of just gpt-5.4.
  • Ensure that the cache is updated correctly when a new provider is added or an existing one is modified.

Example Code:

# Before
def lookupContextTokens(model_id):
    cache_key = model_id
    # ...

# After
def lookupContextTokens(provider, model_id):
    cache_key = f"{provider}/{model_id}"
    # ...

# Usage
provider = "azure"
model_id = "gpt-5.4"
context_tokens = lookupContextTokens(provider, model_id)

Verification

To verify that the fix worked, create a new session with a model that has multiple providers with different contextWindow values. Check that the /status endpoint and the persisted sessions.json entries show the correct contextTokens value for the active provider.

Extra Tips

  • Make sure to update all relevant code paths that use the cache key for context-window lookup and persistence.
  • Consider adding a test case to ensure that the fix works correctly for different scenarios, such as adding or removing providers.
  • Review the cache implementation to ensure that it correctly handles provider-qualified cache keys and updates the cache accordingly.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#optimization#mixed precision#training loop#device allocation#model download

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Bug: contextTokens/status can use wrong context window when same model id exists across providers [1 pull requests, 1 comments, 2 participants]