Hi @user691 thanks for the post, and for the detailed breakdown. Let me go through each part one by one.
1. Is ~97 GB / ~1.4 GB/day expected? It’s on the extreme end, but it lines up with a known limitation rather than “just how databases work.” Right now Cursor doesn’t automatically clean up or compact the chat and agent history it saves locally, so if you keep your conversations, that history keeps growing, especially with heavy use across many repos and lots of sub-agents. So this is real saved history, as you correctly found, not wasted empty space, and it’s something we’re aware of.
2. Are My Machine / local workers an amplifier? Not really. The local workers don’t write into that database at all, and there’s no worker-specific storage behavior, so turning them on isn’t a separate cause of the growth. The timing lines up simply because you were running more agent sessions during that stretch, and any heavy agent use (workers or not) produces more saved history. So the real driver is the desktop app storing all that chat history plus your overall agent volume, not the workers themselves. Two quick side notes: very heavy sub-agent use (agents that spawn copies of themselves) can multiply the number of saved records, and those large worker log files are a separate disk issue.
3. A supported way to prune without breaking chat loading? Yes, and please don’t delete or rename the database file itself (that’s what causes the endless “Loading Chat”). Instead, open the Command Palette and use these built-in commands:
Developer: Delete Old Chats...asks how many days of history to keep (default 30), removes chats you haven’t touched since then, then clears the now-unused history and compacts the file to hand the space back, and offers a Reload Window at the end.Developer: GC Agent KV Blobsdoes that same cleanup and compaction without deleting any chats. It only clears leftover data that’s no longer attached to any conversation, so it’s safe, but it won’t shrink a database that’s mostly made up of chats you’re keeping.
4. Plans for automatic cleanup, caps, or log rotation? Yes, this is on our radar. There’s already an automatic background cleanup for leftover/unused data, but by design it doesn’t touch history you’re keeping, and on older databases it can’t return the freed space on its own (which is why the manual compaction command exists). Proper automatic cleanup of kept history, the reclaim-reliability fix above, and the noisy worker logs are all understood on our side and being worked on. I can’t promise specific dates, but none of this is new to us.
5. Additional details. No need to upload the 97 GB file. If the cleanup above doesn’t free much, the most helpful thing to share is the summary line the cleanup command shows when it finishes (it reports how many entries were total, still in use, and deleted). It will look something like this:
Deleted 24 chat(s) older than 60 days in 0.4s. GC complete in 8.3s (GC: 7.5s, VACUUM: 0.8s): 10,226 total, 8,016 live, 2,214 deleted
Bottom line: run Developer: Delete Old Chats... with the days setting of your choice, and let us know how this goes!