Repository navigation
[Bug] Decouple model capability and response speed controls to match the official OpenAI ChatGPT experience #3255
Description
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
- Run OpenCodex and connect it to the ChatGPT desktop app.
- Start a new conversation and open the model-strength control in the composer.
- Observe that only one strength selector/slider is available.
- Change the strength value and observe that model capability and response-speed behavior are coupled.
- 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.
Activity
github-actions commentedon Sep 2, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
str0203 commentedon Sep 3, 2026
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 commentedon Sep 3, 2026
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 commentedon Sep 3, 2026
리뷰 · 우선순위 38 / 80
이 이슈는 ChatGPT 데스크톱(Codex App 연동)에서 모델 강도(능력)와 응답 속도가 하나의 컨트롤로 묶여 있어, 공식 ChatGPT처럼 능력과 속도를 따로 고를 수 없다는 보고입니다. 기대값은 능력(Light / Medium / High / Extra high / Max)과 속도(Standard / Fast / Ultra-fast)를 자유 조합하는 것이고, 작성자는 이를 “새 기능”이 아니라 기존 컨트롤의 결합 버그로 적어 두었습니다. 버전은 2.39.0, 영역 라벨은
bug+catalog입니다. 품질 봇이 한 번 닫았다가 Summary를 보강한 뒤 다시 열린 상태입니다.지금 CURRENT
devHEAD는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(idpriority, 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- 라우트/비지원 슬롯에서 속도 메타를 지우고, 레거시 idfast→priority만 맞춘다. “한 컨트롤로 합치기” 로직은 없다.경로/심볼 - 요청의 Light·Ultra-fast 라벨과 3단 속도는 현재 업스트림 카탈로그/OpenCodex 와이어에 근거가 없다. 임의로 만들면 Codex 파서·계정 게이트와 어긋날 수 있다.
메인테이너의 판단이 필요한 지점
너의 추천
열어 두되 바로 구현 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 commentedon Sep 3, 2026
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:
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, includingsupported_reasoning_levels,service_tiers, andadditional_speed_tiers.lidge-jun commentedon Sep 3, 2026
@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 modelsoutput.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 commentedon Sep 4, 2026
Reclassifying this from
bugtoenhancementduring 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:
@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 commentedon Sep 4, 2026
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:
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:
For example:
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:
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:
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
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.
lidge-jun commentedon Sep 8, 2026
Re-reviewed this while working through the backlog, and I owe you a correction rather than a close.
The
needs-infolabel was stale. You supplied exactly what was asked on 2026-09-04 — scope narrowed to ChatGPT Desktop,gpt-5.6-solwith its reasoning levels andservice_tiers: priority, ultrafast, five numbered fallback rules, a backward-compatible migration path, and ten acceptance criteria. Closing this with a request for that detail would have told you that you had not answered a question you did answer. I have droppedneeds-infoand relabeled itenhancement.To be straight about where it sits: #3377 (per-model capability declarations) is a dependency of this, not a home for it — the Desktop surface work is its own thing and is not scheduled yet. I would rather leave that visible than close it and have the scheduling question disappear with it.
lidge-jun commentedon Sep 9, 2026
Thanks for the detailed write-up, and for coming back to fill in the Summary.
On current
dev(8026405), capability and speed are already two independent axes in the catalog OpenCodex generates.applyReasoningLevelsinsrc/codex/catalog/effort.tswritessupported_reasoning_levels, whilesrc/codex/catalog/effort.ts:161-171separately writesservice_tiers(idpriority) andadditional_speed_tiers: ["fast"]for models wheresupportsServiceTieris true. No code path binds one to the other, so there is no coupling defect to fix on our side.OpenCodex does not draw the ChatGPT desktop composer — it publishes
opencodex-catalog.jsonand the injected config, and the client decides how many selectors to render. A routed model intentionally ships without speed metadata so Fast never leaks to a non-OpenAI provider. TheLightandUltra-fastrungs you describe also have no counterpart in the upstream catalog, so adding them would put values on the wire that the client parser does not define.Closing as working as designed. Please reopen with the exact model slug and its
ocx inspect catalogoutput for that row if you see a native model whoseservice_tiersis present yet no speed control appears — that would be a real bug and we would want it.