feat(app): expose Fast tier controls for capable custom providers

Summary

Expose Fast-tier selection and effective-tier status in the Codex desktop app when a custom Responses provider supports that tier, or show a specific explanation when the selected provider/authentication mode is unsupported.

Problem to solve

After switching from direct ChatGPT authentication to a local router pooling two ChatGPT Pro subscriptions, the desktop Fast control disappeared. The composer shows GPT 6.0 Astra High with no Fast indicator. The provider is configured with requires_openai_auth = false because the router selects the upstream OAuth credential. The client configuration already contains service_tier = "fast", and the installed CLI reports fast_mode as stable and enabled.

A read-only probe using the desktop app's bundled app-server returned Astra's Fast tier from model/list while account/read returned no account and requiresOpenaiAuth = false. Users cannot tell whether the configured tier is active, unavailable, or simply hidden. The missing control does not establish that requests stopped using priority processing.

OpenAI's current speed documentation promises ChatGPT Fast mode when signed in with ChatGPT. It does not establish support for this custom-provider authentication arrangement, so this draft requests a capability and clear status rather than asserting a demonstrated breach of that contract.

Proposed behavior

For a selected custom provider and model advertising a Fast service tier, let the desktop user inspect the effective tier and select between the advertised tier and the default tier when supported. If product policy or authentication requirements prevent selection, show the specific reason in the model/speed controls. Distinguish the requested tier from confirmed upstream processing when confirmation is unavailable.

Acceptance criteria

• With a custom Responses provider, requires_openai_auth = false, and a model advertising priority/Fast, the desktop model/speed controls show either an operable tier selector with effective selection or an explicit unsupported-provider/authentication explanation.
• When selection is supported, choosing Fast results in service_tier = "priority" on the next applicable request; selecting the default tier stops requesting priority. The displayed state agrees with the effective request setting.
• A preconfigured service_tier = "fast" is visible as the effective selection when supported, or its unavailability is explained.
• A model without a Fast tier is not presented as supporting it, and direct ChatGPT authentication retains its existing supported behavior.
• The UI does not imply that a custom provider inherits ChatGPT credit billing, subscription entitlement, or confirmed upstream priority merely because its catalog advertises Fast.

Affected area

Codex desktop model/speed selection and service-tier status, using model/list capability information and the selected provider's account state. The desktop implementation is not contained in the public openai/codex source tree; its shared app-server protocol and the repository's Codex App issue template provide the appropriate public reporting route.

Non-goals

Combining subscription quotas, changing authentication or account-pool routing, adding credentials to client requests, guaranteeing an upstream speedup, or prescribing a desktop implementation. No CLIProxyAPI or VibeProxy defect has been demonstrated by these checks.

Supporting context

Observed environment on 2026-09-07: macOS 27.0 arm64; ChatGPT desktop bundle com.openai.codex version 26.901.51231, build 8109; bundled and terminal codex-cli 0.153.4; model gpt-6-astra. The actual listener is a locally modified CLIProxyAPI 7.2.152-wall-clock.1 build, commit b833176e, on 127.0.0.1:8318. VibeProxy 1.8.289 is installed but its frontend on port 8317 is not listening.

Relevant sanitized configuration:

model = "gpt-6-astra"
model_provider = "vibeproxy"
service_tier = "fast"

[model_providers.vibeproxy]
name = "VibeProxy Codex account pool"
base_url = "http://127.0.0.1:8318/v1"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = false

No fast_mode override is present in the inspected features table; codex features list reports fast_mode stable true. The live router's GET /v1/models?client_version=0.153.4 returns a models entry for gpt-6-astra containing service_tiers with id priority and name Fast.

A fresh diagnostic instance of the desktop-bundled app-server, initialized through its documented stdio protocol using the existing default configuration, returned the following selected fields. These are diagnostic-process results, not a capture from the running desktop conversation:

{
  "model/list": {
    "id": "gpt-6-astra",
    "serviceTiers": [{"id": "priority", "name": "Fast", "description": "2x speed, increased usage"}],
    "additionalSpeedTiers": ["fast"],
    "defaultServiceTier": null
  },
  "account/read": {
    "account": null,
    "requiresOpenaiAuth": false
  }
}

The public 0.153.4 source explicitly returns no provider account when requires_openai_auth is false: provider.rs. The CLI Fast status indicator also requires has_chatgpt_account: service_tiers.rs. This establishes an account-dependent visibility rule in the CLI, not the private desktop implementation's exact cause.

The source's request-tier resolution uses the enabled feature and model catalog: session/mod.rs. The upstream CLIProxyAPI Responses translator preserves service_tier = "priority": request translator. That upstream source inspection is not end-to-end verification of the locally modified binary or either subscription's processing tier.

Verification limits: the desktop menu was not independently inspected during the protocol investigation. No direct-versus-proxy desktop comparison, generated model request, outbound request capture, upstream tier confirmation, or latency measurement was performed. The reported missing control and a local composer screenshot are the desktop evidence; the exact private UI gate remains unverified.

Related open reports checked on 2026-09-07: #27940, Fast mode unavailable in desktop/VS Code with API authentication, and #25849, desktop Fast control missing with a custom provider. Their environments differ from this OAuth-backed pool; a shared cause is not proven. This request supplies current evidence for an OAuth-backed custom provider that reports no client account while exposing Fast through model/list; please consolidate with either report if it covers the same product decision.

Official contract references: Codex speed and configuration reference. The latter documents that fast maps to the request value priority.

Start with codex-rs/model-provider/src/provider.rs, codex-rs/tui/src/chatwidget/service_tiers.rs, and codex-rs/core/src/session/mod.rs to understand account gating, tier capabilities, and request resolution. The desktop implementation is not in this repository, so a contributor must first identify the private app integration or clarify the public reporting boundary. Done means supported custom providers expose accurate tier selection or a specific explanation without implying upstream entitlement.