Repository navigation
fix(models): correct xAI reasoning_effort support - #3483
Conversation
…ings grok-4-3 and grok-4-1-fast-reasoning (azure-ai-foundry), grok-4-20-reasoning (vertex-openai), grok-4, grok-4-20-beta-0309-reasoning and grok-build-0-1 (xai) all declare reasoning: true but omitted reasoning_effort from their supportedParameters, so any effort value was silently dropped before the request was built. Inline the shared xaiSupportedParamsNoFreqPresence list (following #3159) and add reasoning_effort to each active reasoning mapping; deactivated and non-reasoning mappings keep the shared constant untouched. Fixes #3436, Fixes #3403
…or xAI mappings Direct capability assertion on each fixed mapping's supportedParameters array, not just the serialized request body — catches a future refactor that stops reading supportedParameters while serialization tests keep passing.
The reasoning_effort regression test read .supportedParameters off the raw catalogue union, which fails tsc because not every mapping member declares it. Narrow the lookup to ProviderModelMapping. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RbUnEaa7vrZZkD82wSStTr
e2e against api.x.ai shows three of the six mappings widened in #3438 answer reasoning_effort with 400 'does not support parameter reasoningEffort': xai/grok-4-20-beta-0309-reasoning, xai/grok-build-0-1, and vertex-openai/grok-4-20-reasoning (same upstream model as the former). Declaring the parameter made the gateway forward it, turning every effort-bearing request into an upstream 400 — 4 gateway e2e tests that pass on main fail with it. Restore the shared parameter list for those three, with a comment on each recording why the omission is deliberate, and split the spec's table so the rejecting mappings assert the drop rather than the forward. xai/grok-4 keeps the parameter (verified 200; it aliases to grok-4.3 upstream). The two azure-ai-foundry mappings keep it as well and remain unverified here — no Azure credentials. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RbUnEaa7vrZZkD82wSStTr
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
WalkthroughThe change updates selected xAI and Azure AI Foundry model mappings to declare ChangesxAI reasoning effort support
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related issues
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Supersedes #3438 (fixes #3436, #3403).
Problem
Six xAI mappings declare
reasoning: truebut omitreasoning_effortfromsupportedParameters, so a caller-supplied effort is dropped at the gate inpackages/actions/src/prepare-request-body.ts:4077-4086. #3438 treated all six as the same oversight and declared the parameter on every one.E2E against
api.x.aishows that premise does not hold. Three of those deployments reason unconditionally but reject the effort knob outright:reasoning_effortgrok-4grok-4.3upstream)grok-4.3grok-4.20-beta-0309-reasoningdoes not support parameter reasoningEffortgrok-build-0.1grok-4.20-reasoningControl requests with the parameter omitted return 200 for all three, so the parameter is the sole cause; streaming behaves identically. For those mappings the omission was the catalogue correctly reflecting upstream, not the bug the issues describe — declaring it turns every effort-bearing request into an upstream 400.
Change
packages/models/src/models/xai.ts— keep #3438's addition forxai/grok-4,azure-ai-foundry/grok-4-3andazure-ai-foundry/grok-4-1-fast-reasoning; restore the sharedxaiSupportedParamsNoFreqPresencelist for the three rejecting mappings, each with a comment recording why the omission is load-bearing so it does not get "fixed" again:xai/grok-4-20-beta-0309-reasoningxai/grok-build-0-1vertex-openai/grok-4-20-reasoning— same upstream model as the firstpackages/actions/src/prepare-request-body.spec.ts— split #3438's six-row table into a positive table (three mappings forward the effort) and a negative one asserting the rejecting mappings arereasoning: true, do not listreasoning_effort, and drop the value from the request body. Also narrows the mapping lookup toProviderModelMapping; reading.supportedParametersoff the raw catalogue union failstscwith TS2339, which brokepnpm buildon #3438.Verification
Ran with a live xAI key.
TEST_MODELS="xai/grok-4,xai/grok-4-20-beta-0309-reasoning,xai/grok-build-0-1" pnpm test:e2e— 29 passed, 2 skipped, 0 failed. On fix(models): reasoning_effort for azure grok-4.3 #3438 the same command produced 4 failures (chat-reasoning.e2e.ts > basic reasoningandchat-rs.e2e.ts > reasoning + streaming, both models, 400 vs expected 200). Those four pass onmain, confirming the regression rather than a pre-existing failure.prepare-request-body.spec.ts+ models specs: 380 passed.pnpm build,pnpm format,pnpm lint: clean.Not verified
azure-ai-foundry/grok-4-1-fast-reasoningkeeps the parameter but was not exercised — no Azure credentials here, and the id does not resolve on native xAI (grok-4.1-fast-reasoning→ "Model not found"; ourxaimapping for it is deactivated). Since every xAI reasoning model probed exceptgrok-4.3rejectsreasoning_effort, this one is worth a/e2erun with the Azure key before merging.azure-ai-foundry/grok-4-3is safer — nativegrok-4.3accepts the parameter.🤖 Generated with Claude Code
https://claude.ai/code/session_01RbUnEaa7vrZZkD82wSStTr
Generated by Claude Code
Summary by CodeRabbit
reasoning_effortsetting across supported xAI and Azure AI Foundry models.medium.