Summary
When using a GLM model (e.g. GLM-5.2 via Z.ai's Anthropic-compatible endpoint at https://api.z.ai/api/anthropic), the effort selector dropdown does not render in the chat composer. This prevents users from selecting GLM-5.2's High and Max reasoning effort tiers, even though the downstream plumbing already carries the effort field end-to-end and Z.ai's endpoint accepts it.
Environment
- CodePilot: v0.56.0 (source HEAD
b4e96a1)
- OS: Windows 11
- Provider: env (Claude Code SDK runtime)
- Endpoint:
https://api.z.ai/api/anthropic
- Model:
glm-5.2[1m]
Root cause
The dropdown visibility is gated by a model capability flag that GLM does not have.
src/components/chat/MessageInput.tsx:991-992:
```tsx
const currentModelMeta = currentModelOption as (typeof currentModelOption & { supportsEffort?: boolean; supportedEffortLevels?: string[] }) | undefined;
const showEffortSelector = currentModelMeta?.supportsEffort === true;
```
supportsEffort: true is set on Claude variants in src/lib/provider-catalog.ts (Sonnet / Opus / Haiku roles, plus Fable 5 at lines 240, 250, 260, 290, 301, 314, 325, 344, 355, 370, 385, 396, 428, 437) but not on GLM models configured via the env provider. When a user selects GLM, currentModelMeta.supportsEffort is undefined, so showEffortSelector is false and the dropdown never renders. There is no way inside the UI to set selectedEffort to anything other than the 'auto' default.
The downstream plumbing already works
Once selectedEffort is anything other than 'auto', the value flows through cleanly:
src/app/chat/page.tsx:890:
```tsx
...(selectedEffort && selectedEffort !== 'auto' ? { effort: selectedEffort } : {}),
```
src/lib/claude-model-options.ts:102-144 (sanitizeClaudeModelOptions) passes effort through unchanged for any model that isn't Opus 4.7/4.8/Fable 5. GLM matches neither the OPUS_ADAPTIVE_THINKING_PATTERN nor the FABLE_PATTERN, so effort: 'max' would reach Z.ai's endpoint as-is.
The EffortSelectorDropdown itself also already falls back to the full 5-level set when supportedEffortLevels is undefined:
src/components/chat/EffortSelectorDropdown.tsx:36:
```tsx
const baseLevels = supportedEffortLevels || ['low', 'medium', 'high', 'xhigh', 'max'];
```
So the only thing missing is the capability flag on GLM model entries.
GLM-5.2 does support effort tiers
Per Z.ai's "How to Switch Models" doc:
"In a Claude Code session, type the /effort command to switch thinking intensity. After switching, Claude Code maps the selected effort to GLM-5.2's actual effort levels..."
GLM-5.2 exposes at least High and Max effort tiers. Users running the Claude Code CLI directly against Z.ai can reach them via /effort max. CodePilot users cannot, because the UI gate is closed. (CodePilot also does not forward /effort as a slash command to the underlying SDK, so there's no escape hatch.)
Suggested fixes
In order of preference:
-
Mark env-provider models with supportsEffort: true by default so the dropdown renders for any Anthropic-compatible endpoint (GLM, DeepSeek, Kimi, etc.). Downstream code handles unknown effort values gracefully, and the endpoint will either accept the level or ignore it.
-
Add explicit GLM entries to ENV_CLAUDE_CODE_MODELS with supportedEffortLevels: ['high', 'max'] matching what Z.ai's endpoint actually documents, so the dropdown surfaces only the levels GLM-5.2 truly supports.
Workaround
None inside CodePilot today. Switching to Opus surfaces the dropdown (Opus has supportsEffort: true), but that's not a real fix for users who chose GLM for cost or quota reasons.
Summary
When using a GLM model (e.g. GLM-5.2 via Z.ai's Anthropic-compatible endpoint at
https://api.z.ai/api/anthropic), the effort selector dropdown does not render in the chat composer. This prevents users from selecting GLM-5.2'sHighandMaxreasoning effort tiers, even though the downstream plumbing already carries theeffortfield end-to-end and Z.ai's endpoint accepts it.Environment
b4e96a1)https://api.z.ai/api/anthropicglm-5.2[1m]Root cause
The dropdown visibility is gated by a model capability flag that GLM does not have.
src/components/chat/MessageInput.tsx:991-992:```tsx
const currentModelMeta = currentModelOption as (typeof currentModelOption & { supportsEffort?: boolean; supportedEffortLevels?: string[] }) | undefined;
const showEffortSelector = currentModelMeta?.supportsEffort === true;
```
supportsEffort: trueis set on Claude variants insrc/lib/provider-catalog.ts(Sonnet / Opus / Haiku roles, plus Fable 5 at lines 240, 250, 260, 290, 301, 314, 325, 344, 355, 370, 385, 396, 428, 437) but not on GLM models configured via the env provider. When a user selects GLM,currentModelMeta.supportsEffortisundefined, soshowEffortSelectorisfalseand the dropdown never renders. There is no way inside the UI to setselectedEffortto anything other than the'auto'default.The downstream plumbing already works
Once
selectedEffortis anything other than'auto', the value flows through cleanly:src/app/chat/page.tsx:890:```tsx
...(selectedEffort && selectedEffort !== 'auto' ? { effort: selectedEffort } : {}),
```
src/lib/claude-model-options.ts:102-144(sanitizeClaudeModelOptions) passeseffortthrough unchanged for any model that isn't Opus 4.7/4.8/Fable 5. GLM matches neither theOPUS_ADAPTIVE_THINKING_PATTERNnor theFABLE_PATTERN, soeffort: 'max'would reach Z.ai's endpoint as-is.The
EffortSelectorDropdownitself also already falls back to the full 5-level set whensupportedEffortLevelsis undefined:src/components/chat/EffortSelectorDropdown.tsx:36:```tsx
const baseLevels = supportedEffortLevels || ['low', 'medium', 'high', 'xhigh', 'max'];
```
So the only thing missing is the capability flag on GLM model entries.
GLM-5.2 does support effort tiers
Per Z.ai's "How to Switch Models" doc:
GLM-5.2 exposes at least
HighandMaxeffort tiers. Users running the Claude Code CLI directly against Z.ai can reach them via/effort max. CodePilot users cannot, because the UI gate is closed. (CodePilot also does not forward/effortas a slash command to the underlying SDK, so there's no escape hatch.)Suggested fixes
In order of preference:
Mark env-provider models with
supportsEffort: trueby default so the dropdown renders for any Anthropic-compatible endpoint (GLM, DeepSeek, Kimi, etc.). Downstream code handles unknown effort values gracefully, and the endpoint will either accept the level or ignore it.Add explicit GLM entries to
ENV_CLAUDE_CODE_MODELSwithsupportedEffortLevels: ['high', 'max']matching what Z.ai's endpoint actually documents, so the dropdown surfaces only the levels GLM-5.2 truly supports.Workaround
None inside CodePilot today. Switching to Opus surfaces the dropdown (Opus has
supportsEffort: true), but that's not a real fix for users who chose GLM for cost or quota reasons.