Repository navigation
[Upstream tracking] Expose Grok 4.6 through xAI OAuth when the upstream model contract is available #1549
Description
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 xaicontinues 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/modelsand 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.6only 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.
Activity
github-actions commentedon Aug 12, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
[-][Feature Request] Add xAI Grok 4.6 support / live discovery for OAuth accounts[/-][+][Upstream tracking] Expose Grok 4.6 through xAI OAuth when the upstream model contract is available[/+]Ingwannu commentedon Aug 13, 2026
Current
devnow contains a provisionalgrok-4.6xAI 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/modelssurface returnsgrok-4.6and 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:
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 commentedon Aug 13, 2026
Authenticated Grok OAuth / CLI-proxy evidence (same transport OpenCodex remaps to)
Thanks for the
devseed. 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 nogrok-4.6in the published xAI registry).1. Discovery:
cli-chat-proxy.grok.comalready returnsgrok-4.6OpenCodex 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/modelstoday (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 extraxhighrung that 4.5 does not have.2. Invocation: OAuth chat through OpenCodex succeeded
With
ocx login xaialready valid, a hand-registeredxai/grok-4.6request against the local proxy (POST /v1/responses) returned HTTP 200:model:grok-4.6OKusage.output_tokens_details.reasoning_tokens: 126So 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:
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).
grok-4.6.reconcileOAuthProviders()rewritesproviders.xai.modelsfrom the registry onocx service start/saveConfig, so a custom/static 4.6 entry does not survive a service restart.Ask
A
devseed is enough for logged-out catalog generation; shipping it tolatest(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/modelsdump or a tool-call continuation if that is still required.lidge-jun commentedon Aug 18, 2026
Resolved on dev: 569d3f9 (+ ca4a90b, 31185fe, f813db1, 2026-08-13) register grok-4.6 across the xAI OAuth provider — models list (src/providers/registry.ts:1012), image input modality (:1021), xhigh reasoning ladder with default high (:1036-1037), per the published upstream contract (docs.x.ai grok-4-6). liveModels discovery confirms per-account availability at runtime. The upstream-tracking condition this issue was blocked on is met. (260818 campaign resolved-issue sweep, verified against origin/dev e446607.)