fix: GLM thinking values, remove output popup, filter enabled models — fixes #61, #67, #62

[Wallacy]

fix: GLM thinking values, remove output popup, filter enabled models — fixes #61, #67, #62

Goal

Fix three reported bugs: GLM accepting invalid thinking values, unwanted output channel popup, and model list showing disabled/unavailable models.

What was implemented

#61 — GLM thinking allows invalid values

• Remove "on" from opencodego.thinking.glm enum — GLM 5.2 only accepts off/high/max per models.dev
• buildThinkingPayload now sends reasoning_effort for GLM when the value is effort-based (high/max); only "off" maps to thinking: { type: "disabled" }
• buildFamilyThinkingSchema split into separate blocks for GLM and Kimi (were combined in a single if)
• Updated validate-models.mts to test GLM with high/max instead of on
• Updated package.json with correct enum and concise description

#67 — Annoying output window popup

• Removed 3 this.getOutputChannel().show(true) calls in testConnection() (success and error paths) and in provideLanguageModelChatResponse() error catch

#62 — Display only enabled models

• fetchModels() already sent Authorization: Bearer <key> header, but the key was only read from secret storage internally. Now the API key is passed explicitly from provideLanguageModelChatInformation() to fetchModels(), ensuring the header always carries the correct key

Changelog

Fixed:
- GLM 5.2 now only accepts off/high/max (removed invalid "on")
- GLM high/max now send reasoning_effort instead of thinking toggle
- Output channel no longer pops up randomly during requests
- Model list fetch always sends Authorization header with the correct API key

Testing

86/86 unit tests pass. GLM dry-run on validate-models.mts confirms:

• GLM 5.1: high → {"thinking":{"type":"enabled"}}
• GLM 5.2: high → {"reasoning_effort":"high"}, max → {"reasoning_effort":"max"}

[ltmoerdani]

nice one, clean fix for 3 bugs at once. I went through the code:

#61 GLM thinking good approach sending reasoning_effort directly for effort-based values and letting the gateway handle resolution. Splitting glm || kimi into separate blocks makes sense too since they behave differently now. One small question: if a user already has glm: "on" saved in their workspace config, buildThinkingPayload will send reasoning_effort: "on" to the gateway. Will that fail gracefully or could it error out? If it might cause issues, might be worth adding a fallback on → high in buildThinkingPayload before it hits the gateway.

#67 output popup the show(true) calls were just in the wrong spots. Error handling via showErrorMessage is enough on its own.

#62 filter models clean, one-line change at the call site makes fetchModels more reusable. Nice.

102 lines of new tests covering effort values, schema generation, override, and invalid value rejection. Solid coverage.

I tested locally, works well. Merged ready. The stale GLM "on" config question is optional though, depends on how the gateway handles it, if it's graceful, just skip it.