Normalize bare-key fallback before cache lookup

applyDiscoveredContextWindows and applyConfiguredContextWindows now write bare model keys in normalized lowercase form, but the fallback path in lookupContextTokens still does MODEL_CACHE.get(modelId) with the raw string. When a caller omits provider (or a provider mismatch forces fallback) and the model id is not already lowercase/trimmed, the cache miss now drops to DEFAULT_CONTEXT_TOKENS, which regresses the backward-compatible unscoped lookup behavior this change intends to keep.

Useful? React with 👍 / 👎.

please review the latest commits, this issue should now be fixed.

Bare-key fallback uses unnormalized modelId

Both applyDiscoveredContextWindows and applyConfiguredContextWindows now store bare keys with .toLowerCase().trim() normalization, but this fallback lookup passes the raw, unnormalized modelId string directly to Map.get(). Any caller passing a model ID with uppercase letters or surrounding whitespace will silently miss the cache, even though the key exists under the normalized form. The scoped key lookup (earlier in the same function) correctly normalizes both sides of the key, making this an inconsistency introduced by this PR.

This is a comment left during a code review.
Path: src/agents/context.ts
Line: 219

Comment:
Bare-key fallback uses unnormalized `modelId`

Both `applyDiscoveredContextWindows` and `applyConfiguredContextWindows` now store bare keys with `.toLowerCase().trim()` normalization, but this fallback lookup passes the raw, unnormalized `modelId` string directly to `Map.get()`. Any caller passing a model ID with uppercase letters or surrounding whitespace will silently miss the cache, even though the key exists under the normalized form. The scoped key lookup (earlier in the same function) correctly normalizes both sides of the key, making this an inconsistency introduced by this PR.

```suggestion
  return MODEL_CACHE.get(modelId.toLowerCase().trim());
```

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

defaultProvider not declared in params type

params.defaultProvider is referenced here, but defaultProvider was never added to the runMemoryFlushIfNeeded params type (defined at lines 250–264). defaultModel is present in the type and works correctly on the next line, but its provider counterpart was omitted. TypeScript will flag this as a type error, and at JavaScript runtime the expression silently evaluates to undefined, so the provider fallback never actually takes effect—the context window lookup always falls back to the bare model ID key.

The fix is to add defaultProvider?: string; to the function's params type:

This is a comment left during a code review.
Path: src/auto-reply/reply/agent-runner-memory.ts
Line: 291

Comment:
`defaultProvider` not declared in params type

`params.defaultProvider` is referenced here, but `defaultProvider` was never added to the `runMemoryFlushIfNeeded` params type (defined at lines 250–264). `defaultModel` is present in the type and works correctly on the next line, but its provider counterpart was omitted. TypeScript will flag this as a type error, and at JavaScript runtime the expression silently evaluates to `undefined`, so the provider fallback never actually takes effect—the context window lookup always falls back to the bare model ID key.

The fix is to add `defaultProvider?: string;` to the function's params type:

```suggestion
export async function runMemoryFlushIfNeeded(params: {
  cfg: OpenClawConfig;
  followupRun: FollowupRun;
  promptForEstimate?: string;
  sessionCtx: TemplateContext;
  opts?: GetReplyOptions;
  defaultModel: string;
  defaultProvider?: string;       // ← add this
  agentCfgContextTokens?: number;
```

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

Use resolved provider for followup context cache lookup

This lookup now uses fallbackProvider, but the run result already exposes the actual provider in runResult.meta?.agentMeta?.provider (and other runners prioritize that value). When those differ (for example, if the embedded runner reports a provider different from the selected fallback candidate), this line queries the wrong scoped cache key and can fall back to an unrelated bare/default context window, which skews token utilization and compaction decisions for followup turns.

Useful? React with 👍 / 👎.

Prefer model metadata over fallback cache in guard

This cache lookup runs before modelContextWindow, but lookupContextTokens falls back to the bare model-id key when a scoped provider::model key is missing (src/agents/context.ts fallback path). On cold start or when only another provider defines the same model id, cachedTokens can come from the wrong provider and override a correct modelContextWindow, causing false low-context warnings/blocks for otherwise valid runs.

Useful? React with 👍 / 👎.

Prefer runtime model context window before cache fallback

This cache lookup now runs before modelContextWindow, so when lookupContextTokens misses the scoped key and falls back to a bare model key, it can return a limit learned from a different provider and override the actual runtime model metadata for this run. In resolveContextWindowInfo, that incorrect cached value is then used for warnings/blocks, which can falsely block valid models (for example on cold cache or provider-id mismatch) even when params.modelContextWindow has the correct window.

Useful? React with 👍 / 👎.

Replace CommonJS require with ESM-safe lookup import

resolveContextWindowInfo now calls require("./context.js") on the hot path; in Node ESM execution contexts (the repo ships with "type": "module"), this throws before the guard can return a context window when modelsConfig has no direct match, which can break agent runs that rely on this guard path. Use an ESM-safe approach (for example a top-level import or createRequire) so the guard works consistently across Node runtimes.

Useful? React with 👍 / 👎.

Preserve bare-key discovery for providerless model entries

The new !model?.provider guard skips discovered models that only provide id + contextWindow, so those entries no longer populate even the legacy bare model key; in environments using older/partial registries this regresses to DEFAULT_CONTEXT_TOKENS instead of the discovered limit, reintroducing incorrect budgeting for unscoped lookups. Keep writing the bare-key cache entry when provider is missing.

Useful? React with 👍 / 👎.

require() throws ReferenceError in ESM module

This package is declared as "type": "module" in package.json, making all .ts/.js files native ESM. In ESM, require is not defined — calling it here will throw a ReferenceError: require is not defined at runtime on any code path where fromModelsConfig is falsy (i.e., the vast majority of calls, since most sessions have no per-model config override).

The fix is to use a static import at the top of the file instead:

import { lookupContextTokens } from "./context.js";

Then remove the require call entirely and call lookupContextTokens directly inside the IIFE.

This is a comment left during a code review.
Path: src/agents/context-window-guard.ts
Line: 46-47

Comment:
**`require()` throws `ReferenceError` in ESM module**

This package is declared as `"type": "module"` in `package.json`, making all `.ts`/`.js` files native ESM. In ESM, `require` is not defined — calling it here will throw a `ReferenceError: require is not defined` at runtime on any code path where `fromModelsConfig` is falsy (i.e., the vast majority of calls, since most sessions have no per-model config override).

The fix is to use a static `import` at the top of the file instead:

```
import { lookupContextTokens } from "./context.js";
```

Then remove the `require` call entirely and call `lookupContextTokens` directly inside the IIFE.

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

Bare key in applyConfiguredContextWindows uses last-write-wins, not smallest-wins

applyDiscoveredContextWindows explicitly implements "smallest wins" for the bare key (lines 53–58) to keep budgeting fail-safe when the provider is unknown. But applyConfiguredContextWindows uses a plain cache.set() with no comparison, meaning if two providers in config list the same modelId with different limits, the last one iterated wins — regardless of which limit is smaller.

This inconsistency means that a larger configured limit from a second provider can silently overwrite a smaller one in the bare-key cache, undermining the fail-safe rationale documented in the comment above it.

This is a comment left during a code review.
Path: src/agents/context.ts
Line: 86-89

Comment:
**Bare key in `applyConfiguredContextWindows` uses last-write-wins, not smallest-wins**

`applyDiscoveredContextWindows` explicitly implements "smallest wins" for the bare key (lines 53–58) to keep budgeting fail-safe when the provider is unknown. But `applyConfiguredContextWindows` uses a plain `cache.set()` with no comparison, meaning if two providers in config list the same `modelId` with different limits, the last one iterated wins — regardless of which limit is smaller.

This inconsistency means that a larger configured limit from a second provider can silently overwrite a smaller one in the bare-key cache, undermining the fail-safe rationale documented in the comment above it.

```suggestion
      // Set bare key – prefer the smaller window so budgeting stays fail-safe
      // when the provider is unknown, consistent with applyDiscoveredContextWindows.
      const existingBare = params.cache.get(normalizedModelId);
      if (existingBare === undefined || contextWindow < existingBare) {
        params.cache.set(normalizedModelId, contextWindow);
      }
```

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

Models without provider now silently skip all cache paths (regression risk)

Before this PR, a model entry with no provider still populated the bare-key cache via the original applyDiscoveredContextWindows logic. After this change the early continue at line 35 means such entries are entirely bypassed — neither the scoped nor the bare key is written for them.

discoverModels is dynamically imported and cast through unknown as ModelRegistryLike, so TypeScript cannot verify at compile time whether every returned entry actually carries a provider string. If any discovered models lack that field (e.g. because the underlying PI model-discovery layer doesn't attach a provider to every entry), those models will silently produce zero cache coverage — a regression from the previous behaviour where at least the bare key was populated.

The safest fix is to guard only the scoped-key write behind the provider truthiness check, while always writing the bare key regardless of whether provider is present. This preserves the full fallback coverage that existed before the refactor.

This is a comment left during a code review.
Path: src/agents/context.ts
Line: 34-36

Comment:
**Models without `provider` now silently skip all cache paths (regression risk)**

Before this PR, a model entry with no `provider` still populated the bare-key cache via the original `applyDiscoveredContextWindows` logic. After this change the early `continue` at line 35 means such entries are entirely bypassed — neither the scoped nor the bare key is written for them.

`discoverModels` is dynamically imported and cast through `unknown as ModelRegistryLike`, so TypeScript cannot verify at compile time whether every returned entry actually carries a `provider` string. If any discovered models lack that field (e.g. because the underlying PI model-discovery layer doesn't attach a provider to every entry), those models will silently produce zero cache coverage — a regression from the previous behaviour where at least the bare key was populated.

The safest fix is to guard only the scoped-key write behind the `provider` truthiness check, while always writing the bare key regardless of whether `provider` is present. This preserves the full fallback coverage that existed before the refactor.

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

Let configured context window override bare cache entry

In applyConfiguredContextWindows, the bare-key update only writes when contextWindow > existingBare, so a discovered larger value is never replaced by a smaller explicit config value. That means providerless lookups (and scoped lookups that fall back to bare in lookupContextTokens) can ignore a user-configured cap and keep using the discovered value instead. This regresses config override behavior for fallback paths and can inflate budgeting/guard decisions when models.providers[*].models[].contextWindow is intentionally lower.

Useful? React with 👍 / 👎.

Canonicalize provider-scoped cache keys before writing

applyDiscoveredContextWindows stores scoped entries with the raw normalized model id (provider::model.id), so provider-prefixed ids become doubly prefixed (for example github-copilot::github-copilot/gemini-3-flash). Runtime lookups use split refs (provider + provider-stripped model, via parseModelRef in src/agents/model-selection.ts), so lookupContextTokens misses the scoped key and falls back to the bare key, which can pull another provider’s limit and reintroduce cross-provider context-window poisoning.

Useful? React with 👍 / 👎.

Prefer runtime model context window over cache fallback

resolveContextWindowInfo now returns lookupContextTokens(...) before considering modelContextWindow, so a scoped-cache miss can pull a bare-model fallback from another provider and override the actual runtime window reported for this run. In mixed-provider setups (or cold/warming cache states), this can produce false low-context warnings/blocks even when params.modelContextWindow is valid for the selected provider, so the runtime model metadata should be checked before cache fallback.

Useful? React with 👍 / 👎.