Network issues: "stuck on planning next moves," "taking longer than expected" (and "reconnect" sometimes)

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Unable to use Agent because it is not responding. I either get “stuck on planning next moves,” or “taking longer than expected” (and “reconnect” sometimes). I tried using non-Auto models; changed to HTTP-1.1 and closed and reopened window; turned on and off VPN, reloaded the OS. Nothing helps. The problem is frustrating. It also appeared in the past and seemed to be gone within a day; but it appears again from time to time.

Steps to Reproduce

diagnostics:
Cursor Network Diagnostic Results

FAILED (5): HTTP/2, API, Ping, Chat, Agent

DNS: Success
Logs:
[2026-07-05T13:07:56.325Z] Host: api2.cursor.sh
[2026-07-05T13:07:56.326Z] Servers: 127.0.0.1
[2026-07-05T13:07:56.326Z] Resolved to 3.220.39.216 in 2ms
[2026-07-05T13:07:56.422Z] Resolved to 3.220.39.216 in 94ms
[2026-07-05T13:07:56.423Z] Resolved to 3.220.39.216 in 0ms
[2026-07-05T13:07:56.424Z] Resolved to 3.220.39.216 in 0ms
[2026-07-05T13:07:56.426Z] Host: api2.cursor.sh
[2026-07-05T13:07:56.426Z] Servers: system
[2026-07-05T13:07:56.426Z] Resolved to 3.220.39.216, 67.202.40.192, 100.57.232.83, 54.145.252.92, 100.24.220.84, 100.49.175.34, 35.170.235.205, 100.51.175.121 in 0ms
[2026-07-05T13:07:56.427Z] Resolved to 3.220.39.216, 67.202.40.192, 100.57.232.83, 54.145.252.92, 100.24.220.84, 100.49.175.34, 35.170.235.205, 100.51.175.121 in 1ms
[2026-07-05T13:07:56.428Z] Resolved to 3.220.39.216, 67.202.40.192, 100.57.232.83, 54.145.252.92, 100.24.220.84, 100.49.175.34, 35.170.235.205, 100.51.175.121 in 0ms
[2026-07-05T13:07:56.429Z] Resolved to 3.220.39.216, 67.202.40.192, 100.57.232.83, 54.145.252.92, 100.24.220.84, 100.49.175.34, 35.170.235.205, 100.51.175.121 in 0ms
[2026-07-05T13:07:56.429Z] Result: true

HTTP/2: Error: Unexpected protocol: undefined
Logs:
[2026-07-05T13:07:56.307Z] Start
[2026-07-05T13:08:19.192Z] Host: api2.cursor.sh
[2026-07-05T13:08:19.192Z] Protocol: undefined
[2026-07-05T13:08:19.192Z] Result: Error: Unexpected protocol: undefined in 22885ms

SSL: Running
Logs:
[2026-07-05T13:07:56.307Z] Start
[2026-07-05T13:08:19.191Z] URL: undefined
[2026-07-05T13:08:19.191Z] Status: undefined
[2026-07-05T13:08:19.191Z] IP: undefined
[2026-07-05T13:08:19.191Z] Issuer: undefined
[2026-07-05T13:08:19.191Z] Name: undefined
[2026-07-05T13:08:19.191Z] AltName: undefined
[2026-07-05T13:08:19.191Z] DNS Time: undefinedms
[2026-07-05T13:08:19.191Z] Connect Time: undefinedms
[2026-07-05T13:08:19.191Z] TLS Time: undefinedms

API: Error: [unavailable]
Logs:
[2026-07-05T13:07:56.308Z] Start
[2026-07-05T13:08:17.988Z] Error: ConnectError: [unavailable]

Ping: Error: [unavailable]
Logs:
[2026-07-05T13:07:56.309Z] Sending ping 1
[2026-07-05T13:08:18.092Z] Error: ConnectError: [unavailable]

Chat: Error: [unavailable]
Logs:
[2026-07-05T13:07:56.309Z] Starting stream
[2026-07-05T13:08:18.058Z] Error: ConnectError: [unavailable]

Agent: Error: [unavailable]
Logs:
[2026-07-05T13:07:56.309Z] Starting stream
[2026-07-05T13:07:56.310Z] Pushing first message
[2026-07-05T13:08:18.024Z] Error: ConnectError: [unavailable]

Marketplace: Success
Logs:
[2026-07-05T13:07:56.302Z] Host: marketplace.cursorapi.com
[2026-07-05T13:07:56.462Z] Response in 160ms
[2026-07-05T13:07:56.462Z] Response: 200
[2026-07-05T13:07:56.462Z] Response Type: cors
[2026-07-05T13:07:56.462Z] Server: null
[2026-07-05T13:07:56.462Z] Result: OK in 160ms

Authentication: Success
Logs:
[2026-07-05T13:07:56.304Z] Host: prod.authentication.cursor.sh
[2026-07-05T13:07:56.447Z] Response: 200 in 143ms

Authentication UI: Success
Logs:
[2026-07-05T13:07:56.307Z] DNS lookup: authenticator.cursor.sh
[2026-07-05T13:07:56.421Z] Resolved authenticator.cursor.sh to 8.6.112.8 in 112ms

Cursor Tab: Success
Logs:
[2026-07-05T13:07:56.307Z] DNS lookup: api3.cursor.sh
[2026-07-05T13:07:56.363Z] Resolved api3.cursor.sh to 104.18.19.125 in 54ms

Agent Endpoint: Success
Logs:
[2026-07-05T13:07:56.307Z] DNS lookup: agent.api5.cursor.sh
[2026-07-05T13:07:56.422Z] Resolved agent.api5.cursor.sh to 44.197.141.31 in 112ms

Codebase Indexing: Success
Logs:
[2026-07-05T13:07:56.307Z] DNS lookup: repo42.cursor.sh
[2026-07-05T13:07:56.504Z] Resolved repo42.cursor.sh to 54.173.109.205 in 195ms

Downloads: Success
Logs:
[2026-07-05T13:07:56.306Z] Host: downloads.cursor.com
[2026-07-05T13:07:56.668Z] Response: 403 in 362ms

CDN: Success
Logs:
[2026-07-05T13:07:56.307Z] Host: cursor-cdn.com
[2026-07-05T13:07:56.563Z] Response: 404 in 256ms

Operating System

Windows 10/11

Version Information

Version: 3.9.16 (user setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

Same issue here and it only started today, everything is stuck in either ‘Planning next moves’ or ‘taking longer than expected’

same issue here, always ‘taking longer than expected’

Same issue. any eta on a fix? Why am i unable to use software that i pay monthly for?

This has been happening to me all day as well. Never had this issue so consistently before. I’ve hardly done any work today as most tasks hang forever til I tell the agent to stop or quit Cursor when the agent doesn’t respond.

Happening for me too…
Doesn’t work with these that I tested…

  • GPT 5.5
  • fable

Some others seem to intermittently work, but very slowly if they do.

It seems to be a speed issue maybe…
Also had better results in a new chat but not in an existing chat with more existing context.

When it does work, the text output streams to screen slower.

Tried it on my wifi, and my hotspot… both of which usually work fine. Both producte same slow result or not at all.

Currently unusable.

Update: I can’t really get any model to work now.

27.0 Beta (26A5378j)

Hey everyone! There are actually two different things landing in this thread, so let me split them.

If your agent was mainly slow or stuck on “Taking longer than expected” over the last few days: that lined up with a couple of temporary model-provider slowdowns on Jul 6–7 that have since been resolved. You can check real-time status anytime at status.cursor.com. While a model is under load, switching to Auto or starting a fresh chat (less context = faster) is the quickest way to keep moving.

If Network Diagnostics fail API / Chat / Agent with ConnectError: [unavailable] (like the original report): that one is a local connection/transport issue rather than the provider slowdown. Worth trying, in order:

  1. Update to the latest version (3.10+). Recent builds include connectivity fixes for this exact symptom on some 3.9.x setups.
  2. Cursor Settings → Network → set HTTP Compatibility Mode → HTTP/1.1, then fully quit and reopen Cursor (not just reload the window).
  3. Temporarily turn off any VPN, antivirus web-shield, or custom DNS and re-run diagnostics. A local resolver pinning you to a single unreachable IP produces exactly this pattern.

Full steps: Network troubleshooting

If you’re on the latest version, status.cursor.com is green, and it’s still failing, reply with your OS and a request ID (three-dot menu on a message → Copy Request ID) and we’ll dig in.

Same issue for me. Started noticing some weird behavior already a few weeks back, where the first request went through fine, and every follow-up request got stuck, so I always had to start a new chat. Now since a few days nothing works, every request gets stuck.

I tried everything, including:

  • Quit all other apps (incl. VPN & Tailscale) - Cursor is the only app running.
  • Using HTTP/1.1 or HTTP/1.0
  • Completely uninstalled Cursor (also deleted ~/.cursor and ~/Library/Application\ Support/Cursor
  • I’m on v3.10.20 (see details below)
  • Tried different models incl. Composer 2.5 (Fast), Sonnet 5, Auto.
  • “Run Diagnostics” returns success everywhere.

I’ve been using Google’s Antigravity in the meantime and it’s been working great. Sorry to say, but I’m already more than halfway on the move.

Version: 3.10.20 (Universal)
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 24.2.0

@lighthaus205 - your case looks different from the original report here, so the earlier steps in this thread won’t help. You’re already on the latest build (3.10.20), your diagnostics pass, and you’ve done a full reinstall, so I don’t want to send you in circles repeating those.

The slowdowns several people hit over Jul 6–8 were tied to some temporary model-provider degradation that has since been resolved (you can check current status any time at https://status.cursor.com). Every request hanging on the latest version with clean diagnostics is something we’d want to trace on a real request rather than guess at.

Could you grab a request ID from one of the stuck requests? Send a message, let it hang, then open the three-dot menu on that message and hit Copy Request ID, and paste it here. One caveat: if you have Privacy Mode on we can only see limited data, so if you’re able to, switch to Share Data temporarily in settings, reproduce once, copy the new request ID, then switch back.

Your observation that a fresh chat works but a longer one with more context stalls is a useful clue, and it matches what another person in this thread saw. Until we can trace it, starting a new chat is the most reliable way to keep moving, though I know that’s a workaround and not a fix. I understand the frustration, and a request ID is the fastest way for us to see what’s actually happening on your setup.