# Bug: GLM-5 (Modal Research) — Agent tool calls return empty (no output, no error)

Describe the Bug

Environment

  • Cursor version: 3.0.13 (commit/distro: d5c0e77a0214208f36b56d42e8e787de88d02ea4)

  • OS: Windows 10 (22H2, build 19045)

  • Workspace: E:\PROYECTOGAMBUSINAS (local drive, trusted folder)

  • Model: GLM-5 via Modal Research (OpenAI-compatible endpoint)

  • Other models in same workspace: Claude, GPT-4o — all work fine

Description

When using GLM-5 (Modal Research) as the Agent model, all tool calls (Read, Shell, Glob) return completely empty — no output, no error, no status code. The tools appear to execute but produce zero response. Other Cursor-native models in the exact same workspace and session work correctly, confirming this is not a workspace trust, sandbox, or filesystem issue.

Steps to Reproduce

  1. Open Cursor 3.0.13 on Windows 10 (22H2, build 19045)

  2. In Settings → Models, configure GLM-5 via Modal Research (OpenAI-compatible endpoint, API key per Modal)

  3. Open workspace E:\PROYECTOGAMBUSINAS (trusted folder)

  4. In Agent, request e.g.: “Read Las-Gambusinas\services\configuracionService.js” or “Run dir on the project root”

  5. Observe that Read / Glob / Shell return no output and no error message

  6. Switch to a Cursor-native model (e.g. Claude or GPT-4o) and repeat the same request: tools return results correctly

Expected Behavior

Read, Glob and Shell should return file contents, directory listings, or terminal output — same as with Cursor-native models.

Actual Behavior

All three tools (Read, Shell, Glob) return empty with no error:

  • Read: no file content shown

  • Glob: no file list returned

  • Shell: no command output, no exit code

No error message is displayed — the failure is completely silent.

Likely Cause

GLM-5 / Modal Research endpoint does not correctly format tool_calls responses in the OpenAI-compatible schema that Cursor expects for agent tools. The model may be:

  • Omitting tool_calls from its response entirely

  • Returning malformed JSON in tool call arguments

  • Using MTP/speculative decoding that corrupts tool call JSON (this has been reported by other users in the community)

Workaround

  • Use a Cursor-native model (Claude, GPT-4o, etc.) for Agent tasks

  • GLM-5 can still be used for chat without tool requirements

Related

  • Community reports indicate disabling MTP (--speculative-config.method mtp) on self-hosted vLLM can fix similar tool calling corruption

  • Cursor ≥ 2.0.74 includes patches for external model tool calling — issue persists even on latest version

Request

Can the Cursor team investigate how the Agent tool call protocol handles OpenAI-compatible endpoints that may not fully conform to the expected tool_calls schema? A more descriptive error or fallback would help diagnose these issues faster.

Operating System

Windows 10/11

Version Information

Cursor: 3.0.13 (from package.json at E:\Program Files\cursor\resources\app\package.json). Commit/distro: d5c0e77a0214208f36b56d42e8e787de88d02ea4.

For AI issues: which model did you use?

GLM-5 through Modal Research (OpenAI-compatible API / base URL override in Cursor).

For AI issues: add Request ID with privacy disabled

4a11cfeb-8c69-41bb-89e4-5a01e234a3ec

Does this stop you from using Cursor?

Yes — Cursor is unusable

Hi,

Thanks for posting on the Cursor forum!

To help ensure most of our users can participate in discussions, this forum is currently English only.

If you’d like, you can edit your post to translate it into English. Once it meets our guidelines, it will be automatically relisted.

Specifically, the “Steps to Reproduce,” “Expected Behavior,” and “Version Information” sections contain Spanish text — translating those into English will bring the post in line with our guidelines.

Thanks for understanding!

Note: This is an automated detection system and sometimes makes mistakes. If your post is already in English, feel free to ignore this message, or just make a small edit and it will be reviewed again.

Same here:
Ubuntu 24.04.4, Cursor 3.0.16,

https://api.us-west-2.modal.direct/v1/chat/completions

also:

https://api.z.ai/api/coding/paas/v4

Models: GLM-5-FP8 (modal.direct) , GLM-5 + GLM-5.1 (z.ai)
Model GLM-5-TURBO seems to work correct at the moment.

Model: zai-org/GLM-5.1-FP8 via Modal Research
Request ID: 2f1f977f-0843-4710-8e59-cb232753dd28
Date: 2026-04-11
OS: Windows 10 (x64)
Cursor Version: Latest


Summary

When using GLM-5.1-FP8 via Modal Research as the agent model in Cursor, all tool calls (Read, Glob, Shell) fail silently — they return empty results with no error and no output. However, the same model, same API key, and same URL work correctly when used through the Roo Code extension inside Cursor.

What Works :white_check_mark:

  • Roo Code extension (v3.52.0) with provider openai → GLM-5.1 tool calls execute correctly and return results

  • Roo Code uses the endpoint /v1/chat/completions with OpenAI-compatible function calling format

What Doesn’t Work :cross_mark:

  • Cursor’s native agent with the same model → Read, Glob, Shell all return empty (no error, no content)

  • Cursor’s agent appears to either use a different function calling format or process tool call responses differently than Roo Code

System Checks (All Passed)

  • Drive E: Fixed NTFS, online, read/write :white_check_mark:

  • File existence and permissions :white_check_mark: (FullControl for all groups)

  • Files readable via PowerShell :white_check_mark:

  • Cursor process running normally :white_check_mark:

  • User hgartemis is owner of project folder :white_check_mark:

This confirms the issue is not related to file access, permissions, indexing, or the local environment.

Key Observation

The fact that Roo Code successfully executes tool calls with the exact same Modal endpoint and model strongly suggests that:

  1. Modal’s API does support OpenAI-compatible function calling via /v1/chat/completions

  2. The issue is specific to how Cursor’s native agent sends or processes tool call requests/responses, not the model’s capability

  3. Cursor’s agent may be using a different endpoint (e.g., /v1/responses), a different tool call format, or expecting a response structure that differs from what Modal returns

Reproduction Steps

  1. Configure GLM-5.1-FP8 via Modal Research (https://api.us-west-2.modal.direct/v1) in Cursor Settings → Models

  2. Open any project

  3. Ask Cursor’s native agent to read a file, search for files, or run a shell command

  4. All tool calls return empty — no content, no errors

  5. Install Roo Code extension in Cursor

  6. Configure the same Modal URL + API key with provider openai (not openai-native)

  7. Ask Roo Code to perform the same file/shell operations

  8. Tool calls work correctly and return results

Request for the Cursor Team

Could you investigate how Cursor’s native agent handles tool calls with custom OpenAI-compatible providers? There seems to be a compatibility difference between Cursor’s agent implementation and extensions like Roo Code that use the standard /v1/chat/completions + function calling format. Specifically:

  • Does Cursor’s agent use /v1/responses instead of /v1/chat/completions for tool calls?

  • Is there a difference in how the tool call response schema is parsed vs. the standard OpenAI format?

  • Could there be a fallback or compatibility mode for providers that don’t support the Responses API?

Request ID for server-side debugging: 2f1f977f-0843-4710-8e59-cb232753dd28

Having the same issue here.
I am working with the support team. I think there was a change recently from Cursor. When we pass GLM-5, cursor resolves it as glm-5 while z.ai expects GLM-5.

I think the solution should be extremely easy since GLM-5 used to work!

Found a solution from a different forum.
adding the following skill:

name: glm-native-workspace

description: Enforces Cursor-native workspace operations for z.ai GLM models (GLM-5, GLM-5.1, GLM-5-Turbo, and other GLM-* variants). Forbids shell commands for listing, searching, reading, creating, editing, or deleting files and folders, requiring native Cursor tools (read_file, edit_file, list_dir, codebase_search, grep, glob) instead. Use when the user selects a GLM or z.ai model, mentions z.ai or GLM, or requests a native-IDE-only workflow without terminal file operations.

-–

# GLM Native Workspace Operations

## Purpose

This skill applies to every conversation with z.ai GLM models (GLM-5, GLM-5.1, GLM-5-Turbo, and other `GLM-*` variants). It forces the agent to use Cursor’s native IDE tools for all workspace exploration and file modifications, rather than shelling out to the terminal.

## Mandatory Pre-Action Step

Before taking ANY action, review the available tools and choose the appropriate native Cursor tool for the job. Avoid manual CMD, Bash, or PowerShell execution for file or folder operations.

## Strictly Forbidden

Under NO circumstances should the agent use terminal commands, shell scripts, Command Prompt, or PowerShell to read, write, modify, delete, or list files and folders.

Do NOT use terminal commands such as:

| Purpose | Forbidden Commands |

|---------|--------------------|

| Listing / Searching | `ls`, `dir`, `tree`, `find`, `grep`, `rg`, `Get-ChildItem` |

| Folder Operations | `mkdir`, `rmdir`, `rm -rf`, `New-Item`, `Remove-Item` |

| File Reading | `cat`, `head`, `tail`, `less`, `more`, `Get-Content` |

| File Writing / Editing | `echo >`, `>`, `>>`, `vim`, `nano`, `sed`, `awk`, `Set-Content`, `Out-File` |

## Required Native Tools

Always route workspace work through Cursor’s native tool surface:

| Task | Use Native Tool |

|------|-----------------|

| List folder contents | `list_dir` / workspace file explorer |

| Find files by name/pattern | `glob_file_search` |

| Search file contents | `grep` / `codebase_search` |

| Read a file | `read_file` |

| Create or edit a file | `edit_file` / `write` |

| Delete a file | `delete_file` |

| Understand code semantically | `codebase_search` |

## Allowed Terminal Use

Terminal execution is reserved ONLY for:

- Running applications (e.g. `python app.py`, `node server.js`)

- Executing tests (e.g. `pytest`, `npm test`)

- Starting local servers or dev watchers

- Package management (e.g. `pip install`, `npm install`, `uv sync`)

- Version control commands explicitly requested by the user (e.g. `git status`, `git commit`)

If a task requires a shell command outside this list, stop and use the native tool equivalent instead.

## Decision Flow

1. Need to inspect or modify the workspace? → Use a native tool.

2. Unsure which native tool applies? → Re-check the available tool list before acting.

3. About to type `ls`, `cat`, `mkdir`, `echo >`, `sed`, etc.? → STOP. Switch to the native tool.

4. Shell command is purely about running code, tests, servers, or installers? → Proceed via terminal.

## Examples

**Correct**

- “I need to see what’s in `src/`.” → Call `list_dir` on `src/`.

- “Open `README.md`.” → Call `read_file` on `README.md`.

- “Create `src/utils/logger.ts`.” → Call `edit_file` / `write` with the new path.

- “Find every usage of `fetchUser`.” → Call `grep` or `codebase_search`.

- “Run the test suite.” → Run `pytest` or `npm test` in the terminal.

**Incorrect**

- Running `ls src/` to inspect a folder.

- Running `cat README.md` to read a file.

- Running `mkdir -p src/utils && echo “…” > src/utils/logger.ts` to scaffold a file.

- Running `grep -r “fetchUser” .` instead of the native grep/search tool.

## Compliance Checklist

Before responding, confirm:

- [ ] No forbidden shell command was used for file/folder ops.

- [ ] Every file read went through `read_file`.

- [ ] Every file or folder mutation went through `edit_file` / `write` / `delete_file`.

- [ ] Every search went through `grep`, `codebase_search`, or `glob_file_search`.

- [ ] Terminal use, if any, was limited to running apps, tests, servers, or package managers.

and GLM works!