[Bug] Decouple model capability and response speed controls to match the official OpenAI ChatGPT experience

[str0203]

Client or integration

Codex App

Area

Catalog / models

Summary

The ChatGPT desktop integration currently exposes only one combined model-strength control, so model capability and response speed cannot be adjusted independently; I expected separate controls matching the official OpenAI ChatGPT experience.

Problem

When OpenCodex is used with the ChatGPT desktop app, the UI currently exposes only one model strength control. In practice, this single control couples two independent dimensions: model capability/reasoning strength and response speed.

The goal of this request is to make OpenCodex match the official OpenAI ChatGPT experience, where model capability and response speed are presented and controlled separately.

This should be treated as a bug fix for an existing control, not as an entirely new feature. The current implementation is a small parameter-coupling defect: two settings that should be independent are currently represented by one setting.

Current behavior

• The ChatGPT desktop integration exposes only a single model strength selector.
• Increasing the selected strength also changes the effective response-speed behavior.
• Users cannot choose a high-capability model setting while independently selecting a preferred speed.
• Users cannot adjust speed without also changing model capability.

Expected behavior

Add two independent controls, matching the official OpenAI ChatGPT interaction model:

Response speed

• Standard
• Fast
• Ultra-fast

Model capability / strength

• Light
• Medium
• High
• Extra high
• Max

The two controls should be freely combinable. For example, users should be able to select High + Standard, Max + Fast, or Light + Ultra-fast. Changing one control must not silently change the other.

Why this matters

Model capability and response speed represent different user priorities. Simple edits and short questions may benefit from faster responses, while code analysis, architecture work, and multi-file changes may require a higher capability level. Some users may want high or Max capability with Standard speed, while others may prefer a lighter capability level with Ultra-fast responses.

The current coupling removes that choice and makes OpenCodex behave differently from the official OpenAI ChatGPT client. This is important for usability, task-specific tuning, predictable resource usage, and client compatibility.

Suggested implementation scope

To keep this fast and low-risk, please preserve the existing model-strength mapping and add response speed as a separate parameter in the existing configuration/request path. The UI can add a second selector or row within the current strength popover; a broader redesign should not be necessary.

For backward compatibility, existing configurations should retain their current model-strength value, and configurations without an explicit speed value should default to Standard.

Acceptance criteria

• The ChatGPT desktop integration shows separate controls for model capability/strength and response speed.
• Strength options are: Light, Medium, High, Extra high, and Max.
• Speed options are: Standard, Fast, and Ultra-fast.
• All valid combinations can be selected and used.
• Changing speed does not change strength, and changing strength does not change speed.
• Existing strength settings remain compatible.
• Existing configurations without a speed value default to Standard.
• The labels and interaction should match the official OpenAI ChatGPT experience as closely as practical.

Summary

This is a focused correction to the current model-selection behavior: decouple two parameters that are currently incorrectly bound together, so OpenCodex provides the same independent model-capability and response-speed choices as the official OpenAI ChatGPT client.

Reproduction

1. Run OpenCodex and connect it to the ChatGPT desktop app.
2. Start a new conversation and open the model-strength control in the composer.
3. Observe that only one strength selector/slider is available.
4. Change the strength value and observe that model capability and response-speed behavior are coupled.
5. Try to select a high or Max capability level while independently choosing Standard, Fast, or Ultra-fast response speed; there is currently no separate speed control.

Expected:
The ChatGPT desktop integration should expose separate model-capability and response-speed controls, matching the official OpenAI ChatGPT experience. Both settings should be independently selectable and should remain unchanged when the other setting is modified.

Actual:
Only one model-strength control is exposed, so users cannot independently select capability and response speed.

Version

2.39.0

Operating system

macOS (ChatGPT desktop integration; exact OS version not recorded)

Provider and model

No response

Logs or error output

Screenshots and supporting files

No response

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[str0203]

I added the previously missing Summary with the concrete current behavior and expected behavior. The issue now clearly documents that this is a focused bug fix to decouple model capability and response speed so OpenCodex matches the official OpenAI ChatGPT experience. Please re-run the issue-quality check and reopen the issue if it now passes validation.

[str0203]

The issue body has been updated with the required Summary and concrete symptom/expected behavior. This is a focused bug fix to align OpenCodex with the official OpenAI ChatGPT experience.

[lidge-jun]

리뷰 · 우선순위 38 / 80

이 이슈는 ChatGPT 데스크톱(Codex App 연동)에서 모델 강도(능력)와 응답 속도가 하나의 컨트롤로 묶여 있어, 공식 ChatGPT처럼 능력과 속도를 따로 고를 수 없다는 보고입니다. 기대값은 능력(Light / Medium / High / Extra high / Max)과 속도(Standard / Fast / Ultra-fast)를 자유 조합하는 것이고, 작성자는 이를 “새 기능”이 아니라 기존 컨트롤의 결합 버그로 적어 두었습니다. 버전은 2.39.0, 영역 라벨은 bug+catalog입니다. 품질 봇이 한 번 닫았다가 Summary를 보강한 뒤 다시 열린 상태입니다.

지금 CURRENT dev HEAD는 bb27c26be이고 package.json은 2.41.0입니다. OpenCodex는 ChatGPT 데스크톱 작곡기 UI 위젯을 직접 그리지 않습니다. Codex/ChatGPT App이 읽는 것은 $CODEX_HOME/opencodex-catalog.json 카탈로그와 주입된 config.toml입니다. 그 카탈로그에는 이미 서로 다른 두 축이 있습니다. 능력/추론 깊이는 supported_reasoning_levels(와이어 effort: low / medium / high / xhigh / max, 일부 모델은 ultra)이고, 속도는 service_tiers(id priority, UI 이름 Fast)와 additional_speed_tiers: ["fast"]입니다. 네이티브 gpt-5.5·gpt-5.6-* 스냅샷(src/codex/data/upstream-models.json)이 두 축을 같이 갖고 있고, 라우트 모델은 의도적으로 속도 메타데이터를 벗겨 Fast가 비OpenAI 제공자에 새지 않게 합니다(devlog _fin/90_service-tier-fast, docs/codex-app-model-catalog.md).

그래서 “한 칸만 보인다”는 증상은 HEAD에 “두 축을 하나로 합쳐 둔 버그”라기보다, (1) 라우트 슬롯을 보고 있어 속도 칸이 원래 없음, (2) Fast 게이트([features].fast_mode, requires_openai_auth = true, ChatGPT 계정)가 꺼져 클라이언트가 속도 UI를 숨김, (3) 클라이언트가 effort 설명 문구(“Fast responses with lighter reasoning”)와 Fast 서비스 티어를 한 슬라이더로 보여 줌, (4) 보고자가 말하는 Ultra-fast·Light 라벨이 아직 Codex 카탈로그/업스트림에 없음 중 하나일 가능성이 큽니다. src/reasoning-effort.ts의 ultra는 “자동 작업 위임이 있는 최대 추론”이지 속도 티어가 아닙니다. 업스트림 스냅샷에도 Ultra-fast용 additional_speed_tiers 값은 없고 Fast(priority)만 있습니다.

관련 열린 일과의 경계도 중요합니다. #2455/#3251은 “요청한 service tier가 실제로 승인됐는지 로그에 보이게”이고, 작곡기 이중 컨트롤과는 다릅니다. Cursor Fast 토글 열차(#3222 등)는 Cursor 어댑터 쪽입니다. #2279/#2280의 synthetic max 억제는 effort 사다리 안의 별 축입니다. types.ts/config.ts 분할 캠페인과는 무관하므로 분할 때문에 닫을 대상이 아닙니다. 다만 “버그”로 바로 코딩하기 전에 재현 모델(네이티브 slug인지 라우트인지), 화면 캡처, codex debug models에서 해당 항목의 supported_reasoning_levels / service_tiers / additional_speed_tiers 출력이 필요합니다.

src/reasoning-effort.ts 라인 5-11 - Codex 추론 사다리는 low..ultra다. low 설명이 “Fast responses…”라서 속도와 혼동되기 쉽지만, 이는 능력 축 카피이지 service_tier가 아니다.
src/codex/catalog/effort.ts 라인 160-167 - supportsServiceTier === true일 때만 Fast(priority)와 additional_speed_tiers: ["fast"]를 카탈로그에 심는다. Standard/Fast 이중 축은 여기 이미 있다. Ultra-fast 슬롯은 없다.
src/codex/data/upstream-models.json - gpt-5.5/5.6 네이티브는 reasoning levels와 Fast service_tiers를 동시에 실는다. gpt-5.4-mini·gpt-5.2는 Fast 배열이 비어 속도 UI가 안 나오는 것이 정상이다.
src/codex/catalog/parsing.ts 라인 297-326 · normalizeServiceTiers - 라우트/비지원 슬롯에서 속도 메타를 지우고, 레거시 id fast→priority만 맞춘다. “한 컨트롤로 합치기” 로직은 없다.
경로/심볼 - 요청의 Light·Ultra-fast 라벨과 3단 속도는 현재 업스트림 카탈로그/OpenCodex 와이어에 근거가 없다. 임의로 만들면 Codex 파서·계정 게이트와 어긋날 수 있다.

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

• 네이티브 패스스루에서 Fast가 이미 보이면 “결합 버그”가 아니라 needs-info/클라이언트 UX로 둘지
• Ultra-fast를 업스트림에 생길 때까지 upstream-tracking으로만 둘지, OpenCodex가 가짜 3단 속도를 만들지(비추천)
• Light 등 UI 라벨을 카탈로그 description에 맞춰 바꿀지, 클라이언트 표기는 Codex App 소관으로 둘지
• bug 라벨을 enhancement/needs-design으로 바꾸거나 needs-info를 붙일지

너의 추천
열어 두되 바로 구현 PR을 받지 않는다. 보고자에게 (a) 사용 중인 모델 slug, (b) 작곡기 한 칸 화면 캡처, (c) codex debug models에서 그 모델의 reasoning/service_tiers 줄을 요청한다. 네이티브인데 Fast가 안 보이면 Phase 90 회귀(주입 toml의 fast_mode/requires_openai_auth, 카탈로그 Fast 메타)로 좁힌다. Fast는 보이는데 Ultra-fast·Light만 없다면 upstream-tracking + needs-design으로 두고, OpenCodex가 없는 속도 티어를 발명하지 않는다. #2455/#3251과 합치지 말 것. types/config 분할과 무관. 프리뷰 배포 대상 아님.

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

[str0203]

Thank you for the detailed review. I would like to clarify the intended scope of this issue.

The goal is not to invent new service-tier values or bypass upstream capability restrictions. The goal is to make OpenCodex match the official OpenAI ChatGPT experience by keeping these two dimensions independent:

• Model capability / reasoning effort
• Response speed / service tier

When the upstream model metadata advertises both dimensions, OpenCodex should expose them as separate controls and allow users to combine them independently. OpenCodex should pass through the corresponding upstream values without conflating model capability with response speed.

If a particular model, account, route, or feature gate does not support a given speed tier, the UI should use the available upstream metadata and avoid displaying unsupported options. In that case, the issue can be treated as an investigation into catalog synchronization, feature gating, or client-side presentation rather than as a request to fabricate unsupported protocol values.

This is intended as a correction to the current behavior, where the available model-strength control appears to combine or obscure response-speed selection. It is therefore a compatibility and behavior-fix request aimed at restoring parity with the official OpenAI ChatGPT selection model, rather than an unrelated new feature.

To help determine the exact ownership and implementation path, I can provide the actual model slug, OpenCodex version, ChatGPT desktop version, and the relevant output from codex debug models, including supported_reasoning_levels, service_tiers, and additional_speed_tiers.

[lidge-jun]

@str0203 — following up during a backlog review. This is not closed; it needs one piece of information from you to move.

Where this stands. Reasoning level and service tier are already separate catalog axes at src/codex/catalog/effort.ts, and ultra-fast is not advertised, so the specific mismatch you are seeing is not reproducible from the description alone.

What would unblock it. Please add the exact model slug, a screenshot of the picker, and codex debug models output.

If that arrives, this gets picked up in the next triage pass. Without it, the report cannot be distinguished from configurations that already work, so it will keep sitting here rather than being wrong on purpose.

[lidge-jun]

Reclassifying this from bug to enhancement during the backlog review, with reasoning rather than as a filing tidy-up.

The report argues this is "a small parameter-coupling defect: two settings that should be independent are currently represented by one setting." The code does not support that reading. Reasoning effort and service tier are already separate axes in the catalog — they are not one value being split in the UI. What exists today is a single combined control in the ChatGPT desktop surface that maps onto them together. Making them independently selectable there is a deliberate design of a new control surface, including what the defaults are, how the two interact when a model supports only some combinations, and what happens to existing configurations. That is a feature, and calling it a bug would set the wrong bar for what "fixed" means.

Reclassifying is not a rejection. The underlying request is reasonable and I would like it to happen.

What it needs before implementation, and what I cannot decide by inference:

• Which surface the split controls live on: the OpenCodex dashboard, the ChatGPT desktop integration, or both.
• What happens when a chosen capability and speed combination is not offered by the selected model — refuse, silently clamp, or hide the unavailable option.
• Whether existing single-control configurations migrate to an explicit pair, or keep working as-is with the pair opt-in.

@str0203 — if you have a preference on those, say so here; concrete answers move this faster than a general agreement that the split is desirable. Related: #3429 covers native Ultra Fast service tier support, and #3377 covers per-model capability declarations, both of which this would build on.

[str0203]

Thank you for the detailed review. I agree that this should be classified as an enhancement rather than a bug. The catalog already has separate reasoning/capability and service-tier axes; the requested change is to expose those existing axes independently in the ChatGPT Desktop integration and define the compatibility and migration behavior clearly.

1. Initial scope

For the first phase, I would like to focus on the ChatGPT Desktop integration only.

The goal is not to expand this issue to every OpenCodex surface at once. ChatGPT Desktop is the clearest first target because its official UI already presents model capability/reasoning and response speed as separate choices. Once the integration-level behavior is defined, the same routing logic could later be reused by the Dashboard, CLI, VS Code agents, and other integrations.

2. Independent capability and speed controls

OpenCodex should treat these as two independent dimensions:

• Model capability / reasoning effort
• Response speed / service tier

The available values should be driven by the selected provider, model, account, route, and feature-gate metadata. OpenCodex should not invent or pass through a value that the upstream model does not actually support.

The intended behavior is:

1. If the selected model advertises the requested capability and speed combination, OpenCodex should pass through the corresponding upstream values unchanged.
2. If the combination is not supported, the UI should avoid presenting an impossible option whenever the catalog already knows that it is unavailable. Unsupported values may be hidden or disabled.
3. If support can only be determined after account, route, or feature-gate resolution, the request should remain executable instead of failing solely because of the unsupported combination.
4. In that case, OpenCodex should select the highest compatible option available for that provider/model. It should preserve the requested capability when possible and select the highest compatible speed for that capability. If the capability itself is unavailable, it should fall back to the highest supported capability and a compatible speed tier.
5. The user should receive a small, non-blocking notification explaining that the requested combination was not available and that a compatible fallback was applied.

For example:

The selected provider/model does not support this capability and speed combination. OpenCodex is using the highest compatible option instead.

The UI should ideally distinguish between the requested values and the effective values actually sent upstream. This prevents users from assuming that an unsupported tier or reasoning level was applied successfully.

This also means that labels such as “Ultra-fast” should only appear when the selected model/provider actually advertises the corresponding service tier. The screenshots attached to the original report are intended to illustrate the desired two-axis interaction from the official ChatGPT experience; they are not intended to require every model to expose the same set of values.

3. Backward-compatible migration

For existing configurations that currently contain only one combined model-strength setting, I suggest a gradual, non-destructive migration:

• Continue to read and honor the existing single setting.
• Interpret the legacy value as the capability/reasoning-effort value for the new model-capability control.
• Use Auto, Standard, or the upstream default as the speed value when no explicit speed has been configured. It should not silently switch existing users to a faster or more expensive tier.
• Do not immediately rewrite all existing configuration files.
• When the user first changes either the capability or speed control, materialize an explicit pair of values and persist both fields.
• If a provider/model does not support service-tier selection, keep the capability setting and use the upstream/default speed behavior, with a small explanatory notice.

In other words, legacy configurations should remain valid, while the explicit capability-plus-speed configuration becomes opt-in through the new controls. This avoids breaking existing users and avoids silently changing their effective routing behavior.

4. Concrete model information

The model shown in the attached ChatGPT Desktop screenshot is gpt-5.6-sol. The relevant model metadata from my current OpenCodex environment is:

• Model: gpt-5.6-sol
• Supported reasoning levels: low, medium, high, xhigh, max, ultra
• Additional speed tiers: fast
• Service tiers: priority (Fast), ultrafast (Ultrafast)

The important point is that the actual available choices should continue to come from this metadata. If another provider or route exposes fewer reasoning levels or no speed tier, OpenCodex should reflect that difference rather than presenting a universal fixed list.

5. Proposed acceptance criteria

• The ChatGPT Desktop integration exposes capability/reasoning and response speed as separate controls.
• Changing one control does not silently change the other.
• The controls are populated from the selected provider/model metadata.
• Supported combinations can be selected and passed through using the corresponding upstream values.
• Unsupported combinations are hidden/disabled when known in advance, or automatically downgraded to the highest compatible combination when discovered during resolution.
• Automatic fallback produces a clear, non-blocking user notification.
• Unsupported protocol values are never fabricated.
• Existing single-control configurations continue to work.
• Existing configurations are not silently rewritten into a potentially different speed tier.
• The first explicit user change can migrate the configuration to two independent persisted values.

This keeps the first implementation focused on ChatGPT Desktop while making the underlying behavior general enough to support other OpenCodex integrations later. I hope these decisions provide the concrete scope and design details needed for the next triage pass.