On my 2015 intel mac, running 3.5.33, before the rug-pull last night, the cursor interface would experience very long hangs… not taking input for 45s periods, then catching up. Fable was saying it was because of all the screenshots I was using in my bug reports. The system itself behaved normally. It would get worse with each request, and eventually I’d restart. Now that I’m forced back to Opus 4.6, it doesn’t finish requests… just eventually hangs or the cursor SDK crashes and needs reloaded. I haven’t seen a summary all day. Still, the system responsiveness for everything else is fine… just cursor
Steps to Reproduce
Use the interface and eventually it hangs or crashes.
Expected Behavior
Not to hang nor crash
Operating System
MacOS
Version Information
Mac OS Monterey, 12.7.6, Mid 2015 Macbbook, Cursor 3.5.33,
Hey, thanks for the detailed report. I’ll break it down because there are actually two separate things here.
Freezes and crashes. From our data, the requests reach the server and complete normally, so this isn’t a server issue. It’s the client app getting overloaded. The pattern is pretty classic: the renderer slowly builds up memory and CPU usage over a long chat, especially with lots of pasted screenshots, it gets slower and slower, and eventually freezes. Restarting clears it. Fable was right about this, big pasted images speed up the slowdown a lot.
What will actually help:
Update Cursor. You’re on 3.5.33, the current branch is 3.10.x, that’s several minor versions behind with lots of stability and memory fixes.
Start new chats more often instead of one endless thread. A long chat keeps dragging all the accumulated context with it.
Use fewer and larger screenshots per chat. Lots of big images stay in memory.
Also worth being honest: a mid-2015 Intel MacBook on Monterey is below the comfortable threshold for heavy agent usage. Limited RAM, integrated graphics, older OS. The renderer in Cursor is the most resource-hungry process, so it’s usually the first to freeze while the rest of the system looks “fine”. On that hardware, updating plus shorter sessions will help as much as possible, but it won’t be magic.
About the “rug-pull” with Fable. That’s a separate plan change (Fable moved under Max Mode on the legacy individual plan) and it’s not related to the freezes. Discussion and details are here: Legacy Individual Plan - Max Mode Required, it’s best to post about that there.
Update your version, try shorter sessions, and let me know if it feels better.
No, I’m gun-shy of upgrading, as I fear more rug-pulling. I very much fear the token model where you can’t estimate for me what it’s going to cost before I ask. One reason why I don’t use new models… or only once and try to kill it before it eats 120 requests like Fable did the other day in 20s of doing nothing.
I will accept the new Mac you are going to buy me… I’d like an M4-based with 32GB RAM.
@blackburied, updating the app version and changing your plan are two different things. Updating Cursor doesn’t touch your plan or model access. The rug-pull with Fable was a plan change, it wasn’t related to the app version. So you don’t need to worry that a new version will switch anything else. Also, 3.10.x has a lot of real memory and stability fixes that should help with your freezes.
For unpredictable costs, there’s a safety net. You can set spend limits and spend alerts so you don’t get surprised by something like 120 requests in 20 seconds:
About the new Mac, I can’t really help there, but honestly: on a mid-2015 Intel Mac with Monterey, heavy agent sessions will always hit hardware limits. Updating and keeping chats shorter can smooth things out, but it won’t work miracles.
@sliva-name, that’s a solid idea, and it partly works like that already. The visible part of the chat is rendered with priority. But the freezes here aren’t only about the DOM for what’s on screen. Most of the memory usage builds up because the long chat context is kept, plus large pasted images stay in memory no matter what’s currently visible. So render virtualization alone won’t fully solve it. Improving behavior on very long chats is on our radar, but I can’t share a specific timeline.
@sliva-name, that’s a solid idea. Lazy-loading context and moving large blobs like images out of RAM into temporary storage is exactly the kind of thing that could help with long chats. Some of this already works in a similar way, like prioritizing rendering the visible part of the chat, but fully lazy-loading all context and images would be a bigger rework.
Improving behavior in very long sessions is on our radar, but I can’t share a specific timeline yet. Thanks for the details, suggestions like this are really helpful.
