Network: Tailscale active (MagicDNS 100.100.100.100); on-demand billing
Symptom Many chats start, consume/charge a few thousand tokens, then the model “stalls” and never produces output. No error is shown. Happens across multiple models (seen with claude-opus-4-8 and composer-2.5). Some short requests do complete, so it’s intermittent.
What the logs show On a stalled request, the client starts a client.ttft (time-to-first-token) span and it never completes — the first token is never received and the request hangs open with no error logged:
span_started name=“client.ttft” ← never completes, no tokens ever stream back
On requests that do work, client.network_ttft completes in ~5.5s and streaming proceeds normally. So the difference is purely whether the streamed response ever delivers its first byte.
Already checked
curl https://api2.cursor.sh → HTTP 200 (basic connectivity is fine)
HTTP/2 transports are created successfully to api2/api3/api4/repo42/agentn.global.api5.cursor.sh
No proxy set by me (the only proxy env vars present are Cursor’s own terminal-sandbox proxy)
Tailscale is providing DNS; I’m testing with it disabled to isolate.
Question: Is this a known issue with long-lived HTTP/2 streams on the macOS 26 beta and/or with Tailscale? I can’t easily roll back the OS beta. Happy to provide full request-trace logs (they contain the client.ttft never-completing spans).
@MaxBCM I just got the following from their support bot in email, give it a try!
Hey there! Thanks for reaching out. Your ticket number is XXXXXX for your reference.
The best immediate fix for the streaming stall is switching to HTTP/1.1 mode:
Go to Cursor Settings > Network
Set HTTP Compatibility Mode to HTTP/1.1
Fully quit Cursor with Cmd+Q (just closing the window is not sufficient)
Relaunch
This shifts from HTTP/2 bidirectional streaming to HTTP/1.1 SSE, which avoids the long-lived connection behavior you’re describing. For any already-stuck conversations, Cmd+N to start a new chat will also clear the stalled client state.
On service status: Cursor is fully operational right now. There was a minor incident earlier today resolved by ~7:58 AM UTC affecting Composer and Grok, but that would not account for the pattern you’re seeing later in the day.
On the billing: we’re unable to refund on-demand usage charges, whether the usage was intentional or not. These are valid charges, and we incur real costs from our model providers. This policy applies consistently to all our customers.
If the HTTP/1.1 switch doesn’t resolve things, please share the actual request UUIDs from your traces (format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) and I’ll look them up directly to investigate further.
@MaxBCM Mine never returned, I ended up having more issues because of macOS 27, so I just wiped my system and reinstalled macOS 26. I didn’t have time to wait around, I had to get back up and running! Good chatting with you, hopefully it stays up and going!
