Cursor Grok 4.6 model response taking too long

Support Help
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s new Grok 4.6 model takes a bit longer to respond in the chat window. it is not too long but at least 10 seconds or so. is it normal?

Steps to Reproduce

Start chatting with the new Grok model

Operating System

Windows 10/11

Version Information

Version: 3.19.7 (user setup)
VS Code Extension API: 1.128.0
Commit: 90de2327392570a5f5f625c656c6749d228e6430
Date: 2026-09-02T23:03:07.739Z
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: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

I think around 10 seconds is totally fine for coding, especially if the model is doing more reasoning before answering. If Grok 4.6 is taking about 10 seconds before the response starts, I wouldn’t necessarily consider that a bug.

It could simply be taking a little longer to think through the problem and then generate a better solution.

6

Hey, yes, what you’re seeing is normal.

Grok 4.6 is a reasoning model. On the High setting, it thinks through the task first and only then starts writing, so a few seconds of delay (sometimes closer to 10) before the first text appears is expected behavior. The model also slows down a bit as the chat gets longer, because on each turn it rereads the whole conversation.

What helps make it respond faster:

  1. Start a new chat when the conversation gets long. Long threads are the main factor behind that initial delay.
  2. Try Medium effort in the model picker. It replies faster and it’s enough for most everyday edits. Save High for harder tasks.
  3. You already have Fast enabled, keep it on, or use Auto when you need the fastest first response.

If a request ever hangs noticeably longer than a minute, shows Taking longer than expected, or ends with an error, that’s a different story. In that case, click the three dots on the message, choose Copy Request ID, and send it here, and we’ll take a closer look. For an example of what it looks like during truly slow runs, here’s a similar thread: Taking longer than expected in almost every Grok run

7

Grok definitely became slower. I’ve been using it everyday, all day, since Grok got offered in Cursor (I’m a senior web dev working fulltime) and even in fast-mode it is quite slow to finish tasks. just to compose a commit message & commit a few files can take it 2 minutes, not to mention other more complex tasks.

I’m always using xhigh on “fast” mode because slow more is extremely slow, can take many long minutes to complete tasks, which leaves me unable to continue working until it finishes my question/task

In the beginning Grok was INSANELY fast, like instant fast. Now it’s at least 5 times slower. For sure.

8

I’ve also seen noticeable slow downs. It used to be blazing fast and now it much longer.

9

Hey @yaireo @zanawar, it’s worth separating two different cases.

Case one: the first token taking a few seconds sometimes closer to 10 on a reasoning model at High or xHigh is expected, especially when the chat gets large. On every turn it rereads the full history. I mentioned this above.

But 2 minutes for a simple commit message, or 5x slower than before, is a different case. We need to look at specific requests. From our telemetry, Grok 4.6 in Fast mode is stable right now with no general slowdown, so it’s important to catch your specific slow runs.

Can you share the Request ID for a couple of the slowest requests? Use the three dots on the message > Copy Request ID. Also please confirm:

  • Effort level High, xHigh, or Medium, and whether Fast is on
  • How long the chat was at that moment, new or already hundreds of messages
  • Your Cursor version

With the Request ID, we can check where the time is going, provider side, context length, or something else.

10

I posted this in a different thread, but that thread was renamed, so I deleted that post and moved it to here because it makes the most sense.

Original post:
"I am experiencing the same issue as well . I have Grok 4.6 on Extra High and Fast and the last 2 to 3 weeks. Basically since the release of Grok Bot, I have noticed a significant reduction in speed. I am not sure if that is linked or not, but it has been quite annoying because I had only just purchased Cursor Ultra in mid August.

It was great and fast when I purchased it, and now… it has been severely reduced. When I purchased it though, Grok 4.6 hadn’t been released yet and when it was fast, it was on Grok 4.5. After the 4.6 release, it was fast for a week or so, then plummeted with the release of Grok Bot.

I am not saying that this is the cause for this. These are just my observations."

11

Thanks for the details, @Dan_Livingstone. It’s worth separating two cases.

First is when the first token on a reasoning model (High/xHigh) shows up after a few seconds, sometimes closer to 10. That’s expected, especially as the chat gets bigger. On each step, the model rereads the whole history. I mentioned this above.

But “it’s gotten several times slower over the last 2 to 3 weeks” is a different case, and we need to look at specific requests. From our telemetry, Grok 4.6 in Fast is stable right now. We don’t see a general slowdown, so it’s important to catch your slow runs.

Can you share the Request ID for a couple of the slowest requests? Three dots on the message > Copy Request ID. Also, can you confirm:

  1. Effort level (High / xHigh / Medium) and whether Fast is enabled
  2. How long the chat was at that time, new or already hundreds of messages
  3. Your Cursor version

With the Request ID we can check where the time goes, provider side, context length, or something else. As an example of what truly slow runs look like, here’s a similar thread: Taking longer than expected in almost every Grok run

12

@deanrie - Thanks for getting back to me.

Sure, here is the request ID: 60c862d7-2844-40b4-ba63-478ff4ffceb6

  1. xHigh Fast Enabled
  2. 100s of messages
  3. Version: 3.19.19 (user setup)
    VS Code Extension API: 1.128.0
    Commit: 6496ea8a068aebfcd21990e70ff522e9abf10c80
    Date: 2026-09-08T16:25:33.352Z
    Layout: Agent Window
    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: Windows_NT x64 10.0.26200

Thanks for linking the similar thread. It was helpful.

If you could provide any details about why this is all of a sudden happening, that would be great.

16

When it’s happens to me, after 1 minute, i just force chat interaction like: “did you crash?”, and it’s back to normal

17

but today, it’s hard.. every task stucks on this
i think is only a grok problema, with others models it’s working fine

18

Hey @Dan_Livingstone, thanks for the Request ID, that’s exactly what we needed.

That request ran normally in about 38 seconds. About 19 seconds of that was the model re-reading your chat before it started writing. The chat is very large, around 200k tokens, which is almost 80% of what Grok 4.6 can hold in context. The model re-reads all of it from scratch every time you send the first message after a pause of a few minutes. Messages sent back-to-back reuse that work and start in about a second, which is what happened for the other calls inside the same request.

In the same chat, two turns later, you can see the same pattern. About 19 seconds after a 16-minute break, and about 1 second when the next message arrived after 3 minutes.

We also checked Grok 4.6 Fast across all users for the last three weeks, and time to first token hasn’t changed. What did change on your side is that your chats have grown a lot since mid-August, and the cost of that re-read grows with them. So this isn’t due to the Grok Bot release, and it’s not caused by anything in your setup.

What will have the biggest impact:

  1. Start a new chat for each new task, and open a fresh one when the context indicator in the chat gets high. This is the strongest lever.
  2. If you need history, ask the agent to briefly summarize the current state into a note, then paste that into a new chat.
  3. Keep Fast enabled. Extra High vs High barely affects how quickly the first text shows up, so pick based on quality.

If any request in a fresh chat hangs noticeably longer than a minute or ends with an error, send the Request ID and we’ll take a closer look.

19

@deanrie - Thanks for looking into this. With all due respect though, this sort of response isn’t helpful at all.

This is one prompt over weeks of usage. The context window is summarized automatically when it becomes too large, so the context size would play a small role in what is happening. I have tried new chat windows, same chat windows, it is all the same. When I experience slowness, it is typically really slow with the message “Taking longer than expected”.

It could possibly be related to the issues in this thread as well: Taking longer than expected in almost every Grok run - #30 by Colin

You can tell that this is something on the Grok end because as of Monday Sept 14, all of the issues are gone and everything appears to be working normally again.

Before I was using Fast Mode and it was going just as slow as it would without it on, but of course, still burning twice the amount of credits, so I turned it off because there was no noticeable difference. Prompts would sometimes take 2 to 3 tries before they actually produced output.

After doing some testing on Monday, everything appears back to normal. Reasoning levels are working, Fast Mode is working. Work is getting done as it should, at a reasonable pace, even with multiple agents running.

This was not the case before and it would take an entire day to do the same volume of work that would usually take an hour or 2. So there was definitely something happening that was causing this.

Now that it is fixed, I am not sure how to troubleshoot, but I guess there isn’t a need to; but to blame this on context window size and a few specific prompts, is incorrect.

I apologize if I have overstepped, that is not my intention. It is just frustrating to see the expensive product you are paying for throwing credits and usage away over something that is not in your control, as well as not being reimbursed for the issues. If fast mode, running at the same speed as normal is burning twice the credits without any benefit, that is an issue, but it’s the consumer that is at the disadvantage, because I will never get those credits back.

20

Hey Dan, fair point, and you’re right that there are two different cases here, and I only addressed one of them.

That single Request ID really did show a long cold re-read of a large context. But it doesn’t explain what you’re describing over several weeks: “Taking longer than expected,” 2 to 3 retries before output, and Fast mode not being any faster while costing twice as much. That’s a separate issue, and it’s not about your setup.

During that period, Grok 4.6 (and 4.5) was slow to start for a while under high load. Time to first token went up during peak hours, and that was on the capacity/provider side, not your configuration. The same pattern was discussed in a related thread, where it was confirmed: Taking longer than expected in almost every Grok run. The fact that since Monday, 14 September, everything has been back to normal for you, reasoning levels, Fast, multiple agents in parallel, fits a recovery after that window. So your observation is correct, and sorry my first reply sounded like it all came down to context size.

If it gets slow again, the best way to catch it is to share a couple Request IDs from the slow runs (three dots on the message > Copy Request ID). Then we can see where the time is going. If things are stable right now, there’s nothing you need to do.

About credits spent during that period, that’s for a different team at [email protected]. They’ll be able to look into your specific situation.

Let me know if you notice the slowdown again, and we’ll dig into the specific requests.

21

Here is a request ID example of the (many daily) extremely slow interactions of Grok 4.6 FAST mode (xhigh):slight_smile:

7d9a6b58-a7a5-49fd-9160-8dc6e9d238f0

25

Hey, @yaireo, thanks for the Request ID. That run really was slow, and it wasn’t on your side.

The request took about 5 and a half minutes and made 9 calls to the model. Around 4 minutes of that was waiting for the first token. The first call re-read the whole chat (about 140k tokens), which is usually 15 to 20 seconds, but the next six warm-cache calls, which should start in about a second, each took 14 to 68 seconds. That’s not normal.

The reason was a short stall on the serving cluster that was handling your chat that morning (around 09:30 to 09:45 UTC). The conversation stays on one cluster across all steps, so every step of this request got hit. It recovered in about 15 minutes, and your other Fast requests that day, plus on the 17th and 18th, started in about a second.

One thing to know. On days when Fast was off, non-Fast Grok 4.6 can start noticeably slower, sometimes over a minute, and that’s expected for that mode right now.

If you hit this again with Fast enabled, send 2 to 3 Request IDs (three dots on the message > Copy Request ID) and the approximate time. That way we can see if you’re still landing on stalls or if it’s something else.