As you may (or may not) know, Cursor is currently suffering from a bug that prohibits its ability to edit existing code files - your edit_file tool is broken. I blew through all my fast requests dealing with this issue and now I’m on slow requests, which is actually great because I get to test if the bug still exists every few hours, on your dime.
But my fast requests will renew in 5 days and it’s not looking like this bug is getting fixed anytime soon. I’m worried I’ll just blow through all my fast requests testing to see if its fixed.
Could you implement a way for us to turn off fast requests when your software has major bugs like this so not only does it save us from wasting money but also gives you more of an incentive to fix the bug?
Would be super helpful and the right thing to do to cover for situations like this. Thanks.
You may have done the same thing I did by accident.
By default, there’s an Agent and Chat option (If memory serves, I’ve renamed mine.); neither can be removed. I accidentally edited the Chat agent with a different name and had been using it for a documentation agent, enabling edits, etc. I didn’t realize until after I also ran through a number of fast credits that the agent cannot edit files, whether you enable it or not.
Test this by making a new agent, giving it the abilities you’d like, and having it edit files. It should solve your problem.
That’s not the issue. I didn’t rename anything. This bug is affecting hundreds, perhaps thousands of Cursor users. We’ve already narrowed it down to the edit_file function that Cursor uses to edit files being broken - with the issue cropping up especially when trying to remove lines of code from an existing file.
Ok, well all I’m saying is that the UI isn’t the greatest with the chat agent and while you can enable file edits, it will never edit files and will tell you it doesn’t have the ability to do so, even with the option to allow it enabled.
Yes, I’ve experienced this. I’ve had a couple today. It stops cold turkey for no apparent reason.
It’s far more noticeable with 3.7 thinking and 3.7. I still get it with 3.5, but not nearly as much. I’ve also seen it happen more often when the GPU renderer or CPU is using a lot of system resources.
I wonder if it’s a timeout issue with the tool call. Because of higher CPU or GPU utilization, it can’t complete the call in the given time and simply times out. If it’s a case, it’d be nice to see better retry logic to attempt the call again without simply stopping cold.
Hey, we don’t plan to add a feature like this yet, unfortunately, as slow requests are intended as a backup for when your fast requests run out!
The bug you describe has now been fixed, but feel free to drop us an email at [email protected] and we’ll be happy to compensate you for the issues you’ve seen.