[unavailable] PING timed out on every agent — high latency from Thailand (~800ms vs 50ms Cloudflare)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Issue: Every agent request fails with [unavailable] PING timed out (“Taking longer than expected”) across all models, all workspaces, on both my Ultra account and a test free account.

Request IDs: 00168682-d6d7-4d31-a3d6-e43673818856, 9be683a9-c7f5-42b5-8cd7-0a8ea79e48c5, ca61e60b-0596-4e4e-b92c-4d410ba5750a

Already ruled out: reinstalled + updated to stable (v3.9.8), signed out/in, fresh OS reboot, no MCP servers, no proxy/VPN in path, status page green, HTTP/2 disabled.

Key finding: I’m in Thailand. General internet is healthy — Cloudflare responds in ~50ms. But api2.cursor.sh is consistently ~800ms and spikes to 3s+. Single requests succeed; the long-lived HTTP/2 agent stream’s keepalive PING times out. Looks like a regional routing/latency issue between Thai ISPs and your agent backend.

Ask: Is there a closer region, or can the agent-stream PING timeout be relaxed for high-latency clients?

Steps to Reproduce

  1. Open the Cursor desktop app (macOS, v3.9.8 stable), signed into an Ultra account, located in Thailand.
  2. Open any workspace, start a new agent in Local mode, any model.
  3. Send any prompt (e.g. “go deeper”).
  4. Agent shows “Taking longer than expected…” indefinitely, then fails with [unavailable] PING timed out.

Reproduces 100% of the time — every model, every workspace, and also on a separate free account on the same Mac.

Expected Behavior

The agent should respond normally. The long-lived agent stream should hold its connection instead of dropping with a PING timeout when latency to the backend spikes.

Operating System

MacOS

Version Information

Cursor IDE
Version: 3.9.8 (stable)
Commit: 4aa8ff1b7877
Date: 2026-06-25
OS: macOS (Darwin 25.5.0)

For AI issues: which model did you use?

Composer 2.5 Fast — but it fails on EVERY model (also reproduced on Auto and Sonnet 4.6 Medium). Model-independent.

For AI issues: add Request ID with privacy disabled

00168682-d6d7-4d31-a3d6-e43673818856
9be683a9-c7f5-42b5-8cd7-0a8ea79e48c5
ca61e60b-0596-4e4e-b92c-4d410ba5750a
(Data Sharing is enabled on my account, so these should be traceable on your side.)

Additional Information

Extensive local troubleshooting already done — all ruled out:

  • Reinstalled Cursor; updated to stable v3.9.8; switched release track dev → stable.
  • Signed out/in; reproduced on a second (free) account on the same Mac.
  • Fresh OS reboot.
  • No MCP servers configured; no system proxy; no active VPN in the route (traffic egresses normally via Wi-Fi en0).
  • status.cursor.com all-green during the failures.
  • Tried disabling HTTP/2.

Network evidence (same machine, same moment):

  • Cloudflare: ~50ms, rock-steady.
  • api2.cursor.sh: ~800ms consistently, spiking to 3s+.
    Single HTTPS requests to Cursor succeed; it’s the long-lived HTTP/2 agent stream’s keepalive PING that times out. Looks like a regional routing/latency issue between Thai ISPs and the Cursor agent backend, made fatal by a tight stream PING timeout.

Q: Is there a closer region/edge for the agent backend, or can the agent-stream keepalive timeout be relaxed for high-latency clients?

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hi @Fronk_GGC Thanks for the forum post and I apologize for the inconvenience here. Thanks for the detailed report and request IDs. I checked activity around the reported time and found repeated 30-second gaps where you didn’t get the responses you should have been getting.

As a temporary test, could you try either a mobile hotspot or a VPN with a Singapore exit? The goal is to change the network path. This is different from disabling HTTP/2, which you already tested.

Please also run Cursor Settings > Network > Run Diagnostics and share which checks fail: Network, proxy, and remote connections | Cursor Docs Thanks!