The state.vscdb file has grown to about 1 GB (see attached image), and the AI’s response times have become much slower—about 1 minute. I’ve deleted many old chats, but the state.vscdb file has only gotten slightly smaller. A while back, you suggested I run the command:
sqlite3 “$env:APPDATA\Cursor\User\globalStorage\state.vscdb” “PRAGMA journal_mode=DELETE; BEGIN IMMEDIATE; DELETE FROM cursorDiskKV WHERE key LIKE ‘agentKv:%’; DELETE FROM cursorDiskKV WHERE key LIKE ‘bubbleId:%’; DELETE FROM cursorDiskKV WHERE key LIKE ‘checkpointId:%’; COMMIT; VACUUM;”
which reduces the file size but deletes all chats (unfortunately, this has happened several times).
How can I reduce the size of the state.vscdb file without deleting chats, or save important chats before running the command?
Second issue: the state.vscdb.backup file hasn’t been updated in months; it seems a backup version is no longer being created. Why is that?
Hey, thanks for the detailed report. You can shrink the file without deleting chats.
When you delete chats, space is freed inside the database, but on databases created by older Cursor versions, that space isn’t returned to the OS, so the file size barely changes. This is a known behavior we’re tracking. The sqlite3 ... DELETE ... VACUUM command you were given earlier deletes the rows that store chat content agentKv, bubbleId, checkpointId, which is why the chats disappear.
The correct chat preserving way:
Open the Command Palette with Ctrl+Shift+P and run GC Agent KV Blobs. This removes orphaned data and fully compacts the database while keeping your chats.
A couple notes before you run it: you’ll temporarily need free disk space roughly equal to the current file size, and on a ~1 GB DB it can take a few minutes. Let it finish and don’t close Cursor.
In some cases, not all space is reclaimed right away, but usually the improvement is noticeable.
If you want to be safe and save important chats first, open the chat and run Export Chat from the Command Palette. You’ll get a markdown copy.
On your second question: state.vscdb.backup stopped updating on purpose. Cursor no longer writes that backup since copying a multi GB DB on every close caused issues, so the old file just got stuck. If it’s taking up space, you can delete it while Cursor is fully closed.
Slow responses after compacting the DB should improve. Those delays are usually local overhead from a bloated file, not the model itself. Let me know how it goes.
Finally, after many attempts, I realized that the AI’s response in the standard Cursor IDE is, for some reason, slow—it takes about a minute to respond (request ID: ad544228 -a7f0-48b3-9adf-c0541293b3c8), whereas in the Agent window, the response is immediate (request ID: d2cb6a36-8e71-4ac3-bbaf-bfa47513b7be).
Keep in mind that in the IDE, I’ve deleted almost all chats, restarted Cursor, and logged in and out, but nothing has changed—there’s still a delay in the response.
I prefer using the IDE, but until this delay is resolved, I’ll stick with the Agent window.
So I’m letting you know that the IDE likely has some kind of issue.
Hey, thanks for the comparison, both request IDs really helped.
I checked both requests on our side. The slow one and the fast one were each processed in about 4 seconds, same model, no errors. So the extra time you see in the IDE is happening locally in that window, not in the model or on the server.
One important note: deleting chats, restarting, and logout/login do NOT shrink the database file. As long as state.vscdb is still around 1 GB, the IDE window pays that cost on every message. You mentioned in the previous post that you cleared chats, but you still have not run the compaction GC Agent KV Blobs yet, so let’s do that.
Open Command Palette Ctrl+Shift+P and run GC Agent KV Blobs. With a file this large it can take a few minutes, so don’t close Cursor, let it finish.
Check the size of state.vscdb in %APPDATA%\Cursor\User\globalStorage and write it down.
Restart Cursor, send a message in the IDE window, and time how long the response takes.
Let me know what the file size is after step 2 and whether the delay changed. If the file got smaller but the IDE still lags, tell me and we’ll dig deeper. In that case it’s likely something else in that window, like extensions or the workspace.
After running the “GC Agent KV Blobs” command, the response is now immediate, but I had already run the same command before writing the original post, and it hadn’t solved the problem. The “state.vscdb” file was 820 MB before running the “GC Agent KV Blobs” command and 819 MB after the command, so it remained almost unchanged. I don’t know what fixed the problem, but the response time is currently normal.
About the file barely changing in size 820 to 819 MB, that’s expected for databases created by older versions of Cursor. Space gets freed inside the DB, but it doesn’t always get returned to the OS, so the on-disk size often stays almost the same. This is a known issue we’re tracking. So the problem wasn’t the file size on disk, it was the accumulated data inside the DB that GC Agent KV Blobs cleaned up, which is why performance went back to normal.
For the future, if the IDE starts lagging again:
Run GC Agent KV Blobs again.
Before any cleanup, you can save important chats via Export Chat in the Command Palette and you’ll get a markdown copy.
state.vscdb.backup is intentionally no longer updated, so if it’s taking up space, you can delete it after fully closing Cursor.
If the delay comes back and running GC again doesn’t help, reply here and we’ll dig deeper. It might be something in extensions or in that window’s workspace.
After deleting all past chats (using the “Delete old chats…” command) and running the “GC Agent KV Blobs” command, the AI’s response speed returned to normal. Unfortunately, I have to perform these steps frequently because the AI’s response time increases rapidly.
Hey, thanks for the screenshots. They make it clear where the gigabytes are going: state.vscdb is 14,3 GB and state.vscdb.backup is 10,62 GB.
Start with the easy win. state.vscdb.backup is no longer updated on purpose. Cursor stopped copying a multi-GB DB on every close, so the old file just got left behind. You can delete it after Cursor is fully closed, and that will free up about 10 GB right away and won’t affect your chats.
Next is state.vscdb. You don’t need to delete chats. There’s a correct way to clean it up and compact it:
Open the Command Palette with Cmd+Shift+P and run GC Agent KV Blobs. This removes orphaned data and compacts the DB, and it keeps your chats.
With a DB this big, it can take a few minutes and it will temporarily need free disk space roughly equal to the current DB size. Let it finish and don’t close Cursor.
If you want a safety copy of important chats first, open the chat and run Export Chat from the Command Palette to get a markdown copy.
The files are in ~/Library/Application Support/Cursor/User/globalStorage.
One more note from earlier in the thread: for DBs created by older Cursor versions, space can be freed inside the file but not always returned to the OS. So the file size on disk might not drop much even though the extra data is cleaned and performance gets back to normal. We’re tracking this issue. Let me know how it goes after the cleanup.
