Feature request for product/service
Cursor IDE
Describe the request
Summary
We would like to propose adding a GPUI-based (Rust + GPU-accelerated) rendering backend as an optional alternative to the current Electron-based architecture — not a replacement.
Motivation
Electron has clear advantages: VS Code compatibility, a massive extension ecosystem, and rapid cross-platform shipping. We are not suggesting abandoning it.
However, a growing segment of developers — particularly those migrating toward Zed — are choosing raw performance over ecosystem breadth. Cursor risks losing these users permanently.
Current Electron limitations:
• ~650MB idle RAM vs Zed’s ~180MB
• ~12ms input latency vs Zed’s ~2ms
• Startup time: 3s+ vs Zed’s 0.4s
Proposal
Offer two builds side by side:
Electron build (current):
• Extension ecosystem: Full
• Input latency: ~12ms
• Idle RAM: ~650MB
• Composer 2: Supported
GPUI build (proposed):
• Extension ecosystem: Curated
• Input latency: ~2ms
• Idle RAM: ~180MB
• Composer 2: Supported (shared SDK)
The key insight: Cursor SDK already abstracts the agent core. The frontend renderer is theoretically swappable without rewriting the intelligence layer.
Why now?
The AI-assisted migration cost between Electron and GPUI is lower than ever. Code translation between TypeScript/Electron and Rust/GPUI is increasingly viable with LLM assistance. The engineering investment that would have taken years is now measurably shorter.
On extension philosophy
Rather than replicating VS Code’s 50,000-extension marketplace, the GPUI build could adopt a “curate and integrate” model — pulling the most-used extensions directly into the core product. This is already Cursor’s implicit direction.
We are interested in contributing
I am a product-minded engineer interested in contributing to this effort — particularly on the product design and architecture side. If this direction resonates with the Cursor team, I would welcome a conversation.