feat(glm): add GLM-5.2 with effort-tier routing (high/max)

[dhaern]

Summary

GLM-5.2 (released 2026-06-13) brings a 1M context window, 131072 max output tokens, and always-on thinking. While Zhipu's OpenAI-compatible endpoint only supports binary thinking (enabled/disabled), the Anthropic-compatible endpoint graduates reasoning intensity through Claude Code's effort selector (high/max), carried by the effort-2025-11-24 beta header already present in GLM_ANTHROPIC_BETA.

This PR adds three catalog entries that expose GLM-5.2 at full capacity:

Model	Transport	Reasoning	Context	Max Output
glm-5.2	OpenAI (coding/paas/v4)	thinking always-on (binary)	1M	131072
glm-5.2-high	Anthropic (direct, no fallback)	effort: high	1M	131072
glm-5.2-max	Anthropic (direct, no fallback)	effort: max	1M	131072

The three entries are shared across glm, glm-cn, and glmt via GLM_SHARED_MODELS.

How it works

Effort tiers route directly through the Anthropic transport (no OpenAI fallback) because effort graduation is only supported on Zhipu's Anthropic endpoint:

glm-5.2-high/max
  → transformForTransport strips the suffix (upstream always sees "glm-5.2")
  → injects effort: "high"|"max" into the Anthropic body
  → injects thinking: { type: "enabled" } so the upstream emits thinking_delta blocks
  → GLM_ANTHROPIC_BETA carries the effort-2025-11-24 header

The thinking.type=enabled injection is required: without it, Zhipu's Anthropic endpoint does not surface thinking_delta blocks in the SSE stream, and clients (OpenCode, Claude Code, Cursor) see no reasoning content. The existing claude-to-openai translator maps thinking_delta → reasoning_content, so thinking text renders correctly in the client UI.

The base model (glm-5.2) retains the existing transport behavior (OpenAI primary + Anthropic fallback on retryable errors).

Files changed

File	Change
open-sse/config/glmProvider.ts	Add 3 models to GLM_SHARED_MODELS (1M ctx, 131K output)
open-sse/executors/glm.ts	parseGlm52Effort() helper, force Anthropic transport for tiers, strip suffix, inject effort + thinking
src/shared/constants/modelSpecs.ts	Model specs (1M context, 131K output, thinking + tools)
src/shared/constants/pricing.ts	Pricing entries (mirror glm-5.1, same Coding Plan quota)
open-sse/mcp-server/__tests__/glmCodingProviderConfig.test.ts	Catalog inventory, specs, pricing, tool-calling assertions

Design decisions

• GLM_REQUEST_DEFAULTS untouched (maxTokens: 16384) — bumping it would break 4.x/5.x models with smaller output caps (e.g. glm-4.6v max 32768, glm-4.5 max 98304).
• No changes to glmt — its GLMT_REQUEST_DEFAULTS are a separate preset; fixing the invalid thinkingType: "adaptive" (Zhipu only supports enabled/disabled) is out of scope for this PR.
• Pricing mirrors glm-5.1 — GLM-5.2 consumes the same Coding Plan quota; public per-token pricing is not yet published (API opens "next week").
• Suffix stripping happens in the executor, not in the global model resolver — keeps the effort tier visible for routing/quota while sending a clean upstream ID.

Validation

• 9/9 focused tests pass (glmCodingProviderConfig.test.ts)
• Runtime-verified all three tiers against the live Zhipu upstream:
  • glm-5.2 → OpenAI transport, reasoning_content in response ✓
  • glm-5.2-high → Anthropic transport, effort high, reasoning_content visible ✓
  • glm-5.2-max → Anthropic transport, effort max, reasoning_content visible ✓

Compatibility

• No changes to existing GLM models or transports
• No changes to global request defaults
• New models are additive — clients not using them are unaffected

Refs

• GLM-5.2 announcement & specs
• ChatThinking schema (enabled/disabled only)
• Coding vs general endpoints

[gemini-code-assist]

Code Review

This pull request adds support for the GLM-5.2 model and its effort tiers (high and max), routing them through the Anthropic transport to map Claude Code effort selectors to Zhipu's reasoning intensity. It also updates model specifications, pricing, and provider configurations, alongside adding unit tests. Feedback highlights a critical issue where the current check fails to override the 'adaptive' thinking type sent by some clients, which is unsupported by Zhipu's Anthropic endpoint and would result in a 400 Bad Request; a fix is suggested to explicitly force the thinking type to 'enabled'.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Zhipu's Anthropic endpoint only supports enabled and disabled for the thinking configuration (it does not support adaptive). Since Claude Code and other clients often default to sending thinking: { type: "adaptive" } for reasoning models, the current check if (!translatedRecord.thinking) will evaluate to false and forward the unsupported adaptive type upstream, causing a 400 Bad Request or failing to return thinking. We should explicitly force the thinking.type to "enabled" whenever an effort tier is active, while preserving any other fields (like budget_tokens).

        if (!translatedRecord.thinking || asRecord(translatedRecord.thinking)?.type !== "enabled") {
          translatedRecord.thinking = {
            ...(asRecord(translatedRecord.thinking) ?? {}),
            type: "enabled",
          };
        }

[dhaern]

Good catch, @gemini-code-assist.

Fixed in af8414d9. The effort-tier branch now forces thinking.type = "enabled" unconditionally (while preserving other fields like budget_tokens), instead of only injecting it when thinking was absent. This covers the Claude Code / client default of thinking: { type: "adaptive" }, which would otherwise be forwarded as-is and rejected by Zhipu with HTTP 400.

if (!translatedRecord.thinking || asRecord(translatedRecord.thinking)?.type !== "enabled") {
  translatedRecord.thinking = {
    ...(asRecord(translatedRecord.thinking) ?? {}),
    type: "enabled",
  };
}

9/9 tests still passing.

[gemini-code-assist]

The updated logic correctly handles the edge case where thinking is present but set to a non-enabled state. For a slight improvement in readability and to avoid redundant asRecord calls, you could consider this minor refactor:

const existingThinking = asRecord(translatedRecord.thinking);
if (!existingThinking || existingThinking.type !== "enabled") {
  translatedRecord.thinking = {
    ...existingThinking,
    type: "enabled",
  };
}

This maintains the same behavior while being slightly more efficient.

[dhaern]

Applied in b8066cea — thanks @gemini-code-assist. existingThinking is now extracted once, keeping the same behavior while avoiding the redundant asRecord calls.

[gemini-code-assist]

Glad to hear the refactor is working as expected. Let me know if you encounter any other issues during testing.

[diegosouzapw]

Thanks, @dhaern! 🙏 Clean GLM-5.2 addition with the effort-tier routing done right — glm-5.2-high/-max route exclusively through the Anthropic transport, set effort, and force thinking.type=enabled (since Zhipu rejects adaptive). I verified GLM_ANTHROPIC_BETA already carries the effort-2025-11-24 beta header, so the intensity selector is wired end-to-end. Registry/pricing/specs tests green (9/9 vitest), lint clean. Added a file-size baseline bump for the +21 pricing rows. Merging into release/v3.8.26. 🚀