Kimi k3 chat stop random all the time

Support Bug Reports
1

Describe the Bug

With Kimi K3, the chat intermittently stops on its own. You can see this in the bottom-right corner: when the stop icon is displayed, the chat is still running; when the microphone icon appears, it has stopped.

Over the past few years, we have occasionally experienced similar issues with other models that were not Anthropic or OpenAI models. It is therefore difficult to determine whether these issues are LLM-specific, meaning the LLM stops independently, or whether they are related to orchestration in Cursor.

Are these issues known, and why do they occur? Is this LLM-specific, with nothing Cursor can change, or is this a Cursor issue?

Steps to Reproduce

see desc

Operating System

Windows 10/11

Version Information

Version: 3.15.19 (user setup)
VS Code Extension API: 1.128.0
Commit: de07bee81cefe43461ebf4f40c3d2d78d15052a0
Date: 2026-08-11T05:22:54.627Z
Layout: IDE
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.291
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

5

image
image678×945 37.2 KB

7

Hi @ddd1345 Thanks for the post. This sounds like an intermittent model issue, can you let me know if you’re still getting this consistently? It may have resolved since your original post.

8

Today I got this problem like 20-30 times at daytime

Now later in the evening it went smoother

I live Berlin UTC

9

I have also noticed that with Kimi K3, when I run a prompt intended to create a handoff, it simply starts over from the beginning. In other words, even if the handoff report is sent to me in the chat, once it has finished, it suddenly starts again from the beginning and reruns the prompt.

The same thing happens if the file is written physically; it does not work in that case either. When I use another model, such as GPT 5.6, the issue no longer occurs.

To be honest, I am not entirely sure whether this issue is:

  • LLM-specific, as with Kimi K3, or
  • related to Cursor orchestration.

In my view, it looks more like a Cursor orchestration issue. The handoff report is generated completely to the end, and then it starts over from the beginning. I cannot imagine that this would even be technically possible from the LLM’s perspective. There must be some incorrect behavior somewhere that causes it to restart.

It may also be related to the issue above, where the chat suddenly stops. The stopping issue could potentially be LLM-specific, but the second issue I am referring to does not seem likely to be caused by the LLM. It appears more likely to be at the agent orchestration layer provided by Cursor.

Throughout the day today, I have probably tried to create 10 to 15 handoffs, but I kept getting stuck in endless loops and having to start over. As a result, I also wasted an extremely large number of tokens.

@kevinn

10

One thing I just noticed: Kimi K3 sometimes takes an incredibly long time to respond in the chat. For a 2,000–3,000-line report, it can take 10–15 minutes.

11

I noticed that when the context window is very small, the handoff reports work with the same prompt. However, when I am at around 50%, or roughly 40% and above, and then try to create a handoff report, it keeps failing.

12

Today, a handoff worked at 60–70% of the context window.

Based on the results of the last attempts, I strongly assume that this is not LLM-specific but related to Cursor. Otherwise, why would it suddenly not work at all consistently on a specific day and now work without any issues?

The speed has increased, and the handoff was created. I strongly assume that this is a Cursor orchestration issue, wherever the underlying problem originates.

13

Could there perhaps be a limit at the Cursor level regarding the size of the response text and/or what can be written to files, where no error message is shown, but it simply stops and starts over from the beginning? Could that be the issue?

14

@deanrie @kevinn

I strongly suspect there is some kind of limit at 2,000 or 3,000 lines in the response, or that calling MCP tools causes the chat to restart from the beginning due to a technical issue.

Could someone from the Cursor team please verify this? I do not know how much money I have already wasted because handoff reports keep starting over from the beginning.

I strongly assume that this does not occur with other models, such as Anthropic—or OpenAI, because they are not as detailed as Kimmy.

When Kimi creates handoff reports, they are much more detailed and longer. This is likely why we are reaching the maximum limit. Could someone please confirm this?

15

A workaround is definitely to set a user-specific rule that creates batches of 1,000 lines once a file reaches 2,000 lines. This avoids the issue, but of course it is not a proper solution.

I noticed that the problem occurs when handoff reports grow iteratively. In a normal default state, it is probably difficult to reach a point where a handoff report contains 2,000 to 3,000 lines, or where an LLM sends content of that size. However, if additional handoff reports are created iteratively and passed along with the remaining open tasks and/or whatever is currently being worked on, the issue occurs once a maximum size is reached.

I do not know whether this also happens when the context window is small. What I can say is that at 40%+ utilization, when creating very large handoff reports and the response becomes extremely large, the system gets stuck in an infinite loop.

  • No file can be created using Cursor’s internal edit_file tool.
  • The normal response in the chat does not work either, because it starts over from the beginning again.
  • The same happens with the MCP tool when I try to write a file using my own MCP tool.

Across all three levels, the behavior is the same: it simply starts over from the beginning. This looks very much like a Cursor bug.

Over the last few days, I have tried to create a handoff report with Kimi K3 at 50%+ at least 50 times. I do not know how much money I have already spent on this. I would appreciate it if you could please offer some form of accommodation here.

16

Problem still active. Still no response from devs.

Please verify if you have response limits which are causing those problems

@Colin

17

Hi @ddd1345

Thanks for following up, and sorry for the delayed answer. I checked a recent occurrence, and your response-limit theory is partly correct.

There is no fixed 2,000 or 3,000-line limit. The affected Kimi run reached a per-response token limit. Cursor then attempted to continue automatically, but subsequent model streams timed out after returning partial output, triggering resume attempts. This combination can make completed-looking work appear to start again.

This is not specific to your MCP tool or file-writing method. I also found no hard threshold at 40% context usage. Context usage and the per-response limit are separate.

Your 1,000-line batching rule is the most reliable workaround for now. A fresh chat can reduce context pressure, but it will not remove the response limit. Using another model for especially long handoffs is also reasonable.

To help verify the exact repeated content, if you are comfortable, temporarily enable Share Data, reproduce it once, then use the conversation menu to copy the Request ID and post it here. You can turn Share Data off again afterward. These steps explain how: Reporting a bug | Cursor Docs

18

Thank you very much for your response.

Does this issue occur only with Kimi, or with other models as well? You wrote that I should switch to another model and that the issue would not occur there. But I want to use KImi cause of the response layout.

If it only affects Kimi, what does that mean? Does it mean that an external provider is being used that has a per-response token limit? What would the corresponding solution be going forward? Why is there no per-response token for other models?

At present, we do not know what is happening, we get stuck in an endless loop, and we are unable to create detailed handoff reports.

What is the future-oriented solution in this regard?

Please remove any limits :confused:

19

Thanks, these are fair questions. Switching models was only suggested as a workaround, not because other models have unlimited responses. All models have finite per-response token limits, and the limits and recovery behavior vary by model. Kimi is served through Cursor’s inference partners, but these limits are not unique to Kimi or externally hosted models.

In the occurrence I checked, Kimi reached its output limit. Later streams returned partial output before timing out, after which Cursor resumed from saved state. That sequence is consistent with the restart loop you described.

20

I took a quick look at the chat, and when the limit is reached in the Thinking window, a message appears indicating rate limiting at the model provider. This confirms exactly what is described here: an external model provider is being used, and a limit is then reached.

This occurs during the LLM’s internal reasoning process. I therefore strongly assume that, beyond a certain size, these limits are reached, regardless of how this is currently implemented—via a streaming service or otherwise. This is a fundamental architectural issue.

For example, it means that handoff reports cannot be created. Hypothetically, if there is a 15,000-line handoff report that needs to be summarized because certain tasks have already been completed, and the resulting summarized handoff report would be 6,000 lines, Kimi simply cannot process it because of the rate limits.

This is extremely limiting.

Also, even when a system rule is used to create individual batches, limits keep arising in the internal reasoning process because it is expected to consider in advance how the entire full response will be packaged together.

This means we need to use prompting techniques and workarounds to ensure that all topics are created on a chunk-by-chunk basis, rather than overloading the internal reasoning process through rate limiting. From a prompting architecture perspective, this is, of course, extremely suboptimal, with potentially significant downstream consequences for the handoff reports generated as a result.

This means we need to use prompting techniques to implement append logic, so that only segments are created. Architecturally, we must prevent the model from building the complete full response in its internal reasoning process first and only then creating the batches or chunks.

Instead, we need to ensure that each individual segment is created first, then re-anchored, and then reconsidered. Of course, this is incredibly suboptimal.

I would greatly appreciate it if more effort could be invested in this topic. Kimi is currently one of the best models, and it is extremely limiting that this does not work.

For several years now, I have continuously opened posts here about various limitations related to MCP topics, including issues where content is written to text files, which still have not been resolved, or still no support for custom system prompts, as well as many other issues.

I would truly appreciate it if this topic could be addressed with a higher priority than the other items that are still open.