Repository navigation
Sol Ultrafast is omitted from the first-party model catalog with ChatGPT authentication #52839
Description
Activity
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
- Ultrafast unavailable in Codex CLI v0.162.0 on Pro 500: missing command and fallback to Standard #52726
- GPT-6.1 Sol Ultrafast is not showing up #52573
- Ultrafast unavailable with API-key auth: Codex catalog omits tier that works in Responses API #52296
Powered by Codex Action
Still reproducible on Windows on 11 October 2026 in the desktop model picker: GPT-6.1 Sol offers Fast but no Ultrafast, while Astra offers both.
A freshly read local catalogue (
fetched_at: 2026-10-11T04:33:44.748881Z,client_version: 0.162.0; this is catalogue metadata, not a claim about the GUI's About version) contains:{ "gpt-6.1-sol": { "additional_speed_tiers": ["fast"], "service_tier_ids": ["priority"] }, "gpt-6-astra": { "additional_speed_tiers": ["fast", "ultrafast"], "service_tier_ids": ["priority", "ultrafast"] } }Authentication is through ChatGPT. No local catalogue override has been installed, and no model/tier settings were changed during this diagnosis. This confirms the picker/catalogue omission, not whether the backend would actually serve an Ultrafast request.
The official speed documentation still lists GPT-6.1 Sol Ultrafast for eligible accounts: https://learn.chatgpt.com/docs/agent-configuration/speed#ultrafast-mode
Please investigate the first-party model-catalogue/eligibility filtering, or provide an actionable explanation for this model-specific omission. A supported correction is preferable to freezing and manually modifying the complete local model catalogue. No credentials, account identifiers, client data, transcripts or raw logs are attached.
I am experiencing the same problem for the last 36 hours.
This began occuring ~24hrs after ultrafast launched.
I was able to access ultrafast for the first day.Thank you both for the additional reports.
At 06:26 UTC on October 11, my normal Codex CLI 0.162.1 still returned only
priorityfor GPT-6.1 Sol, while Astra advertised bothpriorityandultrafast. No local catalog override or originator override was configured.A related report in #52726 indicates recovery for another user, so availability may differ across accounts or client contexts. This does not yet establish the cause or a universal resolution.
@KeganHollern, could you share whether you were using the CLI or desktop app, and its version when Ultrafast was available and when it disappeared? Please omit credentials and account identifiers.
Environment
0.162.1.fast_modeandultrafast_modeenabled.model_catalog_jsonoverride in the normal CLI reproductions below.Problem
The catalog returned for normal first-party clients advertises only
priorityforgpt-6.1-sol. A requestedultrafasttier consequently resolves todefaultin the interactive CLI.A controlled catalog comparison using the same account and credentials returned different Sol tier lists when only the
originatorheader changed. Please investigate whether first-party catalog filtering is consistent with the intended Sol Ultrafast rollout and account eligibility.Reproduction
Inspect
gpt-6.1-solincodex debug models, then run:Repeat with
--no-daemonto exclude the shared daemon.Both runs completed their fixed-text replies. The corresponding local
feedback_tagsrecords showed:{ "feature.fast_mode": "true", "feature.ultrafast_mode": "true", "service_tier": "default" }This is client runtime telemetry, not a server-side served-tier or billing receipt.
Controlled catalog evidence
Endpoint:
GET https://chatgpt.com/backend-api/codex/models?client_version=0.162.1.The authorization, account header, URL/query,
Accept: application/json, andUser-Agent: codex_cli_rs/0.162.1were held constant. Onlyoriginatorvaried. All three responses were HTTP 200, dated2026-10-10 09:24:58 UTC.codex_cli_rs["fast"]["priority"]W/"4cd482a52c296cc978ff6e32b7f1f899"Codex Desktop["fast"]["priority"]W/"4cd482a52c296cc978ff6e32b7f1f899"sol_ultrafast_diagnostic["fast","ultrafast"]["priority","ultrafast"]W/"ae5a6f3066817d1b3a2964c8464f8e4a"Response request IDs, in the same order:
req_477ce5d55db84f52a5fe3d3da1f275fbreq_1169f8611ebb4ae09abdf33e2b7d7541req_338dad2294a1444c9e9371d1f8db8f37Changing the originator was a read-only metadata experiment, not an installed workaround. No credentials or account identifiers are included here.
Source trace
For
0.162.1, commit092d3acd6bec3e3a14bdc7e7a2810ab628ab759d:Requested fix
Please reconcile first-party catalog metadata with the intended account/model eligibility. For eligible accounts, the normal CLI should receive the supported tier and preserve it through request construction. If the omission is intentional, please expose the applicable restriction rather than leaving the different catalog responses unexplained.
The official speed documentation lists Sol Ultrafast for eligible plans. I am not claiming that the alternate catalog proves this account's inference entitlement, or that a successful reply proves Ultrafast execution. Backend rollout/eligibility and actual served-tier verification remain for investigation.
Related: #52296 reports a similar catalog mismatch with API-key authentication. This report adds ChatGPT authentication and the controlled originator comparison.