Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bedrock discovery silently uses hardcoded contextWindow for all models [2 pull requests, 1 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#64919•Fetched 2026-04-12 13:26:18
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
mobilinkdmobilinkd
Participants
mobilinkdmobilinkd
Timeline (top)
cross-referenced ×2referenced ×1

Error Message

At runtime, resolveContextWindowInfo receives modelContextWindow: 32000. Since 32000 is a positive number, normalizePositiveInt returns it and the source is marked as "model" rather than "default". This means the existing shouldWarnDefault warning (added in PR #64901) does not fire for Bedrock models that should legitimately warn.

Root Cause

In extensions/amazon-bedrock/discovery.ts:

  • toModelDefinition() always sets contextWindow: defaults.contextWindow (line 166)
  • resolveInferenceProfiles() uses baseModel?.contextWindow ?? defaults.contextWindow (line 285)
  • resolveFoundationModels() uses the same fallback pattern

Since defaults.contextWindow === 32000 (from DEFAULT_CONTEXT_WINDOW), every model without a provider-specific override gets contextWindow: 32000 baked in as if it came from the model's own metadata.

Fix Action

Fixed

PR fix notes

PR #64935: fix(amazon-bedrock): stop baking hardcoded contextWindow into discovery results

Description (problem / solution / changelog)

What

Makes contextWindow optional in ModelDefinitionConfig and removes the hardcoded default assignment from Bedrock discovery.

Why

The AWS Bedrock API does not expose token limits. Discovery was setting contextWindow: 32000 (hardcoded default) on every discovered model, which caused resolveContextWindowInfo to mark the source as "model" rather than "default" — suppressing the shouldWarnDefault warning that PR #64901 added.

How

  • src/config/types.models.ts: contextWindow is now number | undefined
  • extensions/amazon-bedrock/discovery.ts: toModelDefinition() no longer sets contextWindow; resolveInferenceProfiles() inherits only from baseModel?.contextWindow (not the fallback default)
  • Tests updated to reflect that discovered models have contextWindow: undefined

The runtime already handles undefined correctly — it falls through to source: "default" and fires the warning.

Closes #64919

Changed files

  • extensions/amazon-bedrock/discovery.test.ts (modified, +1/-4)
  • extensions/amazon-bedrock/discovery.ts (modified, +6/-4)
  • src/config/types.models.ts (modified, +6/-1)

PR #65030: fix(amazon-bedrock): track literal contextWindow fallbacks with provenance flag

Description (problem / solution / changelog)

What

Adds contextWindowIsLiteralDefault?: boolean to ModelDefinitionConfig. Set to true only when Bedrock discovery falls back to the hardcoded DEFAULT_CONTEXT_WINDOW (32000) with no user-configured defaultContextWindow.

resolveContextWindowInfo uses this flag to mark source as "default" instead of "model", enabling the guard warning to fire for Bedrock models that used the discovery-layer fallback.

Why

Bedrock's AWS API does not expose token limits. Discovery pre-sets contextWindow: 32000 → source: "model" → shouldWarnDefault: false. The provenance flag lets the runtime distinguish between:

  • A real API-provided or user-configured value (source: "model")
  • A hardcoded fallback with no provenance (source: "default")

How

  • Type: Added optional contextWindowIsLiteralDefault to ModelDefinitionConfig
  • Discovery: Bedrock sets true only when using literal DEFAULT_CONTEXT_WINDOW = 32000 and config.defaultContextWindow is not set
  • Runtime: resolveContextWindowInfo checks the flag and uses source: "default" when true
  • Call sites: Updated all 3 call sites to pass the new flag

Tests

  • context-window-guard: source=default when flag is true
  • context-window-guard: source=model when flag is false
  • bedrock discovery: flag=false when defaultContextWindow is configured
  • bedrock discovery: flag=true when no defaultContextWindow is set
  • bedrock inference profiles: inherit flag from foundation model

Safety

  • Zero breaking changes: flag is optional on shared type; other providers omit it
  • Provider-local: only Bedrock sets this; other providers are unaffected
  • Backward-compatible: existing behavior unchanged when flag is absent

Closes #64919

Changed files

  • extensions/amazon-bedrock/discovery.test.ts (modified, +18/-1)
  • extensions/amazon-bedrock/discovery.ts (modified, +16/-4)
  • src/agents/context-window-guard.test.ts (modified, +28/-0)
  • src/agents/context-window-guard.ts (modified, +7/-1)
  • src/agents/pi-embedded-runner/compact.ts (modified, +1/-0)
  • src/agents/pi-embedded-runner/extensions.ts (modified, +1/-0)
  • src/agents/pi-embedded-runner/model.inline-provider.test.ts (modified, +3/-0)
  • src/agents/pi-embedded-runner/model.inline-provider.ts (modified, +6/-0)
  • src/agents/pi-embedded-runner/model.test.ts (modified, +141/-0)
  • src/agents/pi-embedded-runner/model.ts (modified, +35/-3)
  • src/agents/pi-embedded-runner/run/setup.ts (modified, +1/-0)
  • src/config/types.models.ts (modified, +6/-0)
RAW_BUFFERClick to expand / collapse

Problem

Amazon Bedrock's API does not expose token limits. Discovery sets contextWindow: 32000 (a hardcoded default) on every discovered model — including models with much larger actual context windows — when the provider doesn't explicitly override it.

At runtime, resolveContextWindowInfo receives modelContextWindow: 32000. Since 32000 is a positive number, normalizePositiveInt returns it and the source is marked as "model" rather than "default". This means the existing shouldWarnDefault warning (added in PR #64901) does not fire for Bedrock models that should legitimately warn.

Root cause

In extensions/amazon-bedrock/discovery.ts:

  • toModelDefinition() always sets contextWindow: defaults.contextWindow (line 166)
  • resolveInferenceProfiles() uses baseModel?.contextWindow ?? defaults.contextWindow (line 285)
  • resolveFoundationModels() uses the same fallback pattern

Since defaults.contextWindow === 32000 (from DEFAULT_CONTEXT_WINDOW), every model without a provider-specific override gets contextWindow: 32000 baked in as if it came from the model's own metadata.

Proposed fix

Make contextWindow optional in ModelDefinitionConfig so discovery can leave it undefined when using the hardcoded default. The runtime would then see undefined → fall through to source: "default" → fire the warning naturally. This is a more targeted fix than blanket-raising the hardcoded default.

See also: issue #64250 (root cause — Bedrock API doesn't expose token limits).

extent analysis

TL;DR

Make contextWindow optional in ModelDefinitionConfig to allow discovery to leave it undefined when using the hardcoded default, enabling the warning to fire naturally for Bedrock models.

Guidance

  • Review the toModelDefinition(), resolveInferenceProfiles(), and resolveFoundationModels() functions in extensions/amazon-bedrock/discovery.ts to ensure they handle contextWindow as an optional property.
  • Update the ModelDefinitionConfig type to make contextWindow optional, allowing discovery to leave it undefined when no provider-specific override is present.
  • Verify that the shouldWarnDefault warning fires as expected for Bedrock models with larger actual context windows after applying the proposed fix.
  • Consider referencing issue #64250 for additional context on the root cause of the problem.

Example

// Update ModelDefinitionConfig to make contextWindow optional
interface ModelDefinitionConfig {
  // ...
  contextWindow?: number;
}

Notes

This fix assumes that making contextWindow optional in ModelDefinitionConfig will allow the warning to fire naturally for Bedrock models. However, additional testing may be necessary to ensure this fix does not introduce unintended consequences.

Recommendation

Apply the proposed workaround by making contextWindow optional in ModelDefinitionConfig, as this is a targeted fix that addresses the specific issue with Bedrock models.

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#indexing error#inference speed#output truncation#response parsing

Still need to ship something?

×6

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

Back to top recommendations

TRENDING