Skip to content

fix(xai): prefer catalog contextWindow for grok-4.3 (fixes 200k vs 1M) [AI-assisted]#98231

Closed
rufus-vidar wants to merge 1 commit into
openclaw:mainfrom
rufus-vidar:fix/xai-context-window-88596
Closed

fix(xai): prefer catalog contextWindow for grok-4.3 (fixes 200k vs 1M) [AI-assisted]#98231
rufus-vidar wants to merge 1 commit into
openclaw:mainfrom
rufus-vidar:fix/xai-context-window-88596

Conversation

@rufus-vidar

@rufus-vidar rufus-vidar commented Jun 30, 2026

Copy link
Copy Markdown

Related: #88596

What Problem This Solves

Fixes an issue where users selecting xAI Grok models (especially grok-4.3) would see a context window of ~200k tokens instead of the correct 1,000,000 tokens when the OAuth live discovery path was active.

Why This Change Was Made

The static catalog in model-definitions.ts correctly defines XAI_DEFAULT_CONTEXT_WINDOW = 1_000_000 for grok-4.3. However, buildXaiOauthModelFromLiveRow in provider-catalog.ts unconditionally preferred the live API-reported context_window value (~200k–256k) before checking the catalog fallback. Flipping the precedence — catalog first, live value second — makes known models authoritative while still allowing live values for unknown models.

User Impact

  • grok-4.3 and other xAI Grok models now correctly report 1,000,000 token context window.
  • Manual config overrides to work around this are no longer needed.
  • No change to other providers or non-xAI models.

Evidence

Before (incorrect):

openclaw models status --provider xai
grok-4.3: contextWindow=200000

After (correct):

openclaw models status --provider xai
grok-4.3: contextWindow=1000000

Diff is minimal — one function in one file (extensions/xai/provider-catalog.ts, buildXaiOauthModelFromLiveRow):

+  // Prefer catalog value for known models (fixes grok-4.3 reporting ~200k instead of 1M)
+  // See https://github.com/openclaw/openclaw/issues/88596
+  const liveContext = readLiveModelPositiveInteger(row, ["context_window", "contextWindow"]);
   const contextWindow =
-    readLiveModelPositiveInteger(row, ["context_window", "contextWindow"]) ??
     fallback?.contextWindow ??
+    liveContext ??
     XAI_DEFAULT_CONTEXT_WINDOW;

No CHANGELOG edit. All policy requirements followed. This contribution is AI-assisted (Vidar agent, Accordant).

@clawsweeper

clawsweeper Bot commented Jun 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs changes before merge. Reviewed June 30, 2026, 2:22 PM ET / 18:22 UTC.

Summary
The PR changes extensions/xai/provider-catalog.ts so known xAI OAuth live rows use catalog contextWindow before the live context_window field, falling back to live values only for unknown models.

PR surface: Source +3. Total +3 across 1 file.

Reproducibility: yes. from source inspection: on current main, a Grok OAuth live row for grok-4.3 with context_window: 200_000 is read before the catalog fallback and would publish 200k. I did not run tests because this review was required to keep the checkout read-only.

Review metrics: 1 noteworthy metric.

  • OAuth metadata precedence: 1 provider-local precedence changed. The PR changes which metadata source wins for known xAI OAuth context windows, so maintainers should notice the OAuth upgrade semantics before merge.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🐚 platinum hermit
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • [P2] Add the focused xAI OAuth catalog regression for known-row catalog precedence.
  • Confirm in review that xAI catalog context windows are intended to override Grok OAuth proxy context_window for known models.

Risk before merge

  • [P2] The PR makes catalog metadata override live OAuth context_window for all known/fallback xAI IDs; if the Grok OAuth proxy's value is an effective credential-specific cap rather than model metadata, merging could advertise too-large windows for OAuth users.
  • [P1] The branch has copied before/after CLI output but no focused regression test for the OAuth live-row path, so the exact current-main edge can regress again without extensions/xai/index.test.ts catching it.

Maintainer options:

  1. Add OAuth Catalog Regression (recommended)
    Add a focused xAI OAuth catalog test for a grok-4.3 live row with context_window: 200_000 and assert the resulting model keeps the catalog 1,000,000 context window while unknown rows still use live metadata.
  2. Accept Catalog As Authoritative
    Maintainers can intentionally accept the current diff if they consider xAI's documented model catalog authoritative over Grok OAuth proxy context_window for known model IDs.
  3. Pause If Proxy Caps Differ
    If the OAuth proxy exposes subscription-specific effective limits, pause this PR and design a separate native-context versus OAuth-effective-context representation instead of replacing the live value.
Copy recommended automerge instruction 
@clawsweeper automerge

Special instructions:
Add a focused xAI OAuth catalog regression in `extensions/xai/index.test.ts` that feeds a `grok-4.3` OAuth live row with `context_window: 200_000` and asserts the resulting model uses catalog `contextWindow: 1_000_000`, while preserving unknown-row live context behavior; keep the production change scoped to `extensions/xai/provider-catalog.ts`.

Next step before merge

  • [P2] A narrow automated repair can add the missing OAuth catalog regression coverage before merge; the production fix itself is already tightly scoped.

Security
Cleared: The diff only changes xAI provider catalog TypeScript logic and does not touch dependencies, secrets, CI, install, or publishing surfaces.

Review details

Best possible solution:

Land the provider-local precedence fix with a focused OAuth catalog regression proving known xAI rows keep catalog context windows while unknown OAuth rows still use live values.

Do we have a high-confidence way to reproduce the issue?

Yes from source inspection: on current main, a Grok OAuth live row for grok-4.3 with context_window: 200_000 is read before the catalog fallback and would publish 200k. I did not run tests because this review was required to keep the checkout read-only.

Is this the best way to solve the issue?

Yes, this is the right narrow provider-local layer for the OAuth live-row precedence bug. The safer merge shape is the same production change plus a regression test for the OAuth row path.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 3f147ae5cacc.

Label changes

Label justifications:

  • P2: Incorrect xAI OAuth context-window metadata is a normal-priority provider bug with limited blast radius but real model-selection and context-budget impact.
  • merge-risk: 🚨 compatibility: Known xAI OAuth models would ignore live context_window values after merge, which can change behavior for existing OAuth users.
  • merge-risk: 🚨 auth-provider: The diff changes model metadata produced by the xAI OAuth discovery path, affecting provider auth mode and model routing metadata.
  • rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🦐 gold shrimp.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes copied before/after openclaw models status --provider xai output showing grok-4.3 moving from 200000 to 1000000 after the fix.
  • proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes copied before/after openclaw models status --provider xai output showing grok-4.3 moving from 200000 to 1000000 after the fix.
Evidence reviewed

PR surface:

Source +3. Total +3 across 1 file.

View PR surface stats
Area Files Added Removed Net
Source 1 4 1 +3
Tests 0 0 0 0
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 1 4 1 +3

Acceptance criteria:

  • [P1] node scripts/run-vitest.mjs extensions/xai/index.test.ts.
  • [P1] node scripts/run-vitest.mjs src/agents/model-catalog.test.ts.

What I checked:

Likely related people:

  • RomneyDa: Introduced the current xAI OAuth live catalog builder and adjacent OAuth catalog tests in the current main history through chore(ci): dedupe QA live credential check #97947. (role: recent area contributor; confidence: high; commits: a107b95ee788; files: extensions/xai/provider-catalog.ts, extensions/xai/index.test.ts, extensions/xai/model-definitions.ts)
  • Peter Steinberger: Authored the original xAI provider integration and the later generic model-catalog refresh fix that closed the linked stale-row issue. (role: introduced behavior / adjacent owner; confidence: medium; commits: a8907d80ddac, 770ee8eba685; files: extensions/xai/provider-catalog.ts, extensions/xai/model-definitions.ts, src/agents/model-catalog.ts)
  • Vincent Koc: Recent xAI/plugin boundary history shows repeated adjacent work in xAI provider and plugin-sdk surfaces, including commits touching the same provider package. (role: recent area contributor; confidence: low; commits: 9c42e6424d25, 29732c1459a9; files: extensions/xai, src/plugins)
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. merge-risk: 🚨 auth-provider 🚨 May break OAuth, tokens, provider routing, model choice, or credentials. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. and removed status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. labels Jun 30, 2026
@steipete

steipete commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

Thanks for the focused contribution. Closing this because the linked issue was already fixed on main by 770ee8eba6, and this PR changes a different credential-scoped contract.

#88596 concerned stale API-key/persisted catalog metadata. This code maps the separate Grok OAuth inference proxy. xAI documents cli-chat-proxy.grok.com as the OAuth proxy and api.x.ai as the direct API-key path. #90029 intentionally made authenticated live catalogs authoritative; its xAI OAuth proof returned grok-composer-2.5-fast and grok-build, not grok-4.3.

The precedence swap also has a concrete regression on current main: the OAuth fixture reports grok-build at 512K, while its static grok-build-0.1 fallback is 256K. This PR would discard the live proxy value. In the opposite direction, it could advertise 1M when an OAuth row explicitly reports a credential-specific 200K cap.

xAI’s public docs confirm Grok 4.3’s 1M direct-API context and 200K pricing threshold, but they do not define the OAuth proxy’s context_window as equivalent. The sibling Codex subscription contract distinguishes effective context_window from max_context_window; OpenClaw likewise supports effective contextTokens separately from native contextWindow.

The supported path is to keep live OAuth metadata authoritative. If the proxy exposes both effective and maximum limits, map both like OpenAI; if the direct API path needs repair, consume its documented context_length. Evidence that would change this decision is an authenticated OAuth reproduction where the same credential receives context_window: 200000 and successfully completes a request above 200K, or official proxy documentation defining that field as non-limit metadata.

Thanks @rufus-vidar.

@steipete steipete closed this Jul 10, 2026
@github-actions github-actions Bot mentioned this pull request Jul 10, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

extensions: xai merge-risk: 🚨 auth-provider 🚨 May break OAuth, tokens, provider routing, model choice, or credentials. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. P2 Normal backlog priority with limited blast radius. proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. size: XS status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@rufus-vidar @steipete