For users who spend their entire workday in the Cursor application, even infrequent crashes can be a major disruption. As the platform adds features like subagents and instant grep, maintaining stability becomes increasingly complex. The primary culprit for these crashes has been out-of-memory (OOM) errors. Over recent months, Cursor has rolled out new systems for crash observability, memory pressure monitoring, and high-confidence fixes, leading to an 80% drop in OOM-per-session rates since its late-February peak. This post details the engineering efforts behind these improvements, as reported by Cursor Blog.
Detecting and Measuring Instability
Built on Visual Studio Code and Electron, Cursor's multi-process architecture means crashes can originate in renderer processes (editor, agents) or utility processes (extensions, storage). Renderer crashes are most severe, often tied to V8 memory limits. Extension crashes can disrupt functionality but typically recover.
