For even a simple request like “Hi”, the agent takes at least 3 minutes to respond. When using the CLI, it keeps showing “reconnecting” for a couple of minutes before eventually failing without a response. I’m based in India.
At the moment, the experience is frustrating enough that I’m essentially unable to use the Agent feature reliably. I’m on the Pro+ plan, and it’s extremely disappointing to keep running into this issue consistently even after trying multiple suggested fixes and network configurations mentioned in the forum here.
I also tried enabling HTTP Compatibility Mode (HTTP/1.1). However, after switching to it, I started getting the following error:
“Append data exceeds maximum size of 52428800 bytes”.
I ran the Network Diagnostics multiple times and noticed something inconsistent:
Sometimes the Agent test fails with:
“Bidirectional streaming is not supported by the http2 proxy in your network environment.”
However, rerunning the diagnostics immediately afterward sometimes makes the error disappear and all checks pass successfully.
I also tried using Cloudflare WARP and Google DNS, but neither resolved the issue.
Steps to Reproduce
Open Agent or the CLI, send a simple prompt like “Hi”, and wait several minutes until it either reconnects repeatedly or fails without returning a response.
Sorry for the frustration. This isn’t your setup - there are two separate things going on here:
The “Append data exceeds maximum size” error when using HTTP/1.1 mode - this was a bug on our end that’s been fixed in a recent update. Your current version (3.6.21) likely predates the fix. Please update Cursor to the latest version (Help > Check for Updates or re-download from cursor.com), then try enabling HTTP Compatibility Mode (HTTP/1.1) again. It should work without the size error.
The underlying slowness and reconnecting from India - this is a known infrastructure issue we’re tracking. Our streaming endpoint doesn’t currently route through CDN edge nodes in your region, which causes high latency and the intermittent “bidirectional streaming not supported by http2 proxy” diagnostic result. HTTP/1.1 mode (once updated) should help reduce the reconnection loops, though you may still experience some latency compared to users in other regions.
After changing the HTTP compatibility to 1.1, the response time has improved quite a bit, but it’s still not where I’d expect it to be, especially when using a fast model on a fast internet connection. For comparison, Claude Code on Opus 4.8 with a 1M context window returns a response in about 5 seconds without even using Fast Mode, whereas Cursor takes roughly 14 seconds to answer the same request when using Composer 2.5 Fast (request id: 6da5945a-8b36-478c-8940-9490e36019b0).
Glad to hear the update helped and HTTP/1.1 mode is working now.
The remaining latency you’re seeing is the regional infrastructure issue I mentioned - our streaming endpoint (api2.cursor.sh) currently routes through US servers without CDN edge nodes in your region, which adds round-trip overhead on every streamed chunk. Claude Code connects more directly to Anthropic’s infrastructure, so the comparison isn’t quite 1:1, but the gap you’re noticing is real and something we’re aware of.
This is actively tracked on our end and the infra team is looking at routing improvements. I don’t have a specific timeline to share, but it’s on our radar.
When will you rectify the infra issue? Also, it’s not even possible to use the Cursor CLI. You continuously see Reconnecting, and after some time, it ends without giving a response.
On the infra side: I don’t have a timeline I can share. It’s tracked and the routing improvement is still open, but I won’t pretend there’s an ETA on it.
For the CLI specifically, there’s a fix worth trying. The HTTP/1.1 switch that helped you in the editor also exists for the CLI - it’s just set in a config file instead of the settings UI. The CLI defaults to HTTP/2, and on your route that’s the connection that keeps dropping and driving the “reconnecting → failed 10 times” loop (the same transport that HTTP/1.1 mode avoids).
Add the network block to ~/.cursor/cli-config.json, then restart cursor-agent. If you already have a cli-config.json, just add the "network" key — don’t replace the whole file (it holds your permissions/model settings). If the file doesn’t exist yet, you can create it with:
This should stop the reconnect loop in the CLI the same way HTTP/1.1 mode did in the editor. You may still see more latency than you’d like given the regional routing, but it should complete the request instead of failing out. Let me know if it helps.
