Hey, thanks for the detailed report and the Request ID. That helped us figure it out quickly.
What you saw was a short load spike on Composer 2.5 that same morning, around 06:24 to 06:47 UTC on Aug 4. During these spikes, some traffic to the model gets temporarily blocked, and you’ll see the “We’re experiencing high demand for Composer 2.5” message along with reconnects. Your account is totally fine, and it’s not related to your setup.
This has already been resolved, and the model is handling requests normally again. If you hit this message again, the usual workaround is to switch to Auto or another model, or retry the request in a couple minutes.
Let me know if Composer 2.5 still looks odd on your side and we can dig in deeper.
BTW is seems that its account related, because I have another account under teams and this works correctly. The teams account is used on OS X and this Pro account on a Windows PC
Thanks for the new Request ID. The difference between the accounts is confusing, but this isn’t about the account itself or Windows.
Composer 2.5 has been hitting short demand spikes since this morning. During those moments, some traffic to the model gets temporarily limited. That’s why you see the “high demand” message and reconnects. These windows are brief and repeat, so you saw the error a couple more times. Your second account Teams is in a different billing group that wasn’t affected by those spikes, which is why it works there. This isn’t about the OS or a specific account setting.
While the model is under load, the fastest workaround is to switch to Auto or another model, or retry the request in a couple of minutes. We’re tracking these spikes on the infrastructure side.
Let me know if the error becomes constant instead of happening only once in a while, and we’ll dig deeper.
@venturaj, “Taking longer than expected” isn’t a block anymore, it’s a slower response under the same Composer 2.5 load I mentioned above. To look at your specific case, please share the Request ID from one of those slow requests with Privacy Mode off, then I can see exactly where the time is being spent.
@kgrinds if this has been happening all day for you, please start a separate thread with your Cursor version, OS, and the Request ID of a slow request. That way we won’t mix different cases and we can track yours properly.
For now, the workaround during high load is the same, use Auto or a different model. Send the Request ID and we’ll dig deeper.
I have been getting - “Taking longer than expected” from last 12 hrs. I have tried disabling HTTP2, reindexing, reinstalling cursor, Run diagnostics. I am still getting the same issue
Hi all, we are investigating elevated error rates on some Composer 2.5 requests this morning. Nothing on your end is causing it, and it’s an issue we’re tracking. It is sporadic, so your Composer requests might be totally fine, but you may also be seeing issues like the ones shown here.
Two things that should help for now:
Start a fresh chat. This one (@Wldd ) carries a lot of history and images into every follow-up, and longer requests are the ones most likely to time out right now
Switch to another model, such as Cursor Grok 4.5. Pick a specific one rather than Auto, since Auto can still route you back to Composer 2.5.
It’s already a chat with very less history. I think other chats in the same project might have contributed to this. Should I just add another folder for the same project and then continue there?
Is there any way to use composer 2.5 normal instead of fast mode in cloud?
Also, when using remote control, even if composer 2.5 is selected as preferred model, when controlling the chat via Android/ios, the model displayed is composer 2.5 fast in Android. Can you please confirm if fast/non fast is being used while using Android/ios remote control
