fix: use provider-qualified key in MODEL_CACHE for context window lookup by linwebs · Pull Request #15632 · openclaw/openclaw

linwebs · 2026-02-13T17:43:47Z

Summary

Problem: When multiple providers define the same model ID with different context windows, /status and compaction logic show/use the wrong context window for the non-last-loaded provider.
Why it matters: Users running e.g. provider-1/claude-4.6-sonnet (200k) and provider-2/claude-4.6-sonnet (1M) would see both show 1.0m, causing premature compaction on the 1M provider and incorrect status display on the 200k one.
What changed: applyConfiguredContextWindows now writes only bare model-id keys to MODEL_CACHE. Call sites with provider info (get-reply-directives, memory-flush, agent-runner-memory) now call resolveContextTokensForModel with the full cfg, which scans models.providers directly to disambiguate same-named models across providers. resolveContextTokens in model-selection.ts reverted to remove the now-unused provider param.
What did NOT change: Discovery cache entries (OpenRouter slash-path keys), overall context resolution priority chain, API contracts, config schema.

Change Type (select all)

Bug fix

Scope (select all touched areas)

Gateway / orchestration
Memory / storage

Linked Issue/PR

Closes MODEL_CACHE silently overwrites context windows on provider conflicts (last-write-wins) #11629

User-visible / Behavior Changes

/status now displays the correct context window when the same model ID exists across multiple providers with different limits.
Compaction threshold is now computed from the actual provider's configured context window instead of the last-written cache entry.

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No

Repro + Verification

Environment

OS: Linux (Ubuntu 24.04)
Runtime/container: Node 22, local gateway
Model/provider: provider-1/claude-4.6-sonnet (200k), provider-2/claude-4.6-sonnet (1M)
Relevant config: Two providers sharing claude-4.6-sonnet and claude-4.6-opus with different contextWindow values

Steps

Configure two providers with the same model ID but different contextWindow in openclaw.json
/model provider-1/claude-4.6-sonnet → /status
/model provider-2/claude-4.6-sonnet → /status

Expected

provider-1/claude-4.6-sonnet → tokens xx/200k
provider-2/claude-4.6-sonnet → tokens xx/1.0m

Actual (after fix)

provider-1/claude-4.6-sonnet → tokens 19k/200k (9%) ✅
provider-2/claude-4.6-sonnet → tokens 18k/1.0m (2%) ✅

Evidence

Trace/log snippets (TUI status bar confirmed above)

Human Verification (required)

Verified scenarios: Both claude-4.6-sonnet and claude-4.6-opus tested across two providers via TUI. Context window displayed correctly in status bar for each provider. Messages sent to both providers successfully.
Edge cases checked: Confirmed MODEL_CACHE bare-key entries for discovery (OpenRouter slash-path IDs) are not affected by the change; resolveContextTokensForModel falls through to bare cache key when config scan finds no match.
What I did not verify: Agents using contextTokens global override; OpenRouter provider with slash-containing model IDs in live environment.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

(Both Greptile review threads from the previous commit are resolved. The issues they identified — unguarded undefined/model lookup and provider mismatch in persistRunSessionUsage — no longer exist in the current code because the qualified-key-in-cache approach has been replaced entirely.)

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No

Failure Recovery (if this breaks)

How to disable/revert: git revert f5dcd2409
Files/config to restore: None
Known bad symptoms: If context windows regress to always showing the last-loaded provider's value, this commit is the first place to check.

Risks and Mitigations

Risk: resolveContextTokensForModel scans cfg.models.providers on every call instead of reading from cache.
- Mitigation: Config is an in-memory object; scan cost is O(providers × models) and negligible compared to API roundtrip latency.

greptile-apps

_{14 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

src/auto-reply/reply/agent-runner.ts

greptile-apps · 2026-02-13T17:46:21Z

Additional Comments (1)

src/auto-reply/reply/followup-runner.ts
Persisted provider mismatch
providerUsed is computed from runResult.meta.agentMeta?.provider ?? fallbackProvider and used to compute contextTokensUsed, but persistRunSessionUsage is called with providerUsed: fallbackProvider (not the providerUsed variable). If the agent meta provider differs from the fallback provider, the session store will persist modelProvider for one provider while contextTokensUsed came from another, which can reintroduce incorrect context-window resolution on subsequent /status/session views.

        await persistRunSessionUsage({
          storePath,
          sessionKey,
          usage,
          lastCallUsage: runResult.meta.agentMeta?.lastCallUsage,
          promptTokens,
          modelUsed,
          providerUsed,
          contextTokensUsed,
          logLabel: "followup",
        });

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/auto-reply/reply/followup-runner.ts
Line: 198:216

Comment:
**Persisted provider mismatch**
`providerUsed` is computed from `runResult.meta.agentMeta?.provider ?? fallbackProvider` and used to compute `contextTokensUsed`, but `persistRunSessionUsage` is called with `providerUsed: fallbackProvider` (not the `providerUsed` variable). If the agent meta provider differs from the fallback provider, the session store will persist `modelProvider` for one provider while `contextTokensUsed` came from another, which can reintroduce incorrect context-window resolution on subsequent `/status`/session views.

```suggestion
        await persistRunSessionUsage({
          storePath,
          sessionKey,
          usage,
          lastCallUsage: runResult.meta.agentMeta?.lastCallUsage,
          promptTokens,
          modelUsed,
          providerUsed,
          contextTokensUsed,
          logLabel: "followup",
        });
```

How can I resolve this? If you propose a fix, please make it concise.

linwebs · 2026-02-13T18:00:52Z

This PR fixes the issue described in #11629 — MODEL_CACHE now uses provider-qualified keys (provider/model) so same-named models across different providers retain their correct context window values.

Closes #11629

…kup (cherry-pick PR openclaw#15632)

openclaw-barnacle · 2026-02-21T04:01:33Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

openclaw-barnacle · 2026-03-12T04:16:52Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

…ll sites applyConfiguredContextWindows now stores provider-qualified keys (e.g. "rdsec/claude-4.6-sonnet") in MODEL_CACHE alongside the bare model id fallback, using normalizeProviderId so the key format is consistent with resolveContextTokensForModel's lookup logic. All call sites that have provider info now prefer provider-qualified lookups: - agent-runner, followup-runner, directive-handling.persist: switched to resolveContextTokensForModel (direct config scan + qualified cache) - cron/isolated-agent/run, gateway/session-utils, commands/sessions: same migration to resolveContextTokensForModel - resolveContextTokens (model-selection), resolveMemoryFlushContextWindowTokens (memory-flush): added optional provider param with normalizeProviderId-based qualified lookup before bare id fallback (no cfg available at these sites) - get-reply-directives, agent-runner-memory: pass provider through to the above utilities Matches the provider-aware approach already applied to session-store.ts and status.ts in upstream. Fixes incorrect context window display and compaction timing when the same model id is configured across multiple providers with different context limits.

applyConfiguredContextWindows now writes only bare model-id keys to MODEL_CACHE, reserving the provider-qualified key space exclusively for raw discovery entries (e.g. OpenRouter slash-paths). Call sites that need per-provider disambiguation (get-reply-directives, memory-flush, agent-runner-memory) now call resolveContextTokensForModel with the full cfg so they scan models.providers directly, rather than relying on a qualified cache key that was never reliably populated. resolveContextTokens in model-selection.ts reverted to remove the now- unused provider param; resolveMemoryFlushContextWindowTokens accepts cfg and delegates to resolveContextTokensForModel.

linwebs · 2026-03-13T16:29:44Z

Revised approach in 80b8160: instead of writing provider-qualified keys into MODEL_CACHE (which corrupted discovery entries for OpenRouter-style slash-path model IDs), call sites that need per-provider disambiguation now call resolveContextTokensForModel with the full cfg and scan models.providers directly.

Both previous Greptile review threads are resolved — the issues they flagged no longer exist in the new code.

CI failure in src/cron/isolated-agent.delivers-response-has-heartbeat-ok-but-includes.test.ts is pre-existing in upstream main and unrelated to this PR.

@greptileai review

greptile-apps · 2026-03-13T16:33:49Z

Greptile Summary

This PR fixes a multi-provider context-window collision bug where two providers sharing the same model ID (e.g. claude-4.6-sonnet) would both display and compute the context window of whichever provider was loaded last. The fix has two parts: applyConfiguredContextWindows is changed to write only bare model-id keys to MODEL_CACHE (preventing synthetic config writes from corrupting the slash-keyed discovery entries), and a new resolveContextTokensForModel helper is introduced that scans cfg.models.providers directly when a provider is known, completely bypassing the stale bare-key cache for provider-qualified lookups.

All ten call sites (get-reply-directives, agent-runner, followup-runner, agent-runner-memory, memory-flush, directive-handling.persist, cron/isolated-agent/run, sessions, session-utils) are consistently migrated to resolveContextTokensForModel.
followup-runner.ts additionally corrects providerUsed to prefer the actual post-fallback provider from agentMeta rather than always using fallbackProvider.
resolveContextTokens in model-selection.ts is now dead code — its only call site was removed in this PR and the function can be deleted.
The lookupContextTokens mock in run.test-harness.ts is now only reached via resolveContextTokensForModel's fallback path; tests that rely on a fixed 128 k return value should also mock resolveContextTokensForModel directly to remain reliable.

Confidence Score: 4/5

Safe to merge — the logic is correct and human-verified; minor dead code and a potentially stale test mock are the only remaining loose ends.
The core fix is well-reasoned and cleanly implemented across all call sites. The resolveContextTokensForModel function correctly handles the provider-qualified vs. bare-key distinction with appropriate guards. Two minor housekeeping items lower the score slightly: resolveContextTokens in model-selection.ts is now dead code and should be removed, and the lookupContextTokens mock in run.test-harness.ts may not reliably cover the changed code path in run.ts, potentially leaving a test gap.
src/auto-reply/reply/model-selection.ts (dead resolveContextTokens export), src/cron/isolated-agent/run.test-harness.ts (stale mock)

Comments Outside Diff (2)

src/auto-reply/reply/model-selection.ts, line 603-610 (link)

resolveContextTokens is now dead code

After this PR removes its only import in get-reply-directives.ts, resolveContextTokens has no remaining callers in the codebase (confirmed via grep — only the definition in this file remains). It can be deleted to avoid confusion for future contributors who might wonder whether it's intentionally kept.
src/cron/isolated-agent/run.test-harness.ts, line 124-130 (link)

Stale mock may silently pass through real config scan

run.ts now calls resolveContextTokensForModel (real implementation, since ...actual is spread) instead of lookupContextTokens directly. The mocked lookupContextTokens is only reached by resolveContextTokensForModel as a late fallback — after resolveConfiguredProviderContextWindow scans the test's cfg. If a test's cfg object has a matching contextWindow entry, the mock is never reached and the expected 128 000 may not be returned.

Consider adding resolveContextTokensForModel to the mock so the return value is stable regardless of the cfg fixture:
```
vi.mock("../../agents/context.js", async (importOriginal) => {
  const actual = await importOriginal<typeof import("../../agents/context.js")>();
  return {
    ...actual,
    lookupContextTokens: vi.fn().mockReturnValue(128000),
    resolveContextTokensForModel: vi.fn().mockReturnValue(128000),
  };
});
```

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/auto-reply/reply/model-selection.ts
Line: 603-610

Comment:
**`resolveContextTokens` is now dead code**

After this PR removes its only import in `get-reply-directives.ts`, `resolveContextTokens` has no remaining callers in the codebase (confirmed via grep — only the definition in this file remains). It can be deleted to avoid confusion for future contributors who might wonder whether it's intentionally kept.

```suggestion
// (delete lines 603-610)
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/cron/isolated-agent/run.test-harness.ts
Line: 124-130

Comment:
**Stale mock may silently pass through real config scan**

`run.ts` now calls `resolveContextTokensForModel` (real implementation, since `...actual` is spread) instead of `lookupContextTokens` directly. The mocked `lookupContextTokens` is only reached by `resolveContextTokensForModel` as a late fallback — after `resolveConfiguredProviderContextWindow` scans the test's cfg. If a test's cfg object has a matching `contextWindow` entry, the mock is never reached and the expected 128 000 may not be returned.

Consider adding `resolveContextTokensForModel` to the mock so the return value is stable regardless of the cfg fixture:

```ts
vi.mock("../../agents/context.js", async (importOriginal) => {
  const actual = await importOriginal<typeof import("../../agents/context.js")>();
  return {
    ...actual,
    lookupContextTokens: vi.fn().mockReturnValue(128000),
    resolveContextTokensForModel: vi.fn().mockReturnValue(128000),
  };
});
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 80b8160}

openclaw-barnacle · 2026-03-19T04:09:25Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

openclaw-barnacle · 2026-03-23T04:12:29Z

Closing due to inactivity.
If you believe this PR should be revived, post in #pr-thunderdome-dangerzone on Discord to talk to a maintainer.
That channel is the escape hatch for high-quality PRs that get auto-closed.

greptile-apps bot reviewed Feb 13, 2026

View reviewed changes

src/auto-reply/reply/agent-runner.ts Outdated Show resolved Hide resolved

openclaw-barnacle bot added gateway Gateway runtime commands Command implementations agents Agent runtime and tooling size: S labels Feb 13, 2026

sauerdaniel added a commit to sauerdaniel/openclaw that referenced this pull request Feb 14, 2026

fix: use provider-qualified key in MODEL_CACHE for context window loo…

4b6c252

…kup (cherry-pick PR openclaw#15632)

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

openclaw-barnacle bot added stale Marked as stale due to inactivity and removed stale Marked as stale due to inactivity labels Feb 21, 2026

WhiteGiverMa mentioned this pull request Mar 5, 2026

[Bug]: Session contextTokens gets stuck at lower model limit after model switch (e.g. 198k -> 160k -> stays 160k) #35372

Closed

openclaw-barnacle bot added the stale Marked as stale due to inactivity label Mar 12, 2026

linwebs force-pushed the fix/model-cache-provider-qualified-key branch from 9f4f541 to f5dcd24 Compare March 13, 2026 16:05

linwebs force-pushed the fix/model-cache-provider-qualified-key branch from f5dcd24 to 80b8160 Compare March 13, 2026 16:18

openclaw-barnacle bot removed the stale Marked as stale due to inactivity label Mar 14, 2026

openclaw-barnacle bot added the stale Marked as stale due to inactivity label Mar 19, 2026

openclaw-barnacle bot closed this Mar 23, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: use provider-qualified key in MODEL_CACHE for context window lookup#15632

fix: use provider-qualified key in MODEL_CACHE for context window lookup#15632
linwebs wants to merge 2 commits intoopenclaw:mainfrom
linwebs:fix/model-cache-provider-qualified-key

linwebs commented Feb 13, 2026 •

edited

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

Uh oh!

greptile-apps bot commented Feb 13, 2026

Uh oh!

linwebs commented Feb 13, 2026

Uh oh!

openclaw-barnacle bot commented Feb 21, 2026

Uh oh!

openclaw-barnacle bot commented Mar 12, 2026

Uh oh!

linwebs commented Mar 13, 2026

Uh oh!

greptile-apps bot commented Mar 13, 2026 •

edited

Loading

Comments Outside Diff (2)

Uh oh!

openclaw-barnacle bot commented Mar 19, 2026

Uh oh!

openclaw-barnacle bot commented Mar 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

linwebs commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual (after fix)

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

greptile-apps bot commented Feb 13, 2026

Uh oh!

linwebs commented Feb 13, 2026

Uh oh!

openclaw-barnacle bot commented Feb 21, 2026

Uh oh!

openclaw-barnacle bot commented Mar 12, 2026

Uh oh!

linwebs commented Mar 13, 2026

Uh oh!

greptile-apps bot commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 4/5

Comments Outside Diff (2)

Uh oh!

openclaw-barnacle bot commented Mar 19, 2026

Uh oh!

openclaw-barnacle bot commented Mar 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

linwebs commented Feb 13, 2026 •

edited

Loading

greptile-apps bot commented Mar 13, 2026 •

edited

Loading