The AI responds extremely slowly: I have to wait a long time for a response (the message “Taking longer than expected…” always appears), and when the response finally comes, only part of it arrives, followed by another long wait for the rest. Sometimes I have to ask, “Are you stuck?”, and it starts responding again, but always very slowly. Is there any way to speed this up?
I’ve tried using the HTTP/1.1 protocol, reindexing the codebase, and restarting Cursor, but nothing has changed. The file AppData\Roaming\Cursor\User\globalStorage\state.vscdb is 1.8 GB—maybe that’s the issue? But if I delete it, I’ll have to reset a lot of settings, and I’d like to avoid that. Sonnet 4.6 is extremely slow, and it runs a little better with Composer 2, but that’s still slow too.
Hey, I see the screenshot. Your request finished successfully on the backend, but it took about 19 minutes. That’s way too long, and it’s most likely due to two things.
The state.vscdb file is 1.8 GB. That’s the main suspect. This file stores chat and agent session data without limits, and it grows over time. On Windows, it can slow down the whole client.
Workaround: clean it up with SQL. Fully close Cursor first, then in PowerShell.
Then clean it up. You’ll need sqlite3, you can install it with winget install SQLite.SQLite:
sqlite3 "%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;"
This can shrink the file from 1.8 GB down to a few dozen MB. Downside: your chat history in the UI will disappear. Agent transcripts will still be in ~/.cursor/projects/.
Long chats. In the request logs there are two warnings that say “Large conversation state”. The longer the chat, the slower each next reply gets. Try starting a new chat once the current one gets big.
The team knows about the state.vscdb growth issue. There’s no automatic cleanup yet.
Try the cleanup and let me know if it feels faster.
I followed your advice and reduced the size of the state.vscdb file to 300MB. First of all, I noticed that the PowerShell command is slightly different from the one you gave me (I’ll write it down here in case others reading this post need it):
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;”
Once Cursor was restarted and Sonnet 4.6 was used, the “Taking longer than expected…” warning no longer appeared, and the AI began responding immediately; however, unfortunately, it took several minutes—far too many—to get the final output for my request: it is impossible to work with such long wait times.
The Request ID of the request after working on the state.vscdb file is: c3f6dcb1-4f49-423c-a81b-6d08d1db7e26
Glad the warning is gone, that’s progress. And thanks for the PowerShell command fix, it’ll help other users too.
About the remaining slowness, a couple questions so we can narrow it down:
Was the request with the new Request ID in a fresh chat, or a continuation of the old one? In the previous request there were warnings about a large conversation state, which can slow down every next response a lot.
Try starting a new chat and ask something simple, like “explain this function”, on a small file. If the reply is fast, then the issue is the context size, and the fix is to start new chats more often.
Roughly how big is the project, number of files or lines? Big projects with indexing enabled can add delay.
I’ll pass the new Request ID to the team so they can check the backend. Let me know how it goes with a clean chat.
1. I submitted the request ID in a new chat. I had started a new project by creating a new folder in Cursor, and there were only 3 previous requests in the chat. In the previous project—which isn’t related to the current delay—there were actually a lot of requests, but even in that project I often open new chats and archive the old ones (though I don’t delete them; maybe archiving and deleting have different effects on performance?).
2. I tried asking a very simple question and noticed that with the HTTP/2 protocol it’s still very slow; I switched to HTTP/1.1 and it sped up significantly (Sonnet 4.6 in both cases).
3. The project is new; there are only 3 files, each about 300 lines long.
Request ID for the query with a very slow response: bb41a1d6-b596-4de7-a600-6aeba7510a25
Request ID for the query with a fairly fast response: 6901e30d-209c-46d7-b474-5cd2d9171a59
I should note that my issue is also related to 3.0.16 given the tile prompt eventually replies, with “thought briefly” - very incorrect. but this was on a simple “hello” using it with my actual code base is impossible. it proceeds after the long initial first time to token to handle thing at a decent pace - but this is also on a fresh install. Was unable to do anything at all with my prior install, with my configs (RIP my configs) Request ID: 0bf0eb84-af39-43ed-a342-ca8d8c257c07
Update: For unknown reasons, it has started to stabilize and work, opened a new window and it started to respond immediatley. @PascalX Have you noticed this too? or could this be related to fresh install?
–Update x2: spoke too soon, issue came back after a few prompts and is unusable again. Basic asks (verifying my docker syntax) is now taking longer than expected.
Reverting the version to pre 3.0.x version seemed to fix it. Bug persisted in tested newly installed versions 3.0.16, .13, and .04. Reverting to Update below did not fix the issue. check replies for additional info.
Looking for a download link to older version (macOS) as we speak. I just don’t remember which version I had before (I am certain it was a 3.0 version of some kind. Def not 3.0.16). Saw the link below.
Im almost wondering if its a problem with the service, as the version i was running before was 2.6.20 right around composer time.
not sure if somethings happening external to the downloads, but ill keep chasing versions and ghosts until i can maybe find stability otherwise, guess its the world telling me that proxmox doesnt need fixed today.
Yes but my issue started with recent update to 3.0.16. I had updated to 3.0 when it came out and had no issues until this 3.0.16 update.
Update #1: I just tried 3.0.12 > no luck. same issue.
Update #2: Reverted back to 3.0.16 … I am not willing to go version hunting. Also just realized even my cloud agents run through the Cursor app are facing the same exact problem.
I took a step back on the form and started to look around recent tickets. Theres ALOT related to Composer/ Auto mode in related to planning recently regardless of the version. They also mentioned that the latest release resolved some of the “hanging”
For testing im going to head back to 3.0.16 (latest) and try just manually going to Opus 4.6 as agent, and bypassing all auto/composer issues that have appeared as of late.
Update: Initial results feel promising, however, not using auto/composer can rack up cost quick.
Glad its working Hopefully they see the chat and get working on the composer/auto issue. They worked great and their efficiency was always pretty good, hate to see em bring down stability like this. Ill keep testing around and report back if i run into the planning issue again. otherwise, hopefully this gets some people an assist thanks for the debug help as well @PascalX !
Thanks for the thorough debugging here, @Garrett_Giles and @PascalX. You’re right that Composer 2 and Auto mode were experiencing issues, particularly on April 11. Manually selecting a specific model is the correct workaround for now.
The team is tracking this and working on improving Composer 2 and Auto mode reliability. If anyone here is still experiencing hangs after switching to a manually selected model, please share a Request ID, and we can check the backend.
prompt eventually replies, with “thought briefly” - very incorrect. but this was on a simple “hello” using it with my actual code base is impossible. it proceeds after the long initial first time to token to handle thing at a decent pace - but this is also on a fresh install. Was unable to do anything at all with my prior install, with my configs (RIP my configs) Request ID: 0bf0eb84-af39-43ed-a342-ca8d8c257c07
Hopefully they see the chat and get working on the composer/auto issue. They worked great and their efficiency was always pretty good, hate to see em bring down stability like this. Ill keep testing around and report back if i run into the planning issue again. otherwise, hopefully this gets some people an assist