[Bug] Z.AI model discovery uses wrong endpoint and rejects models[].slug response

[makeavish]

Client or integration

OpenCodex dashboard

Area

Catalog / models

Summary

Z.AI model discovery fails in OpenCodex 2.56.0 for the canonical zai provider because it requests the wrong URL. There is also a response-format mismatch that would remain after fixing the URL:

1. OpenCodex requests https://api.z.ai/models, which returns HTTP 404.
2. https://api.z.ai/api/v1/models returns HTTP 200 using the same configured API key, but its model records are in models[] and use slug instead of id. The installed discovery parser rejects this response with invalid_shape.

Expected: successful discovery from /api/v1/models, with models[].slug normalized into catalog IDs and supported metadata preserved.

Actual: the dashboard reports discovery failure and falls back to configured models. Fixing only the URL is insufficient.

Reproduction

1. Run OpenCodex 2.56.0 with the canonical Z.AI provider configuration below and a valid API key.
2. Open the dashboard Models page and trigger/read Z.AI model discovery.
3. Read /api/providers through the authenticated dashboard session. The zai entry reports status: "failed", reason: "http", httpStatus: 404.
4. Resolve the configured credential and call the installed buildModelsRequest(provider, credential, "zai"). Its generated URL is https://api.z.ai/models.
5. Make authenticated GET requests to that URL and to https://api.z.ai/api/v1/models using the same credential. Observe 404 and 200 respectively.
6. Pass the successful JSON response to extractProviderModelItems(response, resolveProviderModelDiscovery("zai", provider)). Observe { "ok": false, "reason": "invalid_shape" }.

Version

@bitkyc08/opencodex 2.56.0; bundled Bun 1.4.2.

Operating system

macOS 27.0 (26A428), arm64.

Provider and model

zai / GLM Coding Plan, openai-responses adapter. This affects model discovery across the provider.

Logs or error output

Sanitized results observed on 2026-09-16:

GET https://api.z.ai/models
HTTP 404
Content-Type: text/html
Body: nginx 404 Not Found page

GET https://api.z.ai/api/v1/models
HTTP 200
Content-Type: application/json; charset=utf-8
Top-level keys: ["models"]

Installed parser result for the HTTP 200 JSON:
{"ok":false,"reason":"invalid_shape"}

Projection of the successful response, retaining only the model identifiers:

{
  "models": [
    { "slug": "glm-5.3" },
    { "slug": "glm-5.3-flash" },
    { "slug": "glm-5-turbo" }
  ]
}

The dashboard's available Z.AI list instead falls back to glm-4.6, glm-5, glm-5.1, glm-5.2, glm-5.2[1m], and glm-5.3, with no Z.AI live model count.

Screenshots and supporting files

Source trace for v2.56.0:

• The Z.AI registry entry sets the root base URL and protocol-specific inference paths, but has no model-discovery path override.
• buildModelsRequest falls back to ${effectiveProvider.baseUrl}/models.
• extractProviderModelItems selects the data envelope and reads each record's id, rejecting Z.AI's models[].slug shape.

Z.AI's official model-switching guide specifies https://api.z.ai/api/v1 for Codex. The exact model-list URL and response shape above were verified directly against the live service.

Suggested fix: add a provider-specific discovery path and response normalization for Z.AI, with regression coverage for both URL construction and models[].slug parsing. Preserve the existing inference paths; changing the shared base URL alone could affect their resolution. Keep any alternate envelope handling scoped to the relevant provider.

These checks confirm that the configured key works for model listing. No inference request was made, and no configuration was changed during diagnosis.

Redacted configuration

Relevant provider fields only; credentials omitted:

{
  "providers": {
    "zai": {
      "adapter": "openai-responses",
      "baseUrl": "https://api.z.ai",
      "authMode": "key",
      "liveModels": true,
      "defaultModel": "glm-5.3"
    }
  }
}

Checks

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

[lidge-jun]

리뷰 · 우선순위 70 / 80

이 이슈는 대시보드 Z.AI(zai) 모델 discovery가 틀린 URL을 치고, 올바른 URL을 쳐도 응답 모양을 거절한다는 버그 보고다. 보고 내용: https://api.z.ai/models → 404, https://api.z.ai/api/v1/models → 200이지만 models[].slug라서 파서가 invalid_shape을 낸다. 기대는 /api/v1/models에서 slug를 카탈로그 id로 정규화하는 것이다. OpenCodex 2.56.0에서 관측했다고 적혀 있고, 지금 dev 2.58.0에서도 같은 구조가 남아 있는지 확인했다.

현재 HEAD 8c5917448e971f8bbfb7595252932f678b486a35에서 src/providers/registry/entries-extended.ts의 zai 행은 baseUrl: "https://api.z.ai", 기본 어댑터 openai-responses, 전송 경로는 responsesPath: "/api/v1/responses" / Chat alias 등으로 이미 /api/v1 쪽을 알고 있다. 그런데 이 행에는 modelDiscovery 스펙이 없다. 스펙이 없으면 src/providers/model-discovery.ts의 providerModelsUrl(baseUrl)이 ${baseUrl}/models를 만들어 https://api.z.ai/models가 된다. 보고된 404와 정확히 같다. 주석·시드(src/providers/registry/model-seeds.ts)는 권위 있는 roster를 GET https://api.z.ai/api/v1/models라고 이미 적어 두었는데, discovery URL만 그 문서와 어긋나 있다.

두 번째 구멍은 파서다. parseProviderModelsApiResponse(같은 파일 후반)는 OpenAI식 data[] 봉투(또는 top-level 배열)만 받고, 각 행의 id는 (raw).id 문자열만 인정한다. sibling models[]는 이미 입학한 data[] 행을 풍부하게 할 때만 쓰이며(buildSiblingIndex는 id/model/name 키), **단독 models[].slug 봉투는 invalid_shape**이다. 보고자의 두 번째 실패 모드와 맞다. 정적 models: ["glm-5.3", ...] 시드가 있어 discovery 실패 시 완전 공백은 아닐 수 있지만, 대시보드가 live discovery 실패를 보여 주고 새 roster를 못 받는 증상은 그대로다. types/config 분리와 무관하고 중복 이슈로 보이지 않는다.

경로/심볼 - src/providers/registry/entries-extended.ts zai — modelDiscovery 없음. baseUrl만으로 /models 조합.
경로/심볼 - src/providers/model-discovery.ts providerModelsUrl(대략 63–67행) — trailing /models 제거 후 다시 /models 붙임. api.z.ai → 잘못된 루트.
경로/심볼 - src/providers/model-discovery.ts resolveProviderModelDiscoveryUrl — 스펙이 있으면 url/path로 고칠 수 있음. 다른 프리셋(예: baseten path: "models") 선례 있음.
경로/심볼 - src/providers/model-discovery.ts 파서 — envelope 키 ["data"]만, id 필드만. slug / 단독 models[] 미지원 → invalid_shape.
경로/심볼 - src/providers/registry/model-seeds.ts — 권위 URL이 이미 /api/v1/models라고 주석됨. discovery 스펙만 맞추면 문서·코드가 일치한다.

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

• modelDiscovery: { url: "https://api.z.ai/api/v1/models" }(또는 path /api/v1/models)만으로 충분한지, 응답이 정말 data[].id인지 models[].slug인지 라이브 한 번 더 확인할지
• slug 지원을 범용 파서에 넣을지(위험: 다른 공급자 봉투와 혼동), zai 전용 normalizer/filter로 좁힐지
• discovery가 고쳐진 뒤 정적 models 시드와 live roster가 어긋날 때 retain 정책을 어떻게 둘지

너의 추천
받아들여라. 작은 PR 하나로 (1) zai에 registry modelDiscovery를 /api/v1/models로 고정하고, (2) 라이브 응답이 slug 봉투면 zai 전용으로 slug→id 정규화 또는 envelope 키를 허용하는 테스트를 tests/ 쪽에 넣어라. 프로바이더 전체를 Chat로 되돌리거나 baseUrl을 /api/v1로 바꿔 Responses 경로를 깨는 방향은 피하라. 증거 JSON을 이슈에 한 장 더 붙이면 리뷰가 더 빨라진다.

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

[lidge-jun]

Fixed on dev by #4886 (1ac246c4e2), released in 2.58.0.

The zai preset now carries modelDiscovery with path: /api/v1/models, envelopeKey: models, and idField: slug, so both halves of this report are addressed — the endpoint and the response shape. The base URL and the inference path are unchanged.