Add native Ultra Fast service tier support for Codex #3429

Area

CLI

What are you trying to accomplish?

I would like OpenCodex to natively support Codex's new Ultra Fast service tier for models that expose it, currently including gpt-5.6-sol.

My ChatGPT/Codex account already has access to Ultra Fast. When I temporarily disable OpenCodex and use Codex directly, the Ultra Fast option can appear in Codex.

However, when OpenCodex manages the Codex model catalog, Ultra Fast is not exposed by default.

The desired workflow is:

1. OpenCodex detects or preserves the Ultra Fast capability from the upstream Codex model metadata.
2. Codex shows Standard, Fast, and Ultra Fast when the account/model supports them.
3. Selecting Ultra Fast sends service_tier="ultrafast" through OpenCodex without rewriting or dropping it.
4. OpenCodex request logs recognize Ultra Fast as a first-class speed tier instead of treating it as an unknown tier.

What prevents this today?

OpenCodex currently does not include Ultra Fast in the generated Codex model catalog for gpt-5.6-sol.

As a result, Ultra Fast disappears from the Codex UI when OpenCodex is enabled, even though the same account can expose Ultra Fast when using Codex without OpenCodex.

I can restore the option manually by editing ~/.codex/opencodex-catalog.json and adding "ultrafast" to additional_speed_tiers and service_tiers.

After doing this, Codex successfully sends service_tier="ultrafast", and OpenCodex logs show:

callerServiceTier: "ultrafast"
requestedServiceTier: "ultrafast"
configuredServiceTier: "ultrafast"
wireValue: "ultrafast"

However, OpenCodex's logging/classification logic does not appear to recognize Ultra Fast as a known speed tier. For example, the same request is logged with:

fastOutcome: "not-requested"
confirmation: "unknown"

There is also no requestedSpeedLabel/configuredSpeedLabel for Ultra Fast.

The manual catalog modification is also temporary because OpenCodex can regenerate the catalog during sync/start/update operations.

What should OpenCodex do?

OpenCodex should support Ultra Fast as a native Codex service tier.

Observable behavior should be:

• Preserve or generate the "ultrafast" service tier for models that support it.
• Show Ultra Fast in Codex alongside Standard and Fast when available.
• Preserve service_tier="ultrafast" end-to-end when the user selects Ultra Fast.
• Do not rewrite Ultra Fast to "priority" or remove the service_tier.
• Preserve Ultra Fast after ocx start, ocx sync, catalog refreshes, and OpenCodex upgrades.
• Recognize Ultra Fast in request logs and diagnostics as its own speed tier.
• Report requested/configured/wire/response tier information consistently for Ultra Fast.
• Ideally derive availability from upstream Codex model metadata/account capabilities rather than requiring a hard-coded local workaround.

Ultra Fast should be treated separately from the existing Fast/priority tier.

Example usage or interface

{
"additional_speed_tiers": [
"fast",
"ultrafast"
],
"service_tiers": [
{
"id": "priority",
"name": "Fast",
"description": "1.5x speed, increased usage"
},
{
"id": "ultrafast",
"name": "Ultra Fast",
"description": "Ultrafast processing"
}
]
}

With the catalog entry above and the following Codex configuration:

service_tier = "ultrafast"
model = "gpt-5.6-sol"

OpenCodex currently receives and forwards:

callerServiceTier: "ultrafast"
requestedServiceTier: "ultrafast"
configuredServiceTier: "ultrafast"
wireValue: "ultrafast"

Expected OpenCodex UI/log behavior:

Speed: Ultra Fast
Requested tier: ultrafast
Configured tier: ultrafast
Wire tier: ultrafast

and, when available from upstream:

Response tier: ultrafast

Alternatives or workarounds

The current workaround is to manually edit:

~/.codex/opencodex-catalog.json

and add "ultrafast" to both additional_speed_tiers and service_tiers for gpt-5.6-sol.

I can then set:

service_tier = "ultrafast"

in ~/.codex/config.toml.

This successfully makes Ultra Fast appear in Codex, and OpenCodex logs confirm that "ultrafast" reaches the outbound service-tier wire value.

However, this workaround is fragile because OpenCodex can regenerate opencodex-catalog.json, which removes the manual modification.

Disabling OpenCodex also allows native Codex to expose Ultra Fast on the same account, but that means losing OpenCodex routing and monitoring features.

Additional context

I verified the behavior using the same ChatGPT/Codex account and gpt-5.6-sol.

Without OpenCodex:

• Codex has exposed an Ultra Fast option for this account.

With OpenCodex:

• Ultra Fast is absent from the generated model catalog/UI by default.

After manually adding Ultra Fast to opencodex-catalog.json:

• Ultra Fast immediately appears in Codex.
• Codex sends service_tier="ultrafast".
• OpenCodex preserves it through the outbound request.

Example OpenCodex log:

"requestedModel": "gpt-5.6-sol",
"requestedEffort": "high",
"callerServiceTier": "ultrafast",
"requestedServiceTier": "ultrafast",
"configuredServiceTier": "ultrafast",
"modelSupportsServiceTier": true,
"responseServiceTier": "default",
"tierOutcome": {
"wireKind": "service-tier",
"wireValue": "ultrafast",
"fastOutcome": "not-requested",
"confirmation": "unknown",
"responseServiceTier": "default"
}

For comparison, a normal Fast request is recognized by OpenCodex as:

"callerServiceTier": "priority",
"requestedServiceTier": "priority",
"requestedSpeedLabel": "fast",
"configuredServiceTier": "priority",
"configuredSpeedLabel": "fast",
"fastOutcome": "applied",
"confirmation": "assumed",
"canonical": "priority"

This suggests that the transport path already accepts and forwards "ultrafast", while the generated model catalog and speed-tier classification/logging still need first-class Ultra Fast support.

One additional detail: responseServiceTier currently reports "default" for both my known Fast requests and the Ultra Fast request, so that field alone does not appear sufficient to determine whether the ChatGPT-authenticated Codex backend actually served the requested speed tier.

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.