Response streaming is very slow - literally letter by letter

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Responses with any model - auto or a particular model selected - are very slow - letter by letter.
First I switched to Composer 2.5 Fast and that made responses faster but then even with that responses got slow.
Happening in new and old chats both - regardless of chat history length.

Steps to Reproduce

Just start a new chat and give some work to the agent in IDE
See that the responses are very slow

Expected Behavior

Responses should be quick - not displayed like as if buffering to the screen - letter by letter

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.19.13 (Universal)
VS Code Extension API: 1.128.0
Commit: dd066f332fcea7382764400fde902f61920648d0
Date: 2026-09-04T17:41:16.065Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Ashish_Kumar2, thanks for the report and the recording, that was helpful.

The model itself is generating at normal speed on our side, and the time until the first word appears looks normal for your account too. What is slow is the delivery of the text to your Mac: it is arriving roughly one word at a time, which usually means something on the network path (a VPN, a security or filtering app, a proxy, or a flaky connection) is holding up the stream. One clue: your Cursor is currently running in HTTP/1.1 compatibility mode rather than HTTP/2, which Cursor switches to automatically when it detects certain proxies.

Could you try the following and tell me what changes?

  1. Open Cursor Settings, go to the Network section, and set “HTTP Compatibility Mode” to “HTTP/2”.
  2. Quit Cursor completely (Cmd+Q) and reopen it.
  3. Start a new chat and send any prompt. Does the text now stream in smoothly?
  4. If it is still slow, temporarily turn off any VPN or security software (for example Netskope, Zscaler,

Also, on one slow response, click the three dots on that message, choose “Copy Request ID”, and paste it here along with which of the steps above helped (if any). That will let us pin down where the time is going.

7

I tried to set HTTP compatibility mode to http/2 but it kept switching back to http/1

And ran the network diagnostics:

Cursor Network Diagnostic Results

FAILED (1): Ping
WARNINGS (1): SSL

DNS: Success
Logs:
  [2026-09-09T15:57:59.352Z] Host: api2.cursor.sh
  [2026-09-09T15:57:59.352Z] Servers: fe80::1,192.168.1.1
  [2026-09-09T15:57:59.352Z] Resolved to 98.87.73.228 in 9ms
  [2026-09-09T15:57:59.393Z] Resolved to 98.87.73.228 in 40ms
  [2026-09-09T15:57:59.395Z] Resolved to 98.87.73.228 in 2ms
  [2026-09-09T15:57:59.398Z] Resolved to 98.87.73.228 in 3ms
  [2026-09-09T15:57:59.402Z] Host: api2.cursor.sh
  [2026-09-09T15:57:59.402Z] Servers: system
  [2026-09-09T15:57:59.402Z] Resolved to 98.87.73.228, 100.59.151.51, 34.192.161.55, 35.170.127.183, 100.61.228.17, 54.235.54.245, 32.193.116.23, 54.226.39.99 in 4ms
  [2026-09-09T15:57:59.402Z] Resolved to 98.87.73.228, 100.59.151.51, 34.192.161.55, 35.170.127.183, 100.61.228.17, 54.235.54.245, 32.193.116.23, 54.226.39.99 in 0ms
  [2026-09-09T15:57:59.402Z] Resolved to 98.87.73.228, 100.59.151.51, 34.192.161.55, 35.170.127.183, 100.61.228.17, 54.235.54.245, 32.193.116.23, 54.226.39.99 in 0ms
  [2026-09-09T15:57:59.403Z] Resolved to 98.87.73.228, 100.59.151.51, 34.192.161.55, 35.170.127.183, 100.61.228.17, 54.235.54.245, 32.193.116.23, 54.226.39.99 in 1ms
  [2026-09-09T15:57:59.403Z] Result: true

SSL: Warning: Encrypted traffic is being intercepted by unrecognized certificate: C=US; O=PromptSecurity; CN=ca.prompt.security
Logs:
  [2026-09-09T15:57:59.343Z] Start
  [2026-09-09T15:58:00.260Z] URL: https://api2.cursor.sh/
  [2026-09-09T15:58:00.260Z] Status: 200
  [2026-09-09T15:58:00.260Z] IP: 127.0.0.1
  [2026-09-09T15:58:00.260Z] Issuer: C=US; O=PromptSecurity; CN=ca.prompt.security
  [2026-09-09T15:58:00.260Z] Name: api2.cursor.sh
  [2026-09-09T15:58:00.260Z] AltName: DNS:api2.cursor.sh, DNS:prod.authentication.cursor.sh, DNS:*.api2.cursor.sh
  [2026-09-09T15:58:00.260Z] DNS Time: 278ms
  [2026-09-09T15:58:00.260Z] Connect Time: 0ms
  [2026-09-09T15:58:00.260Z] TLS Time: 280ms
  [2026-09-09T15:58:00.260Z] Result: Warning: Encrypted traffic is being intercepted by unrecognized certificate: C=US; O=PromptSecurity; CN=ca.prompt.security in 917ms

API: Success
Logs:
  [2026-09-09T15:57:59.344Z] Start
  [2026-09-09T15:58:00.256Z] Result: true

Ping: Error: Response took 1160ms
Logs:
  [2026-09-09T15:57:59.344Z] Sending ping 1
  [2026-09-09T15:58:00.257Z] Response: 'ping' in 913ms
  [2026-09-09T15:58:00.257Z] Sending ping 2
  [2026-09-09T15:58:01.161Z] Response: 'ping' in 904ms
  [2026-09-09T15:58:01.161Z] Sending ping 3
  [2026-09-09T15:58:02.215Z] Response: 'ping' in 1054ms
  [2026-09-09T15:58:02.215Z] Sending ping 4
  [2026-09-09T15:58:03.289Z] Response: 'ping' in 1074ms
  [2026-09-09T15:58:03.289Z] Sending ping 5
  [2026-09-09T15:58:04.449Z] Response: 'ping' in 1160ms
  [2026-09-09T15:58:04.450Z] Result: Error: Response took 1160ms

Chat: Success
Logs:
  [2026-09-09T15:57:59.344Z] Starting streamSSE
  [2026-09-09T15:58:00.296Z] Response: 'foo' in 949ms
  [2026-09-09T15:58:01.333Z] Response: 'foo' in 1037ms
  [2026-09-09T15:58:02.380Z] Response: 'foo' in 1047ms
  [2026-09-09T15:58:03.325Z] Response: 'foo' in 945ms
  [2026-09-09T15:58:04.324Z] Response: 'foo' in 999ms
  [2026-09-09T15:58:05.297Z] Result: true

Agent: Success
Logs:
  [2026-09-09T15:57:59.344Z] Starting stream
  [2026-09-09T15:57:59.347Z] Pushing first message
  [2026-09-09T15:58:00.338Z] Response: 'foo' in 991ms
  [2026-09-09T15:58:00.839Z] Pushing next message
  [2026-09-09T15:58:01.889Z] Response: 'foo' in 1551ms
  [2026-09-09T15:58:02.390Z] Pushing next message
  [2026-09-09T15:58:03.470Z] Response: 'foo' in 1581ms
  [2026-09-09T15:58:03.971Z] Pushing next message
  [2026-09-09T15:58:05.002Z] Response: 'foo' in 1532ms
  [2026-09-09T15:58:05.503Z] Pushing next message
  [2026-09-09T15:58:06.472Z] Response: 'foo' in 1470ms
  [2026-09-09T15:58:06.472Z] Result: true

Marketplace: Success
Logs:
  [2026-09-09T15:57:59.331Z] Host: marketplace.cursorapi.com
  [2026-09-09T15:57:59.581Z] Response in 250ms
  [2026-09-09T15:57:59.581Z] Response: 200 
  [2026-09-09T15:57:59.581Z] Response Type: cors
  [2026-09-09T15:57:59.581Z] Server: null
  [2026-09-09T15:57:59.581Z] Result: OK in 250ms

Authentication: Success
Logs:
  [2026-09-09T15:57:59.331Z] Host: prod.authentication.cursor.sh
  [2026-09-09T15:58:00.277Z] Response: 200  in 946ms

Authentication UI: Success
Logs:
  [2026-09-09T15:57:59.343Z] DNS lookup: authenticator.cursor.sh
  [2026-09-09T15:57:59.391Z] Resolved authenticator.cursor.sh to 104.18.35.233 in 46ms

Cursor Tab: Success
Logs:
  [2026-09-09T15:57:59.343Z] DNS lookup: api3.cursor.sh
  [2026-09-09T15:57:59.353Z] Resolved api3.cursor.sh to 104.18.19.125 in 7ms

Agent Endpoint: Success
Logs:
  [2026-09-09T15:57:59.343Z] DNS lookup: agent.api5.cursor.sh
  [2026-09-09T15:57:59.544Z] Resolved agent.api5.cursor.sh to 54.153.104.1 in 195ms

Downloads: Success
Logs:
  [2026-09-09T15:57:59.332Z] Host: downloads.cursor.com
  [2026-09-09T15:58:00.103Z] Response: 403  in 771ms

CDN: Success
Logs:
  [2026-09-09T15:57:59.332Z] Host: cursor-cdn.com
  [2026-09-09T15:57:59.730Z] Response: 404  in 398ms

Prompt security is something configured by company’s IT - for making sure prompts don’t divulge customer data or lead to any commands that fetch or log customer data openly

If that’s problematic - which it seems - I’ll report to my company’s IT as well.

Any further advice though? Thank you for reply.

8

it happened again

even after our company IT disabled prompt security

cursor request id - 3caa3c94-73a9-4286-b242-9766e7220779

12

I am a colleague of Ashish, the individual who initiated this thread.

We have a followup question to this part of your earlier diagnosis:

" … your Cursor is currently running in HTTP/1.1 compatibility mode rather than HTTP/2, which Cursor switches to automatically when it detects certain proxies. "

We are using Prompt here to help monitor our AI interactions.

The question is:

Why does Cursor downgrade the HTTP setting?
What are " certain proxies " ?

Is there something that can be changed with Prompt to prevent the downgrade from happening?

13

Just confirming what Shane already said - like I had reported earlier too - I can’t switch HTTP compatibility to HTTP/2 - is that a cursor bug?

17

Hey @Shane_Durham and @Ashish_Kumar2, thanks for the follow-up questions, happy to explain what is happening!

Cursor talks to its servers over HTTP/2 and uses that connection to stream responses. During every encrypted (TLS) handshake the two sides agree on the protocol to use (this step is called ALPN). If whatever terminates the TLS connection on your side does not offer HTTP/2 there, the connection fails, and Cursor switches itself to HTTP/1.1 compatibility mode so requests keep working. It saves that choice in your user settings and it does not switch back on its own. That is probably why the dropdown kept reverting: each time Ashish picked HTTP/2, the very next request hit the same interception and Cursor flipped it again.

Try this after disabling prompt security:

  1. Quit Cursor completely (Cmd+Q) and reopen it.
  2. Open Cursor Settings go to Network, and click “Run Diagnostics”. On the SSL line you should now see an Amazon issuer and no mention of PromptSecurity or 127.0.0.1. If it still shows PromptSecurity, the exclusion is not active yet. Stop here and share that line with IT.
  3. In the same Network section, set “HTTP Compatibility Mode” to “HTTP/2”.
  4. Quit Cursor completely (Cmd+Q) and reopen it again.
  5. Start a new chat and send any prompt. Watch how the text arrives.
  6. Go back to Settings, Network, and confirm the dropdown still says HTTP/2.

If it still reverts even though the SSL line is clean, open Terminal, run defaults read com.todesktop.230313mzl4w4u92 NetworkDisableHttp2 and paste the output here. That tells us whether a device management policy is forcing compatibility mode. And if HTTP/2 sticks but the text still trickles, share a fresh Request ID from that chat and we will take another look!

18

After the first pass of completely quitting Cursor, restarting it, and checking the network settings..

Yes, the application immediately acknowledges that Prompt is present and in effect.

[2026-09-14T17:52:34.178Z] Result: Warning: Encrypted traffic is being intercepted by unrecognized certificate: C=US; O=PromptSecurity; CN=ca.prompt.security in 898ms

And the slow rending of AI responses remains.

I did not complete the remainder of the suggested steps - any attempt to switch to the Http/2 options is instantly undone.

What to make of this?

If I understand you correctly, the working theory is that Prompt does not adopt the HTTP2 protocol correctly - or, at least, it does not provide HTTP2 in the manner which Cursor expects. Thus, Cursor continues to fallback to HTTP1.1

Can we get any clarity on just what that discrepancy could be?

UPDATE
Sorry, I overlooked your very first comment, suggesting that ‘Prompt’ be disabled.

At present, that isn’t an option but, yes, there are periods where it has been temporarily disabled, and yes, the Cursor application operates well during these brief windows.

I concede that this then indicates there may be an issue with Prompt or our configuration of it. We’re just looking for help with diagnosing what that issue could be, For instance, maybe we just need to inform Cursor of the Prompt certificate that it is encountering?

22

Cursor already trusts the Prompt certificate. In your diagnostics, the SSL check returned 200, and the API, Chat, and Agent checks all passed. The line you quoted simply notes that the certificate was issued by Prompt, rather than our provider confirming that traffic is decrypted and re-encrypted on the Mac. A real trust problem would show errors like “unable to verify the first certificate,” and nothing would work. Adding the certificate elsewhere won’t change the speed.

The issue is HTTP/2. During the TLS handshake, Cursor requests HTTP/2 (the ALPN step), and whatever terminates the connection must respond with “h2”. Prompt’s local proxy seems to reply with HTTP/1.1 or nothing, so the HTTP/2 connection fails and Cursor falls back to “HTTP/1.1 compatibility mode.” That’s why any attempt to switch back is immediately undone.

Even on HTTP/1.1, Cursor holds one long-lived connection per response and streams the text as many small messages, with the conversation uploaded the same way. Our server-side timing for Ashish’s requests shows the model finishing in seconds, while the text takes minutes to reach the Mac, and on several requests this week, the server waited two to three minutes just to receive the conversation before it could start. Your diagnostics show roughly 1 second per round trip, which is normally a fraction of that. The proxy is inspecting each message in both directions. That most likely explains the letter-by-letter effect, and why Cursor is fast whenever Prompt is disabled.

There’s not much more we can do in terms of troubleshooting if something installed locally on your machine is producing this effect! I would, however, suggest you bring this information to the folks who work on Prompt Security and see if they’re aware of configuration that can help here.