The difference is that with the memories, both the contents and the index is stored in our infrastructure.
With your code:
Indexing your code allows some of Cursor’s tool and under-the-hood behaviours to have a better implicit understanding of where the most relevant sections of your code lives. While there is no manual way to interface with this, it’s this index which helps Cursor decide what makes it into a prompt, and what gets cut (note that MAX mode isn’t quite the same).
We can do this with privacy mode, because we don’t actually store your raw code, just the indexes to help us navigate through what is sent within each request
With memories:
Both the memories themselves and the indexing of those memories happens on our infrastructure, not in your device. This is because with a large quantity of memories, we need the indexing to find the most relevant memories, but when we go to use that index, it has to be applied against every memory you have.
With code, the indexing only applies to the code itself, so if you @ 3 files, that’s all we have to sift through. With memories, 100s of them could exist and need sorting through with the help of the index.
Therefore, it makes the most sense for this process to, at least for the short term, run off-device, to avoid any client-side degradation and allow for much higher limits of memories.
The Future
Memories are not even released to everyone yet, so are as new as a feature can be! As such, it’s more than likely that we will see iterations on how this works, both in effect in your workflows, but also in its implementation. While I don’t want to guarentee anything, I’d be surprised given a high volume of requests that we don’t add a privacy mode-compliant implementation for this in the future.
I understand the limitation is not optional, but has been done to ensure the features stability and usefulness for those who can use it, vs making it accessible to more people, but not useful enough to be worthwhile!