Hi @here GLM 5.2 is now available in Cursor! To activate it, just head to Cursor Settings → Models and enable GLM 5.2. It will then be selectable in the model picker.
We’ve also added it to our evals here! Cursor · CursorBench
Is it available in enterprise version (Advanced Development)?
Thank you so much for the update!
It is available in Enterprise plans, as long as your admin does not have it blocked.
my pleasure 
Yo THANK YOU MY MAN.
I’m confused, GLM 5.2 is added officially, then if I override OpenAI Based URL to https://api.z.ai/api/coding/paas/v4, will it use my Cursor subscription or Z.ai’s coding lite?
idk if this url is supported, but when you turn on override the url, it should either 1 not work or indeed bill you with the z ai coding lite, but to be fair, I don’t know if it is supported yet
Thanks for the reply; I gave it a try, but it didn’t work.
The current process for adding custom models is a bit confusing: you simply add a “Custom Model” name, while the Base URL and other details are located under “API Keys,” with no clear link between the two. I believe the workflow should be: first add the service provider’s Base URL and API Key, and then add the specific models for that provider.
I agree the confusing part is the mental model.
A custom model name by itself does not tell you which provider, base URL, key, or billing path it belongs to. For BYOK setups, I’d expect the UI to group those together as one provider profile, then let models attach to that profile. Otherwise it is too easy to think you configured a model when you only configured a label.
Hey, thanks for the continued interest in GLM 5.2. We get the request for first-party support as a built-in model a lot, but I can’t share a specific timeline yet. I’ll keep this thread open, and I’ll post an update if I have one.
@usman724 about why BYOK GLM 5.2 isn’t working: this is a known bug on our side, not an issue with your key or config. Right now the name glm-5.2 matches a model in our catalog, so your custom model gets resolved as managed, and Cursor sends the provider a modified id glm-5.2-high instead of exactly glm-5.2. The provider doesn’t recognize it and returns an error that Cursor shows as Unauthorized User API key or Model name is not valid.
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 fix, please use another model from the same provider, for example kimi-k2.7-code. I’ve reported the issue internally, no ETA yet.
For details and updates on this specific bug, it’s best to track it in a separate thread: Cursor Native Agent fails with glm-5.2 via OpenAI-compatible provider, while other agents work so it doesn’t get mixed with the feature request discussion here.
Also, about OpenRouter for anyone trying it: it’s not officially supported. Supported BYOK providers are OpenAI, Anthropic, Google AI, Azure OpenAI, AWS Bedrock. If you’re using a direct OpenAI-compatible endpoint, for example a Z.ai key, and you still hit an error, send the Request ID with Privacy Mode off and we’ll take a look.
GLM 5.2 High tool-calling regression / harness format mismatch
Hi, congrats on adding GLM 5.2 High to Cursor! It is a game-changer that will attract plenty of devs due to its sweet spot of quality, speed, and cost.
Today, GLM 5.2 High started struggling with the harness for tool calling—while the same workspace/terminal with Gemini 1.5 Flash works perfectly.
The Issue:
The model gets stuck in a loop outputting raw text that looks like a custom XML tool call instead of invoking the actual API-level tool-calling mechanism. Because the harness doesn’t recognize this raw text as a valid tool invocation, the tool is never executed. The model
then hallucinates that it “waited” for the result, gets confused, apologizes, and repeats the same broken XML format.
Example of the broken output:
│ The user is frustrated because my Read calls keep glitching. Let me try Grep with proper
formatting.
│ <tool_call><arg_key>-n</arg_key><arg_value>true</arg_value><arg_key>output_mode</arg_key>
<arg_value>content</arg_value><arg_key>path</arg_key><arg_value>FILE_PATH</arg_value>pattern</arg_key><arg_value>session|max_length|limit|Field</arg_value></tool_call>
Diagnosis:
• Format Mismatch: The model is reverting to a custom XML-like syntax (<tool_call><arg_key>…</arg_key></tool_call>) instead of using the standard JSON tool-calling schema expected by the Cursor execution harness.
• No Execution: Because the harness doesn’t parse this XML as an actual tool call, the system never executes it, leading to silent freezes or infinite loops.
• Potential Fix: The system prompt/priming for GLM 5.2 High might need to be adjusted to explicitly enforce the JSON tool-calling schema, or the parser needs to be updated to handle this XML format if the model is prone to reverting to it.
Hi @guillermogonsan Thank you for the post! This is a known issue and we have a bug report raised, we’ll let you know when it’s sorted!