Cursor 1.5 shipped this week with two notable additions: refined multi-window support and per-project AI memory that persists across sessions. Both target workflows that experienced users have been working around.
Multi-window improvements
Cursor has technically supported multiple windows for a while, but the experience was rough. Each window had its own AI session; switching between windows felt like switching applications.
1.5 adds:
- Shared AI session across windows of the same project
- Coordinated chat panel state (open in one window, see in others)
- Better window-specific keybindings
- Less memory usage with multiple windows open
For users who work with multiple windows on the same project (common for split work between front-end and back-end, or for reference vs. active editing), this is meaningful.
Per-project AI memory
The bigger feature: Cursor now remembers context across sessions per project.
What this means concretely:
- “Continue where we left off” works across sessions
- Project-specific patterns the model learned persist
- Conventions you’ve corrected stay corrected
The previous default: each new session was fresh. The model relearned your conventions every time.
The new default: relevant context from previous sessions is available. The model knows what it knew yesterday.
A specific example
A workflow that benefits:
I work on a project where we have specific patterns (a custom Result type, specific error handling, certain naming conventions). In Cursor before 1.5:
- Day 1: I correct the model when it doesn’t follow our patterns
- Day 2: I correct again (the model forgot overnight)
- Day 3: same
In 1.5:
- Day 1: I correct the model
- Day 2: the model remembers; produces correct code
- Day 3: same
Less repeated correction. Less “why does it keep doing that” frustration.
How memory works
Cursor’s memory system:
- Stores context per project (not per repo; respects worktrees and similar)
- Persists across sessions, including after computer restart
- Has a configurable size cap (default ~50k tokens)
- Can be cleared via Settings → Project → Clear Memory
The implementation is opaque from the user’s side; you don’t curate the memory directly. Cursor decides what’s important. So far, the decisions seem reasonable based on my testing.
Privacy considerations
The memory contains content from your sessions: your code, your prompts, your explanations. This data persists in Cursor’s systems.
For users with privacy concerns:
- Memory can be disabled per project
- Memory can be cleared at any time
- Enterprise tier has data residency commitments
For most users, the memory is fine. For users in regulated industries or working on sensitive code, the privacy implications need consideration.
Comparison
Other tools have similar features:
- Cline: Has session memory; persists in
.clinerulesif you save patterns there - Claude Code: Has team profiles plus session history
- Aider: Doesn’t have explicit memory but the repo map serves a similar function
- Copilot: Has conversation history but less explicit memory
Cursor’s implementation is well-integrated. The memory feels seamless rather than something you have to invoke.
What might break
Some considerations for users adopting 1.5:
Memory may carry stale assumptions. If your project’s conventions changed, the memory may still apply old conventions. Manually correct or clear memory.
Memory consumes context tokens. The 50k token default is reasonable for most projects but adds to per-session cost. Watch for cost changes if you’re on BYOK.
Multi-window state can be confusing. Two windows open with different chat panel states is the new normal. Some workflows need adjustment.
Memory + custom rules interact. If your .cursorrules has rules but the memory has different patterns, the model resolves conflicts in non-obvious ways. Test that your rules still apply.
Worth updating?
For active Cursor users, yes. The improvements address real friction.
For users on team plans, the memory feature is per-user (not shared across team members yet). Coordination across the team for “what should the AI remember” remains manual.
For users on Pro tier, this is included. Business and Enterprise tiers also include it with their respective benefits.
What’s coming
Cursor’s roadmap mentions:
- Team-shared memory (an obvious next step)
- Selective memory editing (curate what’s remembered)
- Memory analytics (what’s the model using most)
These would extend the value. The current implementation is a foundation.
A pattern this enables
The memory feature enables a workflow that wasn’t practical before: “long-running projects where the AI knows the project deeply.”
Pre-1.5, the AI knew the project as deeply as the immediate session’s context. Now, knowledge persists. Engineers who spend months on one project can have an AI partner that’s been with them throughout.
This is the kind of feature that takes time to internalize. Engineers who’ve adapted to “fresh AI every session” need to update their mental model. Once internalized, the workflow gets smoother.
For Cursor’s broader strategy, persistent memory is a real differentiator. Other tools will likely follow; Cursor is in front for now.
Update path
Standard auto-update if you have it enabled. Otherwise, manual update via the app’s update prompt. The 1.5 features are immediately available; existing project setups get memory enabled by default.
For users uncomfortable with default-on memory: disable per project before using 1.5 with sensitive code. The feature is opt-out, not opt-in.
The pace observation
Cursor’s release pace remains aggressive. 1.0 in early 2025; 1.5 less than a year later with significant new features. The team is shipping at a rate few competitors match.
Whether this pace is sustainable matters. Users benefit from the rapid feature additions. Engineering teams get tired from the rapid pace. The next year will tell.
For now, 1.5 is one of the more meaningful Cursor updates in some time. Worth paying attention to.
