Add native Ultra Fast service tier support for Codex

[iWishingStar]

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.

[lidge-jun]

리뷰 · 우선순위 60 / 80

설명

이 이슈는 Codex의 새 속도 티어 Ultra Fast(service_tier=ultrafast)를 OpenCodex가 카탈로그·로그에서 1등 시민으로 다루지 못한다는 요청입니다. 증상 분리가 잘 되어 있습니다. 같은 ChatGPT 계정·gpt-5.6-sol에서 OpenCodex를 끄면 Codex UI에 Ultra Fast가 보이고, 켜면 사라집니다. ~/.codex/opencodex-catalog.json에 additional_speed_tiers와 service_tiers로 ultrafast를 수동 넣으면 UI가 돌아오고, OpenCodex 로그에도 callerServiceTier/wireValue가 ultrafast로 통과합니다. 즉 전송 경로는 이미 값을 살려 보내고, 막히는 쪽은 생성 카탈로그와 속도 티어 분류/로그입니다.

현재 dev와 맞춰 보면 그 진단이 코드에도 있습니다. src/codex/data/upstream-models.json의 gpt-5.6-sol(그리고 terra/luna/astra 등) service_tiers는 priority(Fast) 하나이고 additional_speed_tiers는 ["fast"]뿐입니다. src/codex/catalog/effort.ts도 supportsServiceTier === true일 때 Fast(priority)만 넣습니다. src/providers/fastwire.ts의 canonicalFastTierMarker는 priority/fast만 인식하고, src/server/request-log.ts의 requestLogSpeedLabel도 그 두 값만 "fast" 라벨로 바꿉니다. 그래서 수동 카탈로그로 와이어는 통과해도 fastOutcome: "not-requested", confirmation: "unknown", speed label 없음이 설명됩니다. 응답의 responseServiceTier: "default"는 Fast에서도 권위 없는 에코로 이미 #2558 쪽에서 다룬 함정이라, 그 필드만으로 Ultra Fast 성공을 판정하면 안 됩니다.

구현 방향은 “하드코드 우회”보다 업스트림 메타/계정 능력에서 ultrafast를 보존하거나 생성하고, Fast와 별 티어로 로그·카탈로그에 넣는 쪽이 이슈 본문과 맞습니다. normalizeServiceTiers는 지금 fast→priority 정규화만 하므로, ultrafast를 Fast로 접어 버리면 안 됩니다. sync/start/업그레이드가 카탈로그를 다시 쓰면 수동 수정이 사라지는 점도 재현 가능합니다. types.ts/config.ts 분할과 직접 충돌하지 않는 카탈로그·fastwire·request-log 작업입니다.

우선순위 60은 “실제 계정에서 UI가 빠지는 제품 공백이고 재현·워크어라운드가 명확하지만, 계정 entitlement·업스트림 광고 여부에 따른 설계 판단이 남아 있어 즉시 머지형 버그픽스는 아니다”는 위치입니다.

경로 src/codex/data/upstream-models.json gpt-5.6-sol - HEAD에 ultrafast 항목이 없습니다. 카탈로그 핀이 Fast만 노출합니다.
경로 src/codex/catalog/effort.ts supportsServiceTier 분기 - Fast 한 줄만 넣습니다. Ultra Fast를 여기 하드코드할지, 업스트림 발견값을 보존할지가 핵심입니다.
경로 src/providers/fastwire.ts canonicalFastTierMarker / src/server/request-log.ts requestLogSpeedLabel - ultrafast를 Fast로 오인하지 말고 별 라벨·outcome을 두어야 로그가 이슈 기대와 맞습니다.
경로 수동 ~/.codex/opencodex-catalog.json - 전송 검증에는 충분하지만 sync에 덮어쓰이므로 정식 수정이 아닙니다.

메인테이너의 판단이 필요한 지점

• ultrafast를 핀 JSON에 고정할지, 라이브 Codex 모델 메타/계정 capability에서만 살릴지
• sol만인지 terra/luna/astra 등 Fast를 쓰는 모델 전부인지
• 로그에 Ultra Fast를 Fast와 대칭인 1등 시민으로 둘지, 우선 카탈로그 노출만 할지
• responseServiceTier가 default로 남는 한계를 문서화만 할지, 별 확인 경로를 둘지

너의 추천
enhancement로 열고, 카탈로그 생성(upstream-models.json/effort·parsing)과 requestLogSpeedLabel/fastwire 인식을 한 PR로 묶되 Fast(priority)와 접지 마세요. 수동 카탈로그 워크어라운드는 정식 수정 전까지만 안내하면 됩니다. 지금 당장 close할 이슈가 아닙니다.

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

[lidge-jun]

Landed on dev as 3a9c4d297 (PR #3478), as an opt-in — and I want to be precise about which half of this shipped, because the other half is a decision rather than an oversight.

What did not ship: Ultra Fast in the model picker. PR #2994 added an ultrafast row to the pinned catalog and was closed unmerged with the verdict that the picker gained a choice the wire could not honor. Checking src/codex/data/upstream-models.json confirms why: every row that carries tiers advertises exactly one, priority. There is no upstream Ultra Fast tier to forward, so a catalog row advertising one is fabricated metadata. Re-adding it — flag or no flag — would reproduce the defect it was reverted for, so this does not synthesize a row.

What did ship: the proxy no longer refuses to name a tier it is carrying. Your report is exactly right on this, and it holds independently of advertising. Traced on dev:

• canonicalFastTierMarker folded only priority/fast, so ultrafast returned undefined, fastIntent went false, and the attempt was recorded as fastOutcome: "not-requested" — the log asserting you asked for nothing.
• requestLogSpeedLabel returned undefined for the same value, which is why your Logs column stayed empty.

Both are fixed. ultrafast folds to its own canonical rather than onto priority (which would be the opposite lie — claiming a 1.5x Fast request when you named a different tier), and it gets its own speed label.

And the regeneration problem you described. You noted the manual ~/.codex/opencodex-catalog.json edit is temporary because sync rewrites it. The ultraFastTier setting (Codex Set → Advanced settings, default off) makes catalog normalization preserve an ultrafast you supplied instead of stripping it. It still never invents one, and it never lets priority survive onto a routed row under that flag.

One thing worth flagging honestly. Adversarial review caught that my first attempt made this worse: recognising ultrafast as canonical routed it into a wire lookup that maps only priority, so it fell through to drop and stopped reaching the provider at all — where previously it was forwarded verbatim as a foreign tier. That is fixed in f626a12da with a regression test asserting the wire decision, which the original tests never did.

So: your four observable behaviors, items 3 and 4 (preserve service_tier="ultrafast" end-to-end, classify it as a first-class tier) now hold. Items 1 and 2 (generate the tier, show it in the Codex UI) deliberately do not, until upstream actually advertises Ultra Fast. If you see a real speed difference on an opted-in request, that is worth reporting with the evidence — it would change the answer on those two.