I have been absolutely obsessed with cursor since I first tried it a month ago. I primarily use Cursor for work in large, complex monorepos. One issue I face is how often I’m prompted to “start a new chat for better results” — sometimes even in the middle of making a relatively simple change.
Losing context mid-task can cause the assistant to generate irrelevant or even harmful changes. Onboarding a new agent to understand the current context is time consuming and error-prone.
What I’ve Tried
Revised Cursor Memory Bank – This has improved quality significantly, but I still end up restarting chats frequently.
Letta – I couldn’t get it to integrate cleanly with Cursor, and the time investment required to do so wasn’t justifiable.
Graphiti (local MCP with Docker + Neo4j) – After a few hours of debugging, I shelved it. I might revisit it, but only if there’s evidence it’s worth the setup.
Areas I’m Exploring
I’ve been considering whether an embedding-based retrieval layer (FAISS, LlamaIndex, etc.) could act as a context engine to augment Cursor’s capabilities. Another angle is whether anyone has built a custom MCP that works locally and integrates tightly with Cursor’s chat UX. Even something lightweight that scopes context by branch, file history, or commit diffs would be a meaningful improvement.
Open Questions for the Community
Has anyone found a reliable way to persist chat context across sessions in Cursor without constant restarts?
What local tools, MCPs, or custom workflows have you successfully integrated?
How are you scoping context effectively for large monorepos while avoiding redundant onboarding?
Has anyone built or adopted an embedding-based memory layer to complement Cursor?
Would appreciate hearing about any tools or workflows that are working well for you — or pain points you’re still facing. Success stories, failed experiments, architectural tips — all welcome.
Just because Cursor suggests this to you doesn’t mean you have to obey it . I think it just does it at some arbitrary context length, but with larger-context models you don’t need to do it as often as you’d think, esp since Cursor charges per-request and not per-token!
So far I have not found any magic that works better than creating proper documentation, and referencing it where appropriate. I’m using my own tuned version of memory-bank that lets it add supplementary documentation when I tell it to or when it thinks it has discovered something not covered by existing docs.
If you’re working in monorepos, I recommend creating documentation scoped to each main architectural area, documentation around APIs/interfaces, and referencing them as appropriate. You can use a root-level rule to tell the agent which set of documentation to look at for a given task, or define for the LLM some aliases for sets of context (eg. “.fe → read the frontend context-bank in /frontend/memory-bank”).
Another thing would be to look at repomix, which is a tool that lets you compile your entire codebase, or some subset of it, into a single file you can inject as context.
There is now way around starting new chats regularly (a bit longer with MAX probably). You can refer to old ones by @ Past chats, which tries to transfer a good summarization.
I have stopped trying to rely on Cursor rules, and always add my markdown documentation files describing the project and what coding rules to follow manually to each chat session. This seems to work reasonably well.
However, I find it quite tricky with Cursor to get a good understanding of what’s actually in the context at any given time. Even if I add multiple file references as context alongside my textual instruction, those context “badges” often seem to disappear after the model has finished outputting its response. Does this mean they dropped from the context? Or does it just mean that the UI stopped showing them?
At other times, I’ve asked the agent directly what’s in its context. And at least once it reported to have none of that stuff I added earlier in its context.
. I think it just does it at some arbitrary context length, but with larger-context models you don’t need to do it as often as you’d think, esp since Cursor charges per-request and not per-token!