Description
GLM-5.2 routed through an OpenAI-compatible provider ("api": "openai") exposes the wrong reasoning_effort variants in the TUI. The variant switcher shows high and max, but max is not part of the OpenAI reasoning_effort enum (none/minimal/low/medium/high/xhigh). Selecting max causes a 400 from spec-compliant upstreams (e.g. hyper, Cloudflare AI Gateway). The actually-selectable top tier xhigh is never surfaced.
Root cause is in packages/opencode/src/provider/transform.ts — the glm-5.2 + @ai-sdk/openai-compatible branch returns { high, max } instead of { high, xhigh }. The sibling OpenRouter branch already does the right thing (exposes xhigh, gateway translates to GLM's native max).
Plugins
None.
OpenCode version
1.17.11
Steps to reproduce
-
Configure an OpenAI-compatible provider pointing at a GLM-5.2 backend:
-
Launch opencode, open the TUI.
-
Open the model variant switcher — only high and max are listed; xhigh is missing.
-
Select max and send a prompt — upstream returns 400 (reasoning_effort: "max" rejected).
Screenshot and/or share link
N/A (config + 400, no share link).
Operating System
macOS 26 (arm64)
Terminal
Ghostty
Additional context
The OpenRouter branch in the same function already handles this correctly:
if (glm52 && model.api.npm === "@openrouter/ai-sdk-provider") {
// OpenRouter maps xhigh to GLM-5.2's native max effort.
return { high: { reasoning: { effort: "high" } }, xhigh: { reasoning: { effort: "xhigh" } } }
}
The @ai-sdk/anthropic branch is also correct as-is (Anthropic's effort field accepts max natively). Only the OpenAI-compatible branch needs fixing.
Description
GLM-5.2 routed through an OpenAI-compatible provider (
"api": "openai") exposes the wrong reasoning_effort variants in the TUI. The variant switcher showshighandmax, butmaxis not part of the OpenAIreasoning_effortenum (none/minimal/low/medium/high/xhigh). Selectingmaxcauses a 400 from spec-compliant upstreams (e.g.hyper, Cloudflare AI Gateway). The actually-selectable top tierxhighis never surfaced.Root cause is in
packages/opencode/src/provider/transform.ts— theglm-5.2+@ai-sdk/openai-compatiblebranch returns{ high, max }instead of{ high, xhigh }. The sibling OpenRouter branch already does the right thing (exposesxhigh, gateway translates to GLM's nativemax).Plugins
None.
OpenCode version
1.17.11
Steps to reproduce
Configure an OpenAI-compatible provider pointing at a GLM-5.2 backend:
{ "provider": { "hyper": { "id": "hyper", "name": "Hyper", "api": "openai", "options": { "apiKey": "...", "baseURL": "https://hyper.charm.land/v1" }, "models": { "glm-5.2": { "name": "GLM-5.2", "reasoning": true, "interleaved": { "field": "reasoning_content" }, "tool_call": true, "limit": { "context": 1000000, "output": 128000 } } } } }, "model": "hyper/glm-5.2@xhigh" }Launch opencode, open the TUI.
Open the model variant switcher — only
highandmaxare listed;xhighis missing.Select
maxand send a prompt — upstream returns 400 (reasoning_effort: "max"rejected).Screenshot and/or share link
N/A (config + 400, no share link).
Operating System
macOS 26 (arm64)
Terminal
Ghostty
Additional context
The OpenRouter branch in the same function already handles this correctly:
The
@ai-sdk/anthropicbranch is also correct as-is (Anthropic'seffortfield acceptsmaxnatively). Only the OpenAI-compatible branch needs fixing.