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

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.