PR #70908: Route Z.AI vision models to non-coding host on Coding Plan endpoints

• Repository: openclaw/openclaw
• Author: neeravmakwana
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/70908

Description (problem / solution / changelog)

Summary

Fixes #70886. The built-in image tool returned a 404 whenever agents.defaults.imageModel pointed at a Z.AI vision model (for example zai/glm-4.6v) and the Z.AI provider had been onboarded with a Coding Plan key. Z.AI's Coding Plan endpoints do not expose vision models, so the shared provider baseUrl must not be used for them.

Root cause

extensions/zai/onboard.ts previously applied a single provider-level baseUrl to every entry in the Z.AI catalog. When a user onboarded with --auth-choice zai-coding-global or --auth-choice zai-coding-cn, https://api.z.ai/api/coding/paas/v4 (or the CN equivalent) became the only route for every model, including glm-4.6v, glm-4.5v, and glm-5v-turbo. Those vision models are only served from the non-coding paths (…/paas/v4), so the image tool's chat/completions request resolved to a path that does not exist, returning 404.

Fix

• Add isZaiCodingBaseUrl and resolveZaiNonCodingBaseUrl helpers in extensions/zai/model-definitions.ts that map a coding base URL back to the matching non-coding host on the same origin (api.z.ai or open.bigmodel.cn).
• While building the Z.AI catalog during onboarding, attach a per-model baseUrl to the vision entries (glm-4.6v, glm-4.5v, glm-5v-turbo) when the resolved provider baseUrl is a coding endpoint. pi-coding-agent's model registry already prefers per-model baseUrl over the provider-level URL, so vision requests go to …/paas/v4 while text/coding models continue to use the configured coding path.

Why the fix is safe

• Text and coding models keep the configured provider baseUrl; only vision entries gain a per-model override, and only when the provider is already pointed at a Coding Plan endpoint.
• The override maps each coding URL back to the non-coding path on the same origin — api.z.ai ↔ api.z.ai and open.bigmodel.cn ↔ open.bigmodel.cn. No new hosts, CORS surfaces, or trust boundaries are introduced; all four URLs were already defined and tested in this module.
• Authentication is unchanged: Z.AI uses the same Bearer API key for coding and non-coding paths, and auth choices, env var names, and provider metadata are untouched.

Security / runtime controls unchanged

• No changes to prompt text, tool catalog, or any policy decision. Routing is enforced at the runtime transport layer via the already-validated ModelDefinitionConfig.baseUrl field honored by @mariozechner/pi-coding-agent's ModelRegistry.parseModels.
• No changes to ZAI_API_KEY / Z_AI_API_KEY resolution, auth storage, headers, SSRF posture, or host env allow/deny lists.
• No changes to default onboarding: openclaw onboard without an explicit coding choice still lands on ZAI_GLOBAL_BASE_URL, so vision entries carry no baseUrl override in that path.

Tests run

• pnpm vitest run extensions/zai/onboard.test.ts extensions/zai/model-definitions.test.ts — 10 tests pass, including two new regressions asserting that coding-global/coding-cn onboard produces vision baseUrl overrides to ZAI_GLOBAL_BASE_URL/ZAI_CN_BASE_URL and that non-coding onboard paths do not add overrides.
• pnpm test:extension zai — 4 files / 20 tests pass.
• pnpm vitest run src/agents/tools/image-tool.test.ts — 46 tests pass.
• pnpm test:contracts:plugins — 51 files / 637 tests pass.
• pnpm check — typecheck, lint, and policy guards pass.

Made with Cursor

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/zai/model-definitions.ts (modified, +16/-0)
• extensions/zai/onboard.test.ts (modified, +108/-1)
• extensions/zai/onboard.ts (modified, +85/-18)

---

PR #70915: fix(zai): route vision models to standard endpoint instead of coding endpoint (#70886)

• Repository: openclaw/openclaw
• Author: zhanggpcsu
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/70915

Description (problem / solution / changelog)

Summary

Fixes #70886

Issue

Image tool returns 404 for ZAI vision models (zai/glm-4.6v)

Root Cause

When the ZAI provider is configured with a coding endpoint (e.g. api.z.ai/api/coding/paas/v4), vision models like glm-4.6v return 404 because the coding endpoint does not support image understanding requests.

Direct API calls to the standard endpoint (api.z.ai/api/paas/v4/chat/completions) work correctly, confirming the coding endpoint does not serve vision models.

Solution

Override the baseUrl for ZAI vision models (glm-4.6v, glm-4.5v, glm-5v-turbo) in the media understanding provider. When a coding endpoint is detected, strip the /coding path segment to route vision model requests to the standard endpoint that supports multimodal requests.

Changes

• extensions/zai/media-understanding-provider.ts: Added patchCfgForVisionModel() that detects coding endpoints for vision models and overrides to standard endpoint. Custom describeImage/describeImages wrappers apply this patch before calling the generic functions.
• extensions/zai/media-understanding-provider.test.ts: Unit tests for vision model detection, coding endpoint detection, URL transformation, and config patching logic.

Testing

• TypeScript compilation passes (tsc --noEmit)
• All 10 unit tests pass

---

This PR was automatically generated by a daily automation task. 🤖 Generated with Claude Code

Changed files

• extensions/zai/media-understanding-provider.test.ts (added, +95/-0)
• extensions/zai/media-understanding-provider.ts (modified, +70/-3)