[Bug] Z.AI GLM: reasoning_effort never sent, so /effort levels have no effect

[ruttybob]

Affected area: AI providers and models

What happened?

Z.AI models with thinkingFormat: "zai" only send enable_thinking: true/false in API requests — reasoning_effort is never sent. Selecting different effort levels in /effort therefore has no effect: the API receives identical requests for high and max. Additionally, Z.AI models have no thinkingLevelMap, so the selector offers levels that are meaningless for these models.

Two root causes, both still present on current main (verified on main @ 06e4a19):

1. detectCompat hardcodes Z.AI off (openai-completions.ts:1119):

   supportsReasoningEffort: !isGrok && !isZai && !isMoonshot && !isCloudflareAiGateway,

2. The thinkingFormat: "zai" handler only sets the boolean toggle (openai-completions.ts:569):

   if (compat.thinkingFormat === "zai" && model.reasoning) {
       (params as any).enable_thinking = !!options?.reasoningEffort;
   }

Steps to reproduce

1. Configure a Z.AI GLM model (e.g. glm-5.2) and open /effort
2. All 7 thinking levels are listed (no thinkingLevelMap)
3. Switch between high and max — requests to https://api.z.ai/api/coding/paas/v4/chat/completions are identical apart from the boolean

Expected behavior

Effort levels should map to a reasoning_effort request parameter, and the /effort selector should only show levels the model actually distinguishes.

Prime Agent version: observed on 0.7.1, re-verified on main @ 06e4a19

Environment: macOS (Darwin)

Additional context

Measured on glm-5.2 with thinking + reasoning_effort sent manually — the API does honour effort levels:

Effort	Reasoning (chars)	Completion tokens	Latency	Behavior
off	0	192	4.0s	No CoT, friendly answer
high	1,012	456	6.2s	Direct solution
max	3,202	982	15.0s	Explores all branches, validates answer

glm-4.7, glm-5-turbo, glm-5.2 all accept thinking.type + reasoning_effort alongside enable_thinking without conflict.

Upstream pi already fixed this direction (earendil-works/pi#5770 effort levels for GLM-5.2; #6083 clear_thinking: false for Z.AI caching).

Proposed fix sketch: add a thinkingLevelMap for Z.AI reasoning models in generate-models.ts (levels [off, low, medium, high, max] with low/medium aliasing to high), set supportsReasoningEffort: true in their compat, and upgrade the zai handler to also send reasoning_effort mapped through the level map. I have a working implementation with tests on a branch and can share it if invited.

[aljazceru]

PR #1565 implements essentially your proposed sketch, with two corrections from live probing the coding endpoint:

• Efforts actually accepted by glm-5.3 are low | high | max only ("medium" errors); glm-5.2 additionally accepts none/low beyond the high | max models.dev advertises. The map is derived from models.dev reasoning_options per model, so 5.2 exposes off/high/max and 5.3 exposes off/low/high/max.
• off maps to reasoning_effort: "none" (send enable_thinking: true alongside), because enable_thinking: false returns a 400 on 5.2/5.3 — see [Bug] Refinement fails if current model does not support no thinking #1482.

Direct z.ai effort-capable models get supportsReasoningEffort: true in compat, so detectCompat's hardcoded false no longer masks them, while Prime Inference z-ai routes stay toggle-only per their contrac