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

[olddonkey]

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.

[Ingwannu]

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.

[Wibias]

[GD] Opened PR #1885 to address this.

[olddonkey]

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.

[olddonkey]

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".