openclaw - 💡(How to fix) Fix [Bug] 2026.4.5 regression: ZAI-backed GLM requests hit /v4/v1/messages while same GLM models still work via Nano-GPT [1 participants]

Summary

Upgrading OpenClaw app from 2026.4.2 to 2026.4.5 introduced a regression for ZAI-backed GLM requests in our deployment.

The rollout itself succeeded and Ready=True, but direct agent execution failed immediately with:

• 404 on /v4/v1/messages

Rolling the app image back to 2026.4.2 restored successful execution with the same config, same secrets, and same provider setup.

Why this looks like a ZAI-provider-path regression

Our ZAI provider is configured as:

• api: openai-completions
• baseUrl: https://api.z.ai/api/coding/paas/v4

From public OpenClaw/ZAI docs and tests, that is a valid ZAI-native coding endpoint.

The failing runtime path /v4/v1/messages does not match that expected ZAI-native shape and instead looks like a messages-style suffix appended onto a ZAI /v4 base URL.

At this point, the safest interpretation is:

OpenClaw 2026.4.5 appears to introduce a ZAI-provider-specific regression in endpoint/path handling (or provider request shaping), rather than a broad shared custom-provider transport failure.

Repro conditions

Working baseline (2026.4.2)

• OpenClaw app: 2026.4.2
• ZAI coding endpoint: https://api.z.ai/api/coding/paas/v4
• main/default model: zai/glm-5-turbo
• subagents: nanogpt/minimax/minimax-m2.7
• subagent fallback: nanogpt/minimax/minimax-m2.5
• secret path healthy and unchanged

Change made

• Only changed spec.image.tag from 2026.4.2 to 2026.4.5

Observed behavior on 2026.4.5

• reconcile succeeded
• rollout succeeded
• Ready=True
• first direct agent execution failed with:
  • 404 on /v4/v1/messages
  • then auth/profile fallback exhaustion for zai

Rollback result

• Reverted image tag back to 2026.4.2
• Direct agent execution recovered immediately
• Same config / same secrets / same provider definitions

Provider/model comparison matrix

I ran a focused control comparison to determine whether this was a broad transport regression or something narrower.

2026.4.2

• zai/glm-5 => success
• zai/glm-5.1 => success
• nanogpt/zai-org/glm-5 => success
• nanogpt/zai-org/glm-5.1 => success

2026.4.5

• nanogpt/zai-org/glm-5 => success
• nanogpt/zai-org/glm-5.1 => success
• zai/glm-5 => fails with 404 on /v4/v1/messages
• zai/glm-5.1 => fails with 404 on /v4/v1/messages
• earlier, zai/glm-5-turbo also failed with the same /v4/v1/messages pattern

This makes it look much less like a broad shared transport failure across all OpenAI-compatible/custom providers, and much more like a regression on the ZAI provider path specifically in 2026.4.5.

Additional comparison note

As a control, I also swapped the ZAI base URL to the non-coding endpoint on 2026.4.2:

• https://api.z.ai/api/paas/v4

That did not reproduce /v4/v1/messages; instead it failed with:

• 429 Insufficient balance or no resource package

So coding vs non-coding ZAI endpoints appear to have different product/account semantics, and I do not want to over-claim that all ZAI endpoint variants are broken equally.

Relevant upstream seams

The release window around 2026.4.5 touched shared provider transport / compat handling, and there is precedent for path-assembly regressions in other provider families.

Related precedents / partial overlaps:

• #20107 / PR #20593 — wrong API path routing bug in another provider family
• #23117 — custom-provider endpoint type/detection related work
• #48166 / PR #48185 — ZAI-specific model-resolution regression
• #61281 — Z.AI fallback / cooldown symptom overlap

I did not find an existing issue that matches this exact ZAI + /v4/v1/messages regression.

Request to maintainers

Please check whether 2026.4.5 can mis-handle a valid ZAI coding endpoint such as:

• https://api.z.ai/api/coding/paas/v4

by routing it through a messages-style path that appends:

• /v1/messages

producing:

• /v4/v1/messages

The most useful next confirmation point would be temporary debug output for the first ZAI-backed request in 2026.4.5, including:

• resolved provider classification
• selected transport/API family
• final request URL before dispatch

Current conclusion

This is not a confirmed root cause yet, but based on the matrix above, the strongest current hypothesis is:

2026.4.5 introduced a ZAI-provider-specific regression in endpoint/path handling or request shaping, causing valid ZAI-backed GLM requests to be sent to /v4/v1/messages.