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?
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.
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.
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.
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.
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.
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?
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?
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.
