Cursor Editor Deep Dive: UI Lag, Memory Bloat, and Interaction Bugs Unpacked

A Power User's Unfiltered Rant

Recently, a developer posted a scathing critique of the AI coding tool Cursor on Reddit, pulling no punches: "The UI is buggy, laggy dogshit." The post struck a nerve and quickly gained traction, because it hits on a core frustration shared by many AI coding tool users — the massive gap between powerful model capabilities and a poor product experience.

The developer admitted the only reason he's still using Cursor is the impressive performance of its Composer 2.5 model. Beyond that, he's seriously considering "writing his own agent orchestrator," switching to Kimi K2.5, or going fully model agnostic. This love-hate relationship is a textbook example of the contradictions playing out across the AI coding tools market right now.

Cursor's Specific Issues: The Devil in the Details

The user laid out a long list of concrete problems. These details are worth examining one by one, since they're often the clearest signal of how mature a productivity tool actually is.

Memory Management and Performance

The harshest complaints center on resource consumption. The user says he has to constantly delete or archive agents, otherwise Cursor devours memory and causes his MacBook to crawl — even when those agents are idle and not running any tasks.

For a tool that sells itself on boosting productivity, this is a critical flaw. Developers turn to AI-assisted coding precisely to reduce cognitive overhead and friction. If the tool itself becomes a black hole for system resources, forcing users to manually manage and clean up after it, that directly undermines the whole point.

Chaotic Project and Session Management

The user also flagged several state management issues:

When starting a new conversation for an agent, the project directory often fails to carry over correctly into the agent list
When opening a new conversation, Cursor "keeps switching to a completely different agent" and starts talking to the wrong one
When launching the IDE, it frequently opens the wrong project — or no project at all

What these issues share is unreliable state persistence. In a complex workflow with multiple projects and agents running in parallel, dependable context management is table stakes. Frequent context loss and mix-ups don't just break your flow — they can lead to real mistakes, like running a command in the wrong project context.

No Window Position Memory

Another issue that seems minor but adds up fast: Cursor doesn't remember window positions. Every time a new project window opens, the user has to manually re-arrange the layout. He's resorted to using the third-party tool Rectangle to cope, but admits it's "still bad."

Window position memory is a basic capability in desktop applications — one that mature IDEs have handled for years. Its absence here points to gaps in Cursor's desktop engineering polish.

Cursor's Pushy Guidance Wears Users Out

Beyond performance and stability, the user also leveled sharp criticism at Cursor's product strategy. He complained that the app keeps nudging him toward models and approaches he doesn't want, including:

Repeatedly recommending the planner feature
Pushing Grok-based multi-agents (which he also calls "garbage")

All he wants is to "keep using Composer 2.5 for everything."

This touches on a deeper product philosophy tension: the vendor's drive to push new features versus the user's need to maintain a stable workflow. When a tool constantly surfaces prompts and recommendations to change habits that are already working, the intent might be to drive feature adoption — but for power users with an established workflow, that kind of "over-guidance" just becomes noise.

The "Always Allow" Button That Does Nothing

The last issue the user raised is particularly telling: after clicking the "always allow" button, nothing actually sticks — even for the same command (like git push), Cursor will still ask for confirmation about half the time.

What makes this damaging is that it breaks the basic social contract of the interaction. When a user explicitly grants an operation "always allow" status, they expect the tool to honor that. When it doesn't, it wastes time and, more importantly, erodes trust in the entire permissions system. In a context where commands are being executed, that kind of unpredictability is genuinely unsettling.

What Cursor's Problems Reveal About AI Coding Tools

This is one user's subjective experience, but the problems it surfaces are widely applicable. The AI coding tools industry is in an unusual moment right now:

Model capabilities are racing ahead while product engineering is badly lagging behind. Vendors are chasing the latest and most powerful models (Composer 2.5, Kimi K2.5, Grok, and so on), pouring resources into model iteration and feature expansion — while running up a tab of technical debt in the fundamentals: memory management, state persistence, interaction consistency.

This also explains why the user is seriously considering building his own solution. When a tool's core value is reduced to the model itself, and models are increasingly commoditized and interchangeable (model agnostic), the tool's moat gets thin fast. Users can absolutely choose to keep the model they like and ditch the bloated, laggy wrapper around it.

What This Means for AI Coding Tool Vendors

For products like Cursor, this rant is a signal worth taking seriously:

Stability and performance are the floor for retaining power users, not a nice-to-have
Respect existing user workflows — aggressive feature upselling does more harm than good
Interaction promises must be kept — the reliability of the permissions system is foundational to trust

As model capabilities converge, the real competitive moat may turn out to be exactly these "unsexy" product engineering details. The tools that obsess over nailing the fundamentals are the ones that will actually hold onto the technical, demanding developers who matter most.