Terrible agent speed on poor internet connections

For some reason, Cursor has become really poor on mediocre internet speeds and router setups (e.g. 10-20Mbps). It is really useless.

It never really used to be this way - I’ve dropped compatibility to HTTP 1.0. Maybe some clever stuff behind the scenes thats great for decent internet connections but not good ones.

Same thing on a variety of internet connections in Vietnam wherever I go. I can stream TV online well enough, why not Cursor.

I have had to cancel and give Codex a go - like Claude Code it seems to tolerate terrible internet connections a lot better. Cursor disconnects all the time, if I come back to a shortish chat and start again with a message it falls over again

I don’t know if I can provide a Request ID or something. In any case, Codex and Claude Code are usable - Cursor is not

Hey, thanks for the question. I’ll comment on the main point.

From the diagnostics screenshot, the key thing is this: Ping hit 1 715 ms, which is very high latency. The other endpoints do respond, but when streaming agent replies is involved (lots of long-lived connections plus tool calls back and forth), high jitter and latency hurt much more than with normal HTTP. This is an area where Codex and Claude Code do behave more tolerably because they use a different exchange protocol.

A few things that would help us narrow it down, if you’re still up for testing:

  1. What Cursor version are you on, and which model is selected in the agent (Auto / Sonnet / Opus / GPT)?
  2. The Request ID from at least one failed session: in the chat, top right corner (three dots) > Copy Request ID. Even one is enough to check the logs and see exactly where it breaks.
  3. If you haven’t tried both ways yet: in Settings, find Disable HTTP/2 and toggle it. Sometimes HTTP/2 multiplexing is worse on networks with high packet loss, sometimes the other way around, and HTTP/1.1 can be worse due to TLS handshakes on each connection.

I’ll pass your feedback about the difference vs Codex and Claude Code to the team. It’s a useful signal for prioritizing work on resilience on poor networks. I can’t give an ETA, but we know the direction.