[Upstream tracking] Expose Grok 4.6 through xAI OAuth when the upstream model contract is available

[federicorv25]

Status

Blocked on upstream model availability and contract details.

This is now an upstream-tracking issue rather than an implementation-ready feature request.

OpenCodex should not guess a Grok 4.6 OAuth/CLI model slug, context window, reasoning controls, modality support, tool support, or other catalog metadata before xAI exposes and confirms them through the relevant authenticated Grok/xAI surface.

Goal

When Grok 4.6 becomes available to an authenticated xAI/Grok OAuth account, expose it through the existing OpenCodex xAI OAuth workflow so Codex App and Codex CLI users can select it without requiring a separate xAI API-key provider.

The desired flow remains:

ocx login xai
        ↓
OpenCodex discovers or recognizes upstream Grok model
        ↓
/v1/models + generated Codex catalog
        ↓
xai/<confirmed-upstream-slug>

Upstream gate

Implementation should begin only after there is reliable evidence for the OAuth/CLI-backed model contract.

At minimum confirm:

• the model is actually available to the authenticated Grok/xAI account surface used by OpenCodex;
• the exact upstream model identifier;
• whether discovery returns the model dynamically or a maintained fallback entry is required;
• context-window metadata;
• reasoning controls/effort values;
• image/input modality support;
• tool/function-call behavior;
• streaming behavior;
• quota/account eligibility semantics that differ from Grok 4.5, if any.

Public xAI API availability alone is not sufficient if the OAuth/Grok CLI-compatible transport used by this issue exposes a different catalog or entitlement boundary.

Expected OpenCodex behavior once unblocked

• ocx login xai continues to own authentication for the xAI OAuth provider.
• The confirmed Grok 4.6 model is discovered or represented with verified metadata.
• The model appears in /v1/models and the generated Codex catalog.
• Codex App/CLI can select the namespaced xAI model.
• Requests use the existing xAI OAuth/Grok-compatible transport when that upstream surface supports the model.
• Existing Grok 4.5 behavior does not regress.
• Unsupported capabilities are not advertised merely because another Grok version supports them.

Do not implement by guessing

Do not:

• hard-code grok-4.6 only because that name is expected;
• copy Grok 4.5 capability metadata without upstream evidence;
• treat a custom-provider/API-key workaround as proof that the OAuth route supports the same model;
• advertise a model before the authenticated upstream can actually invoke it.

Close condition

Close when the model is available through the intended xAI OAuth account flow and OpenCodex exposes it with verified routing/catalog behavior.

If xAI confirms that this model will not be available through the OAuth/Grok account transport, close as not planned and document the supported alternative.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[Ingwannu]

Current dev now contains a provisional grok-4.6 xAI registry seed (569d3f96e) plus reasoning-replay coverage (494ce1db2). The OAuth transport and catalog tests remain green, so logged-out/static catalog generation can represent the model without changing the existing xAI routing path.

That does not satisfy this issue's close condition yet. The seed itself says its capability metadata is mirrored from Grok 4.5 pending settled upstream tables, and we still do not have an authenticated xAI/Grok OAuth account capture proving that the subscription /v1/models surface returns grok-4.6 and that the OAuth Chat transport accepts a real request with the advertised effort/modalities.

Keeping this open as upstream/account verification rather than adding more code. The remaining evidence needed is:

• redacted authenticated OAuth model-discovery output containing the exact model id;
• one successful OAuth chat request, ideally including a tool continuation;
• confirmation of context, reasoning ladder, and image support from the intended OAuth surface rather than the API-key product alone.

Once that evidence exists, we should replace the provisional mirrored comments with verified provenance and close this tracker. PR #1547 is Cursor-specific evidence and does not prove the xAI OAuth entitlement boundary.

[ethanhe-036]

Authenticated Grok OAuth / CLI-proxy evidence (same transport OpenCodex remaps to)

Thanks for the dev seed. Adding the remaining account-surface evidence from a logged-in Grok/xAI OAuth account on Windows, OpenCodex 2.11.1 (also checked that 2.14.0 still has no grok-4.6 in the published xAI registry).

1. Discovery: cli-chat-proxy.grok.com already returns grok-4.6

OpenCodex xAI OAuth remaps https://api.x.ai/v1 → https://cli-chat-proxy.grok.com/v1. The same origin is what Grok Build / Grok CLI uses.

A session-auth fetch of GET https://cli-chat-proxy.grok.com/v1/models today (2026-08-13T04:12:57Z, Grok Build 1.0.3) includes:

{
  "id": "grok-4.6",
  "model": "grok-4.6",
  "name": "Grok 4.6",
  "api_backend": "responses",
  "context_window": 500000,
  "supports_reasoning_effort": true,
  "reasoning_efforts": ["xhigh", "high", "medium", "low"],
  "supported_in_api": true
}

Image input is advertised on this Grok 4.6 row (same catalog as 4.5). Default reasoning effort is high, with an extra xhigh rung that 4.5 does not have.

2. Invocation: OAuth chat through OpenCodex succeeded

With ocx login xai already valid, a hand-registered xai/grok-4.6 request against the local proxy (POST /v1/responses) returned HTTP 200:

• model: grok-4.6
• assistant text: OK
• usage.output_tokens_details.reasoning_tokens: 126

So the OAuth/Grok-CLI Chat/Responses path already accepts grok-4.6; this is not API-key-only.

3. Why OpenCodex still does not expose it on 2.11.1 / 2.14.0

Two local blockers, in case they help close the remaining work:

1. Live discovery is blocked on Clash fake-ip. OpenCodex logs:
   Provider model discovery for "xai" was blocked by destination policy: cli-chat-proxy.grok.com resolves to benchmark address (198.18.2.93) [fallback=configured]
   So even though the upstream catalog has 4.6, OpenCodex falls back to the static seed (4.5).
2. Startup reconcile wipes a hand-added grok-4.6. reconcileOAuthProviders() rewrites providers.xai.models from the registry on ocx service start / saveConfig, so a custom/static 4.6 entry does not survive a service restart.

Ask

A dev seed is enough for logged-out catalog generation; shipping it to latest (or documenting a non-reconciled custom-model path) would unblock Codex App/CLI users who already have Grok 4.6 on the OAuth/CLI proxy.

Happy to capture a redacted /v1/models dump or a tool-call continuation if that is still required.