[Feature]: enable xAI API-key Priority Processing in Codex Fast mode

Area

Provider adapters

What are you trying to accomplish?

Use Codex Fast mode with Grok models routed through the built-in xai provider when that provider is using an xAI API key. xAI documents Priority Processing for text inference by sending service_tier: "priority" on both Chat Completions and Responses requests.

The expected workflow is that selecting Fast in Codex, or enabling the existing OpenCodex Fast setting, makes an xAI API-key request use xAI Priority Processing while Standard leaves the field absent/default.

What prevents this today?

OpenCodex now has provider/model-scoped service-tier capability resolution, catalog publication, and Chat serialization, but the built-in xai registry entry declares neither chatServiceTier nor modelSupportsServiceTier. Consequently xai/* catalog rows do not advertise Fast and the runtime does not inject or forward the priority tier.

The preset also multiplexes two transports under one provider id:

API-key mode stays on https://api.x.ai/v1, where Priority Processing is officially documented.
OAuth mode is rewritten to https://cli-chat-proxy.grok.com/v1, where the same capability is not established by the public API documentation.

A provider-wide unconditional opt-in would therefore overstate the unverified OAuth transport.

What should OpenCodex do?

OpenCodex should make service-tier capability sensitive to the effective xAI authentication transport:

enable verified service_tier support for the canonical xAI API-key transport;
publish the Codex Standard/Fast selector for eligible xai/* rows only in API-key mode;
inject/forward service_tier: "priority" when Fast is selected and remove it when Fast is explicitly disabled;
keep the Grok OAuth/CLI subscription transport unadvertised and uninjected unless that exact endpoint is separately verified;
preserve explicit user opt-outs and keep catalog/runtime decisions driven by the same capability resolver;
avoid inferring support merely from a Grok model name or from the shared openai-chat adapter.

Example usage or interface

Given an xAI API-key configuration:

{
  "defaultProvider": "xai",
  "providers": {
    "xai": {
      "adapter": "openai-chat",
      "baseUrl": "https://api.x.ai/v1",
      "authMode": "key"
    }
  },
  "fastMode": true
}

the routed catalog entry for xai/grok-4.6 should advertise the priority/Fast tier and the effective Chat Completions body should contain:

{
  "model": "grok-4.6",
  "service_tier": "priority"
}

With authMode: "oauth", the same preset should not advertise Fast and should not send service_tier until the CLI subscription endpoint has its own evidence.

Alternatives or workarounds

Users on current dev can manually declare modelSupportsServiceTier or chatServiceTier, but those settings are not automatically constrained to API-key mode. They can survive an auth-mode switch and cause the unverified OAuth transport to receive the field.

A separate custom API-key provider can also opt in manually, but that duplicates the canonical xAI preset and loses the intended built-in provider experience.

Additional context

xAI Priority Processing documentation: https://docs.x.ai/developers/advanced-api-usage/priority-processing
Related capability issue: [Feature]: expose speed/service-tier capabilities for eligible custom providers and routed models #1436
Chat serialization gate: fix(openai-chat): forward caller-selected service tier #1512
Provider/model capability framework landed through feat: land four rebuilt heavy drafts (service tiers, request pacing, native chat, empty-completion guard) #1752
Historical Phase 90 deliberately stripped inherited Fast metadata from every routed provider, including xai/*; this proposal restores it only where the final transport is verified.

Checks

I searched existing issues and documentation.
This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
I removed secrets and personal data.

This is a valid and well-scoped capability request. The important boundary is exactly the one described here: the built-in xai id can resolve either to the canonical API-key transport or to the Grok CLI OAuth transport, so a static provider-wide chatServiceTier flag would be incorrect.

The mergeable direction is:

resolve service-tier support from the effective transport after auth-mode/base-URL resolution;
advertise and serialize priority only for the canonical xAI API-key path;
keep OAuth/CLI and unknown custom destinations unadvertised unless separately verified;
use the same resolver for catalog publication and request serialization so an auth-mode switch cannot leave stale Fast metadata;
preserve an explicit user opt-out;
cover API-key, OAuth, custom-base-URL, and auth-mode-switch cases.

I am leaving this open as an accepted provider/catalog enhancement. Please do not implement it as a static registry-only opt-in.

[GD] Opened PR #1885 to address this.

Sequencing note: this issue is now the xAI delivery unit (Phase B2) of the FastWire umbrella #1886, which generalizes Fast mode across providers.

What this changes for this issue:

Ordering — implementation lands after the umbrella's A0 (characterization) → A1 (pure refactor) → B0 (per-attempt observability) → B1 (capability semantic migration) phases, so the xAI wiring plugs into the shared resolveFastPolicy pipeline instead of extending the current resolver ad hoc.
The existing implementation branch is held. codex/xai-priority-service-tier (auth-transport-scoped capability overlay) survived the design review conceptually unchanged, but stays unmerged for now.
GA for this unit requires one merge unit containing all three of: (1) the capability enablement itself, (2) the catalog tier description corrected to xAI's actual terms (Priority Processing bills at 2× the standard token price, unlike the OpenAI "1.5x speed" blurb currently hardcoded for every provider), and (3) a pricing-matrix entry for (xai, grok-*, priority) — which first requires verifying from official xAI pricing docs how Priority Processing interacts with long-context pricing. Until that verification, Fast attempts on xAI report cost as unavailable rather than applying a guessed multiplier.

Pricing research for the B2 gate (from the official xAI docs — Priority Processing, Pricing):

Officially priced cells for grok-4.6 (per 1M tokens, input / cached / output):

tierBand	rates	source
standard (<200k prompt)	$2.00 / $0.50 / $6.00	pricing page
long-context (≥200k prompt, whole request)	$4.00 / $1.00 / $12.00	pricing page
priority	2× standard — "billed at a 2x premium over standard rates … applies to all token types — input, output, cached, and reasoning"; cache discounts apply before the multiplier	pricing + priority-processing pages
priority + long-context	not published — no combined table, and "2x over standard rates" does not disambiguate whether it compounds with the long-context band	—

Confirmation semantics (official, and it matches the per-attempt model this issue now depends on): when priority capacity is unavailable the response comes back with "service_tier": "default", and "You are only billed at the priority rate when the response confirms "priority"". So billing follows the response echo, not the request — exactly the confirmed/downgraded distinction the FastWire per-attempt outcome records.

Consequence for the B2 unit:

Three of four matrix cells can be filled from official numbers.
The combined band stays an empty cell (the design forbids guessing a multiplier). However, "billed at a premium" is official evidence that a confirmed-priority request costs at least its non-priority rate, and long-context banding applies unconditionally by prompt size — so the combined band qualifies for priceRelation: "gte-standard" with a defensible lower bound at the long-context rates ($4 / $1 / $12), surfaced as costLowerBound ("≥") rather than a point estimate.
Recommended B2 posture: ship capability + description + the three official cells + the lower-bounded combined band; upgrade the combined cell to exact numbers if xAI publishes them or an empirical ≥200k priority-confirmed request settles the multiplier.

This narrows the GA blocker from "pricing unverified" to "one band lower-bounded instead of exact".

리뷰 · 우선순위 24 / 80

xAI API 키로 Grok을 쓸 때 Codex Fast가 xAI Priority Processing이 되게 하고 싶다. 문서는 Chat/Responses 모두 service_tier priority 다. 옵트인 프로바이더 Fast라 24이다. #1886 의 첫 배달이다.

src/providers/registry.ts 의 xai 항목에는 chatServiceTier 와 modelSupportsServiceTier 가 없다. 그래서 xai/* 행에 Fast가 안 뜨고 런타임도 priority 를 안 넣는다. 기본 authKind는 oauth 이고 allowKeyAuthOverride 가 true다.

키 모드는 api.x.ai 다. OAuth는 src/providers/xai-transport.ts 의 cli-chat-proxy.grok.com 으로 바뀐다. 프로바이더 전체에 Fast를 켜면 검증 안 된 OAuth 수송까지 광고한다. openai-chat.ts 는 chatServiceTier 가 true일 때만 호출자 service_tier 를 넘긴다.

src/providers/fastwire.ts 가 수송(authorization_bearer vs oauth)과 eligibility 를 나눈다. xAI Fast는 키 수송에서만 eligible 이어야 한다. 모델 이름만 보고 켜면 안 된다.

해결방안

canonical api.x.ai 키 모드에만 service_tier 능력을 연다. 카탈로그 Fast는 그 모드의 xai 행만. Fast면 priority 주입, Standard면 필드 제거. OAuth/Grok CLI 는 광고하지 않는다. 사용자 opt-out과 같은 resolver를 카탈로그/런타임이 공유한다. 가격 2배는 #1886 과금 행렬이 생기기 전에는 카탈로그 문구만 고친다.

이 댓글은 grok-bot이 작성했습니다

리뷰 · 우선순위 56 / 80

점수 정정임. 24는 Fast 옵션을 장식으로 본 거였음. #1752 서비스 티어 프레임은 이미 있고 FastWire B2도 들어왔음. xai 레지스트리가 chatServiceTier/modelSupportsServiceTier를 안 켜서 카탈로그에 Fast가 안 뜨고 service_tier: "priority"도 안 나감.

공식 문서는 API 키 https://api.x.ai/v1만임. OAuth cli-chat-proxy.grok.com은 검증 전이라 프로바이더 전체에 켜면 안 됨. 수동 modelSupportsServiceTier는 인증 모드 바꿔도 남아서 OAuth에 필드가 샐 수 있음.

해결방안: 키 모드 + 캐논 api.x.ai일 때만 티어 광고/주입. Fast면 priority, Standard면 필드 빼기. OAuth는 그대로 숨김. 모델 이름으로 추측하지 말 것.

이 댓글은 grok-bot이 작성했습니다

feat(xai): enable Priority Processing on the API-key transport

Merge pull request #2072 from olddonkey/codex/fastwire-b2-xai

이미 #2072 (8535f082fac3f0342e2e73445edd4655be3147eb)로 dev에 반영되었습니다 — xAI API-key 경로에서 Codex Fast / Priority Processing이 동작합니다. 이슈를 닫습니다.

feat(xai): enable Priority Processing on the API-key transport

Merge pull request lidge-jun#2072 from olddonkey/codex/fastwire-b2-xai

Navigation Menu

Repository navigation

[Feature]: enable xAI API-key Priority Processing in Codex Fast mode #1875

Area

What are you trying to accomplish?

What prevents this today?

What should OpenCodex do?

Example usage or interface

Alternatives or workarounds

Additional context

Checks

리뷰 · 우선순위 24 / 80

해결방안

리뷰 · 우선순위 56 / 80

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Feature]: enable xAI API-key Priority Processing in Codex Fast mode #1875

Description

Area

What are you trying to accomplish?

What prevents this today?

What should OpenCodex do?

Example usage or interface

Alternatives or workarounds

Additional context

Checks

Activity

Ingwannu commented on Aug 16, 2026

Wibias commented on Aug 17, 2026

olddonkey commented on Aug 17, 2026

olddonkey commented on Aug 17, 2026

lidge-jun commented on Aug 19, 2026

리뷰 · 우선순위 24 / 80

해결방안

lidge-jun commented on Aug 19, 2026

리뷰 · 우선순위 56 / 80

lidge-jun commented on Aug 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions