Follow-up messages often get stuck on "Taking longer than expected..."

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Follow-up messages often get stuck on “Taking longer than expected…”

Steps to Reproduce

Send a follow-up message and it sometimes gets stuck on “Taking longer than expected…”

Expected Behavior

It should just start immediately.

Operating System

MacOS

Version Information

3.17.19 (Universal)

For AI issues: which model did you use?

Grok 4.6 High Fast

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Oliver_Frost, thanks for the report.

I looked at your recent sessions and there are two different things behind that message.

Some of those follow-ups never actually left your machine. The request sat at “Taking longer than expected” without ever reaching our servers, and the turn only ran after it was resent. This is a known issue we are tracking on the client side, and I have added your report to it. In the meantime, if a follow-up sits on that message for more than a minute without activity, press Stop and resend it (or click “Send Now” if the message is showing in the queue tray). It should start right away.

The rest were real, just slow. That conversation has grown very large (well over a hundred context messages), and Grok 4.6 High Fast is taking 40 seconds or more to produce its first token. Starting a new chat for the next piece of work will make those first tokens noticeably faster.

Two things that would help:

  1. Please update to the latest Cursor (3.18.x). It includes a fix in this area that recovers a turn that gets stuck after the previous one finishes.
  2. Next time a follow-up gets stuck, before you resend, open the chat menu (top right of the chat) and choose Copy Request ID, then paste it here and let me know whether the message was sitting in the queue tray at the time.
7

Hi @Colin ,

I found this thread while searching for the same problem. I’m experiencing very similar symptoms, but my setup doesn’t seem to match the two causes you mentioned:

Cursor version: 3.18.25 (user setup) — this includes the fix you mentioned, but the behavior still occurred.
At the time, the conversation context was around 159.9K, which I believe is below the threshold that would trigger compaction.
The stuck turns were not sitting in the queue tray. They just stayed at “Taking longer than expected” for a long time and eventually failed with the 503 / resource_exhausted error.
This happened in a cluster several hours ago, and it is working normally now.
Let me know if you need more details. Happy to provide request IDs if that helps.

Thanks!