# Cursor Native Agent fails with glm-5.2 via OpenAI-compatible provider, while other agents work **URL:** \ **Category:** Bug Reports\ **Tags:** byok\ **Created:** [June 24, 2026, 12:12pm UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986 "2026-06-24T12:12:56Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Theo\_Yao](https://avatars.discourse-cdn.com/v4/letter/t/e19adc/32.png) [@Theo\_Yao](https://forum.cursor.com/u/Theo_Yao)\ **Post date:** [June 24, 2026, 12:12pm UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986/1 "2026-06-24T12:12:56Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug Cursor Native Agent fails when using `glm-5.2` through an OpenAI-compatible custom provider. The error returned by Cursor is: ```plaintext Unauthorized User API key ``` However, this does not appear to be a globally invalid API key or provider configuration issue. The same API key and endpoint work correctly in Cursor with another model from the same provider, `kimi-k2.7-code`. The same `glm-5.2` model also works correctly outside Cursor in other coding agents, including Mimo Code, Z Code, and OpenCode’s own tooling. Provider configuration: ```plaintext Provider: OpencodeGo Protocol: OpenAI-compatible Chat completions endpoint: https://opencode.ai/zen/go/v1/chat/completions Models endpoint: https://opencode.ai/zen/go/v1/models Model ID: glm-5.2 ``` The `/models` endpoint lists `glm-5.2`, so the model ID appears to be valid. Only this specific combination fails: ```plaintext Cursor Native Agent + OpenAI-compatible custom provider + glm-5.2 ``` I also found a similar public report from another user using Volcengine Ark / Ark Coding Plan where `glm-5.2` started failing in Cursor with `Unauthorized User API key`, even after recreating the key and updating the request URL. This suggests the issue may not be limited to OpencodeGo and may involve Cursor Native Agent’s handling of `glm-5.2` through third-party / OpenAI-compatible coding providers. My suspicion is that Cursor Native Agent may be sending a request shape or model capability configuration that causes `glm-5.2` to fail, possibly related to tools, tool calling, streaming, reasoning parameters, tool result message format, or agent-loop context handling. ### Steps to Reproduce 1. Configure an OpenAI-compatible custom provider in Cursor. 2. Use the following chat completions endpoint: ```plaintext https://opencode.ai/zen/go/v1/ ``` 1. Use a valid OpencodeGo API key. 2. Set the model ID to: ```plaintext glm-5.2 ``` 1. Start a Cursor Native Agent request. 2. Cursor fails with: ```plaintext ERROR_BAD_USER_API_KEY Invalid API key. Unauthorized User API key ``` Control checks: ```plaintext - The same API key and endpoint work in Cursor with kimi-k2.7-code. - The same glm-5.2 model works in Mimo Code. - The same glm-5.2 model works in Z Code. - The same glm-5.2 model works in OpenCode’s own tooling. - The provider’s /models endpoint lists glm-5.2. ``` ### Operating System MacOS ### Version Information Version: 3.8.23 VS Code Extension API: 1.105.1 Commit: 7cf19b7482706625cdb70db3211b7dd035b7aa30 Date: 2026-06-23T14:57:42.334Z Layout: glass Build Type: Stable Release Track: Default Electron: 40.10.3 Chromium: 144.0.7559.236 Node.js: 24.15.0 V8: 14.4.258.32-electron.0 xterm.js: 6.1.0-beta.256 OS: Darwin arm64 25.5.0 ### For AI issues: which model did you use? glm-5.2 ### For AI issues: add Request ID with privacy disabled Request ID: 7bc44b41-704e-4927-8fbc-b926ec6c1d50 {“error”:“ERROR\_BAD\_USER\_API\_KEY”,“details”:{“title”:“Invalid API key.”,“detail”:“Unauthorized User API key”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:,“analyticsMetadata”:{“actionRequired”:“config”}},“isExpected”:true} Unauthorized User API key Invalid API key. Unauthorized User API key ActionRequiredError: Invalid API key. Unauthorized User API key at $ME (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11960:27378) at n4h (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11960:26526) at wYS (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11961:11427) at Object.classify (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11961:15943) at WME (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11961:5707) at async AYg.runWithSharedTurnRunner (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11961:15295) at async Bue.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:21284:3043) at async KFv.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:24462:13711) at async KFv.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:24462:22563) at async Cft.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:12048:2095) ### Does this stop you from using Cursor Yes - Cursor is unusable ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [June 24, 2026, 5:33pm UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986/5 "2026-06-24T17:33:57Z")
Hey, thanks for the detailed report with logs and the Request ID. That really helped. This is a bug on our side, not an issue with your key or config. In short, `glm-5.2` currently matches the name of a built-in model in our catalog, so your custom model gets resolved as managed. Because of that, Cursor sends a modified id to your provider, `glm-5.2-high`, instead of exactly `glm-5.2`. Your provider doesn’t recognize that id and returns an error that Cursor shows as `Unauthorized User API key`. That’s also why `kimi-k2.7-code` works, since there’s no id substitution there. There isn’t a clean client-side workaround right now. The provider needs exactly `glm-5.2`, but Cursor intercepts it. Until we ship a server-side fix, please use another model from the same provider, like `kimi-k2.7-code`. I’ve reported the issue internally. I can’t share an exact fix timeline yet, but I’ll post an update here as soon as I have one. ---
**Author:** ![Tom\_Coustols](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/tom_coustols/32/97175_2.png) [@Tom\_Coustols](https://forum.cursor.com/u/Tom_Coustols)\ **Post date:** [June 24, 2026, 10:09pm UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986/8 "2026-06-24T22:09:01Z")
> It’s there! ---
**Author:** ![russell](https://avatars.discourse-cdn.com/v4/letter/r/50afbb/32.png) [@russell](https://forum.cursor.com/u/russell)\ **Post date:** [July 5, 2026, 10:33am UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986/9 "2026-07-05T10:33:37Z")
kimi-k2.7-code is also no longer usable. Request ID: c2b70bdd-3332-4d5f-b2a6-7c7158260483 ---
**Author:** ![Dei26](https://avatars.discourse-cdn.com/v4/letter/d/f6c823/32.png) [@Dei26](https://forum.cursor.com/u/Dei26)\ **Post date:** [July 12, 2026, 3:31pm UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986/10 "2026-07-12T15:31:54Z")
Is it possible to enable the full 1M-token context window for GLM 5.2 in Cursor’s native Agent? I tested it in a new chat with Max Mode enabled, but the Context Usage panel still shows a maximum of 200K tokens. Is this currently a limitation of Cursor’s integration, or is there another setting required to use the 1M context window? ---
**Author:** ![guoxjtu](https://avatars.discourse-cdn.com/v4/letter/g/d2c977/32.png) [@guoxjtu](https://forum.cursor.com/u/guoxjtu)\ **Post date:** [July 19, 2026, 7:10pm UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986/11 "2026-07-19T19:10:44Z")
There still the bug with opencode go api and glm-5.2. Anyone slove it?😭 ---
**Author:** ![petralian](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/petralian/32/116228_2.png) [@petralian](https://forum.cursor.com/u/petralian)\ **Post date:** [July 31, 2026, 3:35am UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986/12 "2026-07-31T03:35:26Z")
Still waiting for this reasonably simple bug to be solved… Why not modify cursor requests to have a cursor specific ID… like instead of glm-5.2-high you would send cursor/glm-5.2-high. This is why open router requests keep working… as they use z-ai/glm-5.2 While I understand the commercial angle here @cursor team, but many people simply cannot afford to go all in on glm5.2 using api costs, and composer 2.5, while it is a beast, we would all love composer 2.7 or 3 to come out soon, instead of the overpriced grok 4.5 Asking opencode for support also [Opencode Go does not work with Cursor due to using same names for models · Issue #39801 · anomalyco/opencode · GitHub](https://github.com/anomalyco/opencode/issues/39801#issuecomment-5139083030) ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [October 4, 2026, 11:39am UTC](https://forum.cursor.com/t/cursor-native-agent-fails-with-glm-5-2-via-openai-compatible-provider-while-other-agents-work/163986/17 "2026-10-04T11:39:51Z")
Hey all, sorry for the silence here since June. Status: this is still open. On the BYOK path, the model ID collision is unchanged. Picking GLM 5.2 High still sends `glm-5.2-high` to a custom provider instead of the plain `glm-5.2` ID, so providers that only know the base ID reject it. No fix has shipped, and I can’t give an ETA. @petralian @guoxjtu @russell, thanks for the extra reports. They’re attached to the internal ticket. If any of you are still hitting this on the current version 3.23.x, a quick reply with your provider and the exact error helps us show it’s still happening. If a provider-side alias mapping `glm-5.2-high` to `glm-5.2` is an option on your end, that’s the only workaround I know of today.