Cursor Native Agent fails with glm-5.2 via OpenAI-compatible provider, while other agents work

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:

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:

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:

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:
https://opencode.ai/zen/go/v1/
  1. Use a valid OpencodeGo API key.
  2. Set the model ID to:
glm-5.2
  1. Start a Cursor Native Agent request.
  2. Cursor fails with:
ERROR_BAD_USER_API_KEY
Invalid API key.
Unauthorized User API key

Control checks:

- 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

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.

It’s there!

kimi-k2.7-code is also no longer usable.

Request ID: c2b70bdd-3332-4d5f-b2a6-7c7158260483

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?