I have macbook Apple M5 Max 128GB ram, using ±80GB of ram of various things including cursor ±50GB still available. running ±10 working trees is very smooth, all good, but if i leave over night to run ±16 working trees i often find cursor crashed. I use mainly grok 4.6 on medium. It’s part of my setup, for most parts i use other subscriptions atm because of this crash issue. I’m on $200 plan, it lasts me for ±10 days.
I have ram & cpu and disk etc, any way to run ±30 trees at once in stable way? i could run it with CLI, agent, editor mode - i don’t care, just need place to paste in the prompt and leave it in stable way to work on stuff for like 10h on same chat with all the worktrees. would love to have like 30 worktrees or more.
What you’re hitting is a per window memory limit, not a machine RAM limit. Each Cursor window runs a single renderer process with its own memory budget, and every worktree agent session in that window shares it. With ~16 sessions accumulating chat and diff state over a long unattended run, that budget eventually runs out, and the window goes down, no matter how much free RAM the Mac has.
A few ways to get to 30+ worktrees more stably:
Use the Cursor CLI (agent) for the long unattended runs. Each CLI session is its own process with no UI overhead, so you can run dozens in parallel (for example, one per worktree in tmux), and it scales with your hardware instead of a single window’s budget.
Or run them as Cloud Agents, which execute on Cursor’s infrastructure and cost your Mac nothing while running for hours.
If you prefer staying in the editor, split the worktrees across several Cursor windows instead of one window, since each window gets its own memory budget. Keeping under roughly 8 to 10 sessions per window tends to stay comfortable.
Also make sure you’re on the latest version. Recent releases include several memory handling improvements for heavy parallel agent workloads.
If it still crashes after that, reply with your Cursor version (Cursor → About) and the exact text of the crash dialog, and we can take a closer look.