Cannot select reasoning efforts for some models provided by CommandCode

[Tao-Yida]

Client or integration

Codex App

Area

Catalog / models

Summary

The model IDs of CommandCode is different from other providers, which uses original-provider-model-id for some models like z-ai-glm-5.3-flash. src/providers/command-code-efforts.ts cannot capture the reasoning efforts of these models, supported_reasoning_levels=[]. For example, commandcode/deepseek-v4-flash has multiple reasoning efforts, but commandcode/z-ai-glm-5.3-flash has no option for reasoning effort in Codex App, showing only none in logs.

Reproduction

1. Start OpenCodex and configure CommandCode API
2. Select one model like GLM-5.3-flash
3. Cannot select reasoning efforts.

Version

v2.35.0

Operating system

CentOS Linux 7 (Core)

Provider and model

commandcode/z-ai-glm-5.3-flash

Logs or error output

{
  "requestId": "",
  "timestamp": ,
  "model": "z-ai/glm-5.3-flash",
  "provider": "commandcode",
  "admissionKind": "loopback",
  "inboundProtocol": "responses",
  "conversationId": "",
  "requestedModel": "commandcode/z-ai-glm-5.3-flash",
  "requestedAlias": "commandcode/z-ai-glm-5.3-flash",
  "requestedEffort": "none",
  "modelSupportsServiceTier": false,
  "tierOutcome": {
    "wireKind": null,
    "wireValue": null,
    "fastOutcome": "unknown",
    "confirmation": "unknown"
  },
  "resolvedModel": "z-ai/glm-5.3-flash",
  "status": 200,
  "durationMs": 14739,
  "terminalStatus": "completed",
  "closeReason": "terminal",
  "usageStatus": "reported",
  "usage": {
    "inputTokens": 279116,
    "outputTokens": 464,
    "cachedInputTokens": 278080,
    "reasoningOutputTokens": 0
  },
  "totalTokens": 279580,
  "attempts": [
    {
      "ordinal": 1,
      "provider": "commandcode",
      "model": "z-ai/glm-5.3-flash",
      "adapter": "openai-chat",
      "status": 200,
      "durationMs": 14650,
      "sendCount": 1,
      "recoveryKinds": [],
      "usageStatus": "reported",
      "requestedEffort": "none",
      "tierOutcome": {
        "wireKind": null,
        "wireValue": null,
        "fastOutcome": "unknown",
        "confirmation": "unknown"
      },
      "usage": {
        "inputTokens": 279116,
        "outputTokens": 464,
        "cachedInputTokens": 278080,
        "reasoningOutputTokens": 0
      },
      "totalTokens": 279580,
      "displayMetrics": {
        "tokPerSecond": {
          "kind": "value",
          "value": ,
          "estimated": false
        },
        "cost": {
          "kind": "unavailable",
          "reason": "price_unmatched"
        }
      }
    }
  ],
  "routeDecision": {
    "version": 1,
    "decisionId": "",
    "createdAt": ,
    "requestedModel": "commandcode/z-ai-glm-5.3-flash",
    "routeKind": "explicit-provider",
    "requirements": [],
    "candidates": [
      {
        "provider": "commandcode",
        "model": "z-ai/glm-5.3-flash",
        "eligible": true,
        "exclusions": []
      }
    ],
    "selected": {
      "candidateIndex": 0,
      "provider": "commandcode",
      "model": "z-ai/glm-5.3-flash",
      "reason": "explicit-provider-namespace"
    }
  },
  "displayMetrics": {
    "tokPerSecond": {
      "kind": "value",
      "value": ,
      "estimated": false
    },
    "cost": {
      "kind": "unavailable",
      "reason": "combo_attempt_unavailable"
    }
  }
}

Screenshots and supporting files

Redacted configuration

Checks

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

[lidge-jun]

리뷰 · 우선순위 57 / 80

이 이슈가 보여 주는 화면은 간단하다. Codex 앱에서 Command Code API 키 프리셋(commandcode, 어댑터 openai-chat)에서 commandcode/z-ai-glm-5.3-flash를 고르면, 추론 세기 칸이 비고 로그만 requestedEffort: "none"이다. 같은 프리셋의 deepseek-v4-flash 쪽은 세기가 여러 개 나온다. 로그의 resolvedModel은 z-ai/glm-5.3-flash이고, 요청은 200으로 끝나니 모델 자체는 살아 있다. 세기를 고르지 못할 뿐이다. 제보 버전은 v2.35.0이고, 지금 dev HEAD(8621acb87, 패키지 2.36.0)에서도 같은 구멍이다. types/config 분할과 상관없고, 닫을 중복도 아니다.

Command Code 카탈로그는 계정마다 /provider/v1/models에서 살아 있는 모델 목록을 가져온다. 그런데 그 목록에는 추론 세기 계약이 없다. 세기 칸은 src/providers/command-code-efforts.ts의 고정 표 COMMAND_CODE_MODEL_EFFORTS에서만 온다. src/providers/registry.ts의 commandcode와 OAuth command-code 둘 다 reasoningEfforts: []에 modelReasoningEfforts: COMMAND_CODE_MODEL_REASONING_EFFORTS를 붙인다. 주석도 이렇게 못 박혀 있다. 표에 없는 새 살아 있는 모델은 일부러 세기 칸을 안 연다.

카탈로그가 세기를 붙이는 길은 src/codex/catalog/provider-fetch.ts의 applyProviderConfigHints → configuredReasoningEfforts(src/reasoning-effort.ts)다. 여기서 modelRecordValue는 모델 아이디가 표 키와 같거나, 대소문자만 다르거나, 콜론 앞 가족 이름일 때만 맞춘다. 제보 아이디 z-ai/glm-5.3-flash는 표의 zai-org/GLM-5.3과 조직 이름도 다르고 모델 이름도 다르다. 플래시가 아니다. 그래서 표 조회는 빈 값이 되고, 제공자 기본값 []가 적용되어 Codex에는 supported_reasoning_levels=[]로 보인다. 별칭 표 COMMAND_CODE_MODEL_ALIASES(src/adapters/command-code.ts)에도 glm-5.3 → zai-org/GLM-5.3만 있고 플래시 아이디는 없다.

이 고정 표는 라우터의 knownModelIdsForProvider 디코드 원본이기도 하다. 키를 함부로 바꾸면 예전에 쓰던 commandcode/zai-org-GLM-5.3 슬러그가 깨진다. 반대로 새 살아 있는 아이디를 안 넣으면, 지금처럼 원 제공자 아이디(z-ai/glm-5.3-flash)가 카탈로그에 그대로 올라오고 세기만 빠진다. NVIDIA 표에는 이미 z-ai/glm-5.3-flash가 있고, z.ai 프리셋의 glm-5.3-flash는 ["low", "high", "max"] 세 칸이다. 플래시는 글만 읽는 모델이 아니라 그림을 직접 보는 VLM이라, 세기만 넣고 입력 종류를 빠뜨리면 Codex 앱이 그림 첨부를 막을 수 있다. 지금 Command Code 그림 목록 COMMAND_CODE_IMAGE_MODELS에도 이 아이디는 없다.

프로필 페이지로 표를 고치는 refreshCommandCodeReasoningEfforts는 지금도 죽어 있다. parsedProfileEfforts는 "Reasoning efforts … are supported" 문장만 읽고, commandcode.ai 페이지는 그 문장 없이 클라이언트에서 그린다. #2647 때 넣은 세 줄도 같은 이유로 사람 손으로만 고친다. 이번에도 표에 한 줄을 더하는 쪽이 맞고, 프로필 페이지 파서는 별 이슈다. 세기를 z.ai 표에서 그냥 베껴 넣으면 안 된다. Command Code /provider/v1이 그 세기를 받는지 한 번 찍어 봐야 한다.

src/providers/command-code-efforts.ts COMMAND_CODE_MODEL_EFFORTS - 키는 업스트림 아이디 그대로여야 한다. z-ai/glm-5.3-flash 행이 없다. zai-org/GLM-5.3에 묶으면 다른 모델을 같은 세기로 광고하게 된다.

src/reasoning-effort.ts configuredReasoningEfforts / modelRecordValue - 접두어·슬러그 느슨한 매칭이 없다. 그래서 z-ai/glm-5.3-flash는 zai-org/GLM-5.3을 절대 못 찾는다. 이 조회를 느슨하게 푸는 것보다, 살아 있는 아이디를 표에 한 줄 더하는 편이 안전하다.

src/providers/registry.ts COMMAND_CODE_IMAGE_MODELS - 플래시는 네이티브 VLM이다. 세기만 넣고 그림 입력을 안 적으면, Codex 앱이 첨부를 막거나 사이드카로 돌려 더 나쁜 답을 낸다.

src/adapters/command-code.ts COMMAND_CODE_MODEL_ALIASES - 짧은 아이디 glm-5.3만 옛 키로 보낸다. 플래시 짧은 아이디가 카탈로그에 따로 있으면 여기도 한 줄이 필요하다. 없으면 건드리지 마라.

src/providers/command-code-efforts.ts refreshCommandCodeReasoningEfforts - 프로필 HTML 파서가 모든 행에서 실패한다. 이번 표 한 줄의 버그가 아니고, 고친 뒤에도 표가 스스로 고쳐지지 않는다.

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

• z-ai/glm-5.3-flash를 표에 새 키로 넣을지, Command Code가 옛 zai-org/GLM-5.3을 이 아이디로 바꿔 버린 것인지
• 세기 칸을 ["low", "high", "max"]로 열지, Command Code 실측 뒤에 정할지
• 그림 입력을 COMMAND_CODE_IMAGE_MODELS에 같이 넣을지
• 죽은 프로필 파서를 이 이슈에 묶을지, 따로 둘지
• 같은 원 제공자 아이디가 더 있는지는 제보자의 /provider/v1/models 목록을 보고 한 번에 넣을지

너의 추천
이 이슈는 열린 채로 두고, 표에 z-ai/glm-5.3-flash 한 줄을 검증된 세기로 넣는 작은 PR을 받는다. zai-org/GLM-5.3에 별칭으로 묶지 마라. 구현 전에 Command Code 키로 reasoning_effort low/high/max를 한 번씩 보내 받아지는 칸만 적어라. 그림 입력은 플래시가 VLM인 증거가 이미 있으니 같은 PR에 넣는 편이 맞다. 프로필 파서와 느슨한 아이디 매칭은 이 이슈에서 빼라. types/config 분할 때문에 닫을 대상이 아니다.

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

[lidge-jun]

Fixed on dev in a05dd25 (#2917).

z-ai/glm-5.3-flash now carries an explicit ["low","high","max"] ladder, so the effort picker is populated and requests no longer go out as requestedEffort: "none".

On the cause: the model had no row in the Command Code effort table, and the id it arrives under shares neither vendor prefix nor model with the zai-org/GLM-5.3 row that was there. The lookup matches exact, colon-family, or case-folded ids only, so nothing bridged them and the provider-level empty ladder was written onto the model. I left that lookup alone deliberately — relaxing it to a stem or substring match would merge two genuinely different upstream models, for every provider at once.

The ladder is measured rather than assumed. The profile page renders client-side, but the delivered HTML ships a serialized payload whose string table can be read directly: indices resolve as 224=low, 225=medium, 226=high, 227=xhigh, 569=max, and this model's array is [224,226,569]. The same page also carries six models already in the table, and the decode reproduces all six committed values exactly. To be precise about the limit: no authenticated upstream request was made, so the ladder is confirmed against the public payload and six known-good rows, not against a live API accept/reject.

Two things worth knowing that this did not change. Slug decoding was already exact and bijective, and your log showed the id resolving correctly with a 200 — the empty picker was only ever the missing ladder. Separately, the table's self-refresh path is dead for every row (it looks for prose that the live pages no longer contain), so a wrong ladder stays wrong until someone edits it. That is pre-existing and tracked separately; the decode recipe above is what a fixed parser would use.