For days now, the long waits for responses from the AI have resumed, significantly prolonging development times with nerve-wracking delays. It’s not specific to any one AI model—they’re all slow.
I deleted the old chats and reduced the size of the \AppData\Roaming\Cursor\User\globalStorage\state.vscdb file, which is now 600 MB. I’ve restarted Cursor several times, but nothing speeds up the response. The Cursor and AI statuses don’t indicate any slowdowns. What else can I do to speed up the responses?
Hey, thanks for the detailed report. Quick note: Taking longer than expected isn’t an error. It’s a client-side indicator that shows up when response streaming hasn’t started within a set threshold. We don’t see any requests on our side for the Request ID you shared, so this is usually network or local environment related, not model specific.
What to try, in order:
Network Diagnostics: Cursor Settings > Network > Run Diagnostics. This should show where it’s getting stuck.
Switch HTTP protocol: Settings > Network > change to HTTP/1.1. This often fixes slow or hanging responses, especially on corporate networks, VPNs, or proxies like Zscaler. If you’re using a VPN or proxy, also test without it.
state.vscdb: 600 MB is fairly large, and a big local state can slow things down. One catch is that Delete Old Chats doesn’t always fully free space. This is a known limitation on our side, and we don’t have an ETA yet.
If things are still slow after that, let me know what the diagnostics showed at each step, and share a fresh Request ID with Privacy Mode off, and we’ll dig deeper.
I measured the AI’s response time, and it’s about 1 minute. It’s not that long, but waiting a whole minute every time isn’t very productive.
The network is working fine; see the attached image.
I’ve been using the http/1.1 setting for a long time, so it’s already enabled (I don’t use a VPN).
state.vscdb: I resized the file again using the command you gave me:
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;”
but the file is still large: 460 MB.
I deleted the archived chats using the command:
Developer: Delete Old Chats
Thanks, the screenshot helped. In Network Diagnostics all checks are green, so requests are reaching our services fine and the network isn’t the bottleneck here. HTTP/1.1 is already enabled and there’s no VPN, so your local setup looks correct.
From our logs, requests with those Request IDs don’t show up as slow on the server side. On the free tier during peak load, requests get a lower queue priority, and the time to first token (TTFT) can stretch out. The ~1 minute you measured is most likely due to that scheduling, not a specific model or a bug. Unfortunately, this is expected behavior on the free plan during busy hours, and there isn’t much you can tweak locally to change it.
About state.vscdb, having 460 MB left after VACUUM is due to a known limitation on our side. Delete Old Chats doesn’t always fully free space because of leftover records. We don’t have an ETA for a fix yet. 460 MB by itself isn’t critical and it’s very unlikely to cause a 1 minute delay, it barely affects TTFT.
If you want to compare, you can create a clean empty project and send a simple request as a test. If it still takes ~1 minute around the same hours, that confirms it’s scheduling and not your local state. Let me know what you find.
Apologies for the confusion about the free plan. I said that because on our side, the account signed into your Cursor shows as Free, and we’re not seeing your requests come in with Pro+ priority. That matches the slow responses you’re seeing.
The most common reason is that the account you’re signed into in the IDE isn’t the same one your Pro+ subscription is linked to. It’s worth checking:
In Cursor, open Cursor Settings and confirm which email is signed in.
Compare that to the email where you manage the Pro+ subscription. Check the dashboard at cursor.com/settings, it’ll show the plan for the signed-in account.
If they don’t match, sign out of Cursor and sign back in with the Pro+ account.
If the signed-in email already matches your Pro+ account and it still shows as Free after a fresh sign-out and sign-in, tell me here and we’ll dig into it from there.
Yes, the email address for Cursor is the same as the one for the Pro+ plan. I tried logging out and logging back in, but the wait time has actually increased to over a minute—so yes, there is a problem. I’d like to send an email to support, but I can’t find the email address: can you give it to me?
I am facing the same issue on the Pro plan too. But mostly it doesnt work at all with message “The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.”
I managed to speak with support, who performed a sort of reset on my account in your system, but unfortunately the roughly 1-minute wait time remains. I’ve tried both Sonnet 4.6 and Composer 2.5, and the roughly 1-minute delay is present in both. I’m in touch with support, and I hope this gets resolved quickly.
@brales the support email is [email protected], and it sounds like you’ve already reached them, good.
Since the account signed into your IDE shows as Free on our side even though you’re subscribed to Pro+, this is an account-level mismatch that the team at [email protected] needs to fix directly. That’s what’s putting your requests on lower-priority scheduling and causing the about 1 minute TTFT. Once your subscription shows Pro+ priority correctly, wait times should get back to normal. Please keep working with them in that email thread, all the local troubleshooting diagnostics, HTTP/1.1, state.vscdb has already been ruled out here.
@markito your error is different, ERROR_EXTENSION_HOST_TIMEOUT and agent execution provider did not respond in time. To keep things from getting mixed up, can you post in one of the dedicated threads for that, for example Agent execution timed out - ERROR_EXTENSION_HOST_TIMEOUT, so it gets tracked separately.
After countless attempts, I finally realized that the AI’s response delay of about 1 minute was due to the fact that my workspace contained two root folders (one for the free version of the software I’m developing and one for the paid version); for convenience, I had kept them both in a single project. Now I work on one folder at a time, and the AI responds immediately.
I’m writing this post in case someone else might run into the same problem.
Glad you tracked down the cause, and thanks for coming back to share the fix. It’ll really help other users with a similar setup.
Having multiple root folders in one workspace can noticeably increase the amount of context and indexing pulled into each request, so time to first token goes up. Splitting into separate projects, or working with one folder at a time like you did, is the right approach.
If you ever need to keep both projects side by side, you can also tweak .cursorignore to exclude the part you don’t need right now. But if everything’s fast with a single folder, I’d keep it as is. Let me know if the delays come back.
