[Compatibility] grok-4.6 xhigh reasoning effort is clamped to high

[olddonkey]

Client or integration

Codex App / Codex CLI / Direct HTTP

Provider or upstream service

xAI (xai/grok-4.6)

OpenCodex version

dev at c306fb53c (also reproduces on published 2.14.0 static seed behavior)

Endpoint or capability

/v1/responses and /v1/chat/completions reasoning effort mapping / Codex catalog picker

Current behaviour

Selecting Codex xhigh for xai/grok-4.6 is clamped to upstream high.

dev already seeds grok-4.6, but the xAI registry still advertises the Grok 4.5 ladder:

modelReasoningEfforts: { "grok-4.6": ["low", "medium", "high"], "grok-4.5": ["low", "medium", "high"] }

mapReasoningEffort() then snaps any higher Codex tier, including xhigh, down to high. That also hides the real xhigh rung from the Codex picker for the static/fallback catalog. Live discovery cannot repair this: applyProviderConfigHints() overwrites discovered efforts with the configured registry ladder.

This is separate from #1549. That tracker is about OAuth entitlement / exposing the model. This issue is about the already-seeded grok-4.6 row advertising and sending the wrong reasoning ladder.

Expected behaviour

For grok-4.6 and later, OpenCodex should advertise and forward xAI's documented ladder:

• low
• medium
• high (upstream default)
• xhigh

A Codex xhigh request should stay xhigh on the wire. grok-4.5 should keep clamping xhigh to high.

Minimal redacted request or reproduction

1. Use xai/grok-4.6 in Codex App/CLI, or send:

curl http://127.0.0.1:10100/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "xai/grok-4.6",
    "reasoning": { "effort": "xhigh" },
    "input": "say hi"
  }'

2. Inspect the upstream request. reasoning.effort / reasoning_effort is high, not xhigh.

Actual response or error

No hard error. The request succeeds, but the extra Grok 4.6 reasoning depth never leaves the proxy.

Upstream documentation

• https://docs.x.ai/developers/grok-4-6 — Reasoning: Low, medium, high (default), or xhigh
• https://docs.x.ai/docs/guides/reasoning — "xhigh" is available on grok-4.6 and later. On models that do not support it, such as grok-4.5, requests with "xhigh" are treated as "high".
• Authenticated Grok OAuth/CLI catalog evidence on [Upstream tracking] Expose Grok 4.6 through xAI OAuth when the upstream model contract is available #1549 also reports reasoning_efforts: ["xhigh", "high", "medium", "low"] for grok-4.6.

Suggested mapping

Update the xAI registry seed to:

modelReasoningEfforts: {
  "grok-4.6": ["low", "medium", "high", "xhigh"],
  "grok-4.5": ["low", "medium", "high"]
}

Keep grok-4.5 unchanged. Do not invent Cursor xhigh wire slugs unless Cursor live discovery actually exposes them.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.

[coderabbitai]

🔗 Related PRs

#853 - feat(server): advertise reasoning-effort ladders on the raw /v1/models list [merged]
#1069 - fix(deepseek): advertise the ladder each V4 model actually honors (#1057) [merged]
#1300 - fix(catalog): preserve nested reasoning efforts [open]
#1547 - test(cursor): verify Grok 4.6 routing [open]
#1585 - fix(command-code): advertise reasoning efforts for muse spark [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[lidge-jun]

Fixed on dev in 2f3221d (Merge pull request #1593).

The xAI registry now advertises low / medium / high / xhigh for grok-4.6 with high recorded as the documented upstream default, while grok-4.5 keeps its three-tier ladder and still clamps xhigh down to high. The ordinary ladder clamp translates Codex max / ultra to xhigh for 4.6, so no provider alias map was needed, and explicit API-key ladders plus provider-wide downgrade maps in user configuration are preserved rather than overwritten.

Your diagnosis was exactly right, including the detail that live discovery could not repair it because applyProviderConfigHints() overwrites discovered efforts with the configured registry ladder.

#1591 proposed an overlapping fix plus Cursor Extra High Fast parameterization; it was closed as superseded, with the Cursor piece invited back as its own PR.

Verification: tests/reasoning-effort.test.ts and tests/provider-registry-parity.test.ts cover the ladder; full suite on merged dev is 11516 pass / 0 fail.