Repository navigation
[Bug] Combo 默认推理级别设为 max，但实际请求为 none #3108
Description
Activity
리뷰 · 우선순위 69 / 80
설명
이 이슈는 Combo의 기본 추론 레벨을
max로 잡아도, 실제로 고른 자식(여기선deepseek-v4-pro)으로 나가는 요청의 추론 강도가none이라는 보고입니다. 같은 모델을 콤보 없이 직접 고르고max를 주면reasoning_effort=max가 붙습니다. 클라이언트는 Codex 앱, OpenCodex는 제보 기준 v2.37.0, OS는 Windows 11입니다. 지금 체크아웃은 2.39.0 / HEAD6123be31f인데, 아래 경로는 그대로 있습니다.콤보 기본 노력은
src/combos/request.ts의concreteComboRequestBody가 넣습니다. 64행에서defaultEffort가 없으면 바로 돌아갑니다. 66–72행에서 클라이언트가 이미reasoning.effort를 가지고 있으면 덮어쓰지 않습니다. 73–86행에서 그 자식의targetReasoningEfforts가 기본값을 포함하지 않으면 넣지 않고 debug 로그만 남깁니다. 주석도 분명합니다. 피커는 사다리를 모를 때 와일드카드로 보여 주지만, 런타임 주입은 그 자식이 지원을 광고할 때만 넣습니다.GUI 힌트(예:
cws.field.defaultEffortHint)도 “클라이언트가 노력을 안 밝혔을 때만 쓴다”고 말합니다. Codex 앱이 콤보 모델로 보낼 때reasoning.effort를none으로 명시하면, 콤보 기본max는 영원히 적용되지 않습니다. 직접 고를 때는 앱이max를 보내니 통과합니다. 이게 제보와 가장 잘 맞는 갈래입니다.다른 갈래는 카탈로그입니다.
src/codex/catalog/aggregation.ts168–171행의 콤보 기본값은 멤버 사다리 교집합과 맞춰지고, 주입은 그 교집합이 아니라 자식 각각의reasoningEfforts를 봅니다. GUI에서max를 고를 수 있어도, DeepSeek 행이max를 광고하지 않으면 런타임은 생략합니다. 직접 경로의 모델 피커는 그 모델 사다리만 보고max를 보내서 성공합니다. 둘 다 HEAD에 있는 동작이고, types.ts/config.ts 분할과는 무관합니다. 제보의 스크린샷은 없고 재현 절차는 분명합니다.라인
src/combos/request.ts66–72 - 클라이언트가effort: "none"을 명시하면 콤보 기본값을 안 넣습니다. Codex 앱이 콤보 턴에 none을 항상 심는지가 이 버그의 핵심입니다. 로그에 요청 JSON의reasoning이 있는지 보면 갈립니다.
라인src/combos/request.ts75 - 자식 사다리에max가 없으면 주입을 건너뜁니다. GUI 교집합에max가 보이는데 자식 카탈로그에는 없는 상태일 수 있습니다.combo default effort omitteddebug 로그가 있는지가 두 번째 단서입니다.
경로 Codex 앱 vs 직접 모델 - 직접은 피커 값이 와이어로 가고, 콤보는 “생략될 때만 기본값”입니다. 제품 문장이 “콤보 기본 레벨을 쓰면 그 값이 나간다”이면 지금 구현과 어긋납니다.
경로 버전 - 제보는 v2.37.0입니다. 2.39.0 HEAD의concreteComboRequestBody도 같은 가드라, 버전만 올려서는 안 사라질 가능성이 큽니다.메인테이너의 판단이 필요한 지점
- 콤보 기본 노력이 Codex 앱의 명시적
none을 이길지, “생략될 때만”을 유지할지 - 피커 교집합과 런타임 자식 사다리가 어긋나면 GUI에서
max를 못 고르게 할지, 런타임을 피커에 맞출지 - 재현 로그(콤보 요청의
reasoning과combo default effort omitted로그)를 더 받을지, 바로 패치를 탈지
너의 추천
열린 버그로 두고, 먼저 콤보 요청에reasoning.effort가 이미none인지부터 확인하는 것을 추천합니다. 있으면 콤보 기본값은 설계상 적용되지 않은 것이고, Codex 앱이 콤보에 none을 넣는 쪽을 고치거나 콤보가 none을 “생략”으로 취급해야 합니다. 없고 사다리 미스로 빠졌으면 카탈로그 광고를 고치면 됩니다. 지금 HEAD만으로도 두 갈래가 설명되고, 제보를 닫거나 중복 처리할 이유는 없습니다.이 댓글은 grok-bot이 작성했습니다
- 콤보 기본 노력이 Codex 앱의 명시적
- added a commit that references this issue
on Sep 1, 2026 Fixed by #3172, landed on dev as 7386b52.
The combo request path tested literal membership against the target model's effort ladder and dropped the configured default on a miss, so nothing reached the wire and the provider default applied - which is what surfaced as none. The catalog plane had never agreed with that: it advertises a combo default resolved to the highest supported rung at or below the request. Both planes now share one resolver, so a combo set to max against a target topping out at high sends high rather than nothing.
Unknown ladders stay fail-closed and an explicitly empty ladder still means no reasoning effort. Regression coverage is in tests/combos.test.ts.
Closing manually because pull requests target dev rather than the default branch.
Automated translation bookkeeping — detected language: English.
- added a commit that references this issue
on Sep 1, 2026
Client or integration
Codex App
Area
Proxy and routing
Summary
使用 Combo 路由
deepseek-v4-pro时，Combo 的“默认推理级别”已设置为max，但实际请求日志中的推理强度为none。作为对照，直接选择同一个
deepseek-v4-pro并设置max时，reasoning_effort=max能正常生效。因此推测 Combo 路由过程中没有正确传递默认 reasoning effort。
Reproduction
combo/0，策略为 failover。max。deepseek-v4-pro。combo/0发送请求：实际推理强度为none。deepseek-v4-pro并设置max：reasoning_effort=max。两种情况下实际使用的是同一个 DeepSeek V4 Pro。
Expected behavior
当 Combo 默认推理级别设置为
max时，如果客户端没有指定其他推理级别，最终选中的目标模型应收到reasoning_effort=max。Actual behavior
deepseek-v4-pro→maxcombo/0→deepseek-v4-pro→noneEnvironment
v2.37.0deepseek-v4-pro已确认截图中的供应商信息已做脱敏。