False positive loop detection when using custom model (qwen3-coder-plus) with repetitive reasoning text before different tool calls

[argrigorov (Artem)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When using a custom model (qwen3-coder-plus) via a self-hosted LLM proxy server with an OpenAI-compatible endpoint, which normalizes tool calls and works around tool invocation issues for this model, the agent is frequently stopped with the error “Unrecoverable agent model looping detected” even though it is making legitimate progress on the task.
The issue appears when the model performs code analysis that requires many tool calls (searching the codebase, reading files), including calling several tools in parallel within a single turn.

What happens is that, before each block of tool calls, the model produces a short explanation of what it is going to do next.
This explanatory text is often very similar or even identical across turns, while the actual tool calls in the same turn are different (different tools, different parameters, or multiple parallel tool invocations).
The loop detection mechanism seems to focus mainly on the similarity of this reasoning text and therefore incorrectly concludes that the agent is stuck in a loop, even though the sequence of tool calls is changing and the model is progressing through the codebase.

Steps to Reproduce

1. Configure Cursor to use the custom model qwen3-coder-plus served by vLLM, or a similar self-hosted LLM proxy, via an OpenAI-compatible endpoint that supports Qwen models and normalizes and fixes tool invocation and tool result handling for this model.

2. In Ask or Agent mode, give the model a task that requires extensive project-wide analysis, for example: “Analyze the project files and find code duplication that can be optimized.”

3. Let the model run; observe that it starts invoking tools (often multiple tools in parallel in a single turn) and prints similar or identical explanatory text before each group of tool calls.

4. After a few such turns, even though the tools and their parameters are different, the run is terminated with the error “Unrecoverable agent model looping detected”.

Expected Behavior

• The agent should be allowed to continue as long as the sequence of tool calls is actually progressing, including cases where several tools are invoked in parallel in a single turn.

• Loop detection should take into account which tools are being called, with what parameters, and how the set of files or queries changes over time, rather than relying mainly on the similarity of the explanatory text between tool calls.

• Repetitive reasoning text alone (for example, repeating the same description of the next high-level step) should not be enough to classify the behavior as an infinite loop if the underlying tool actions are different.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.1.47 (user setup)
VSCode Version: 1.105.1
Commit: 2d3ce3499c15efd55b6b8538ea255eb7ba4266b0
Date: 2025-12-04T02:31:50.567Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.17763

For AI issues: which model did you use?

Сustom model qwen3-coder-plus served by vLLM, or a similar self-hosted LLM proxy, via an OpenAI-compatible endpoint that supports Qwen models and normalizes and fixes tool invocation and tool result handling for this model.

Additional Information

This issue has been reported with other custom models (Qwen family, Gemini, Grok). The loop detection logic needs to be refined for models that use structured reasoning patterns where explanatory text may be similar but underlying actions are distinct and progressive, especially when parallel tool calling is involved.

Partially - It does not make using custom models impossible, but significantly complicates and slows down the workflow for multi-step agent tasks.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report. This looks like a known false positive from loop detection. You can’t disable the detector right now.

To pass this case to our engineers, please share:

• 1-2 exact prompts that reproduce it
• Request IDs of failed runs: Chat top-right → Copy Request ID
• Whether it reproduces without your proxy on the built-in model in a new Agent chat
• A short note about your proxy and how it normalizes tool calls, plus tool call logs/traces that show calls differ while the reasoning text repeats

As a temporary workaround, try:

• Breaking the task into smaller steps and removing repetitive explanations in the prompt
• Running in a new Agent chat without switching models mid-conversation

Send the details and I’ll share them with the team.

[argrigorov (Artem)]

Hi Dean,

Here are the details you requested:

1. Exact prompts that reproduce the issue:

Original prompt (Russian):

Проанализируй проект и найди места дублирование кода, которые можно вынести и оптимизировать - укажи модули и номера строк и напиши список мест без листингов кода.

Большие файлы читай блоками строк. Не используй grep - используй ТОЛЬКО чтение файла.

Перед вызовов инструментов пиши РАЗНЫЕ комментарии. Описывай - какие инструменты и зачем ты вызываешь в каждом конкретном случае. Иначе, из-за твоих одинаковых комментариев, Курсор начинает думать, что ты зациклился. Текст перед вызовом инструментов ДОЛЖЕН быть разным!

Отвечай на русском.

English translation:

Analyze the project and find code duplication that can be extracted and optimized - specify modules and line numbers and write a list of locations without code listings.

Read large files in blocks of lines. Don't use grep - use ONLY file reading.

Before calling tools, write DIFFERENT comments. Describe - which tools and why you are calling them in each specific case. Otherwise, due to your identical comments, Cursor starts to think that you are stuck in a loop. The text before calling tools MUST be different!

Respond in Russian.

2. Request ID of failed run:

• Request ID: 541aebfe-487a-4fa2-bd8a-7dccb62594e2

3. Whether it reproduces without proxy on built-in model:
This issue occurs very rarely with built-in models (Claude, GPT) in Auto mode, and when it does, it’s often justified. With custom models via the proxy (especially Qwen family), it happens more frequently and is usually a false positive.

4. Proxy description and tool call normalization:

About the proxy:
AGIWS Gateway is an LLM proxy server with an OpenAI-compatible API endpoint. I’m developing this server using Cursor IDE, and the logs contain full request payloads from Cursor and full response payloads that the server returns to Cursor. I specifically started the server with clean logs to reproduce this issue, so the log file contains only entries related to this specific problem.

How the proxy normalizes tool calls:
The proxy performs normalization and validation of tool calls for Qwen models (and others) to ensure compatibility:

1. Tool call ID generation: If missing, generates IDs in format call_{timestamp}_{random}.
2. JSON argument parsing: Converts JSON strings to objects for validation; attempts to repair common JSON errors (trailing commas, unclosed strings).
3. Validation: Checks required fields (id, function.name, function.arguments) and validates arguments against tool schemas.
4. Back-conversion: Before sending to the client, converts arguments back to JSON strings (OpenAI-compatible format).

5. Tool call logs/traces showing calls differ while reasoning text repeats:

From the attached log file gateway-2025-12-05.log.txt, here are examples showing that tool calls differ while the reasoning text is similar or identical:

Example 1 - Message 8 (around line 18527):

• Reasoning text: “Для анализа проекта на предмет дублирования кода мне нужно изучить основные модули. Я начну с чтения главного файла gateway.py (который я уже прочитал), затем изучу основные модули в src/agiws_gateway/. Я буду читать файлы параллельно, чтобы ускорить анализ.”
• Tool calls: 1 tool call - read_file for src/agiws_gateway/core/config.py

Example 2 - Message 10 (around line 26670):

• Reasoning text: “Для анализа проекта на предмет дублирования кода мне нужно изучить основные модули. Я буду читать файлы параллельно, чтобы ускорить анализ.”
• Tool calls: 3 parallel tool calls - read_file for src/agiws_gateway/core/server.py, src/agiws_gateway/core/main.py, and src/agiws_gateway/api/common/models_manager.py

Analysis:
The reasoning text is very similar or identical across turns, but the actual tool calls are different:

• Different tools being called (read_file with different file paths)
• Different number of tool calls (1 vs 3 parallel calls)
• Different parameters (different target files)

This demonstrates that the model is making legitimate progress through the codebase, exploring different files and using parallel tool calls efficiently, but the loop detection mechanism incorrectly flags this as a loop due to the similarity of the explanatory text.

Additional context:
The log file shows multiple instances where the same reasoning pattern appears (“Для анализа проекта на предмет дублирования кода мне нужно изучить основные модули…”) but with different tool calls each time, indicating progressive analysis rather than a loop.

---

Thank you to the Cursor IDE development team for this excellent product. I wish you success in bringing it to perfection.

Best regards,
Artem
gateway-2025-12-05.log.txt (20,0 МБ)

[argrigorov (Artem)]

Thanks a lot for looking into this issue and for all your work on Cursor.

After the recent updates to Cursor, improvements to the Qwen3 Coder model, and an additional system‑prompt injection on my own server side, I’m no longer seeing the false loop‑detection problems in my workflows. Everything has been running smoothly in scenarios that previously failed, so from my side the issue now appears resolved.