I am experiencing a persistent issue where my request fails unexpectedly. When I execute the request, it seems to run normally for a while, but then suddenly pops up an error and fails to complete. I have manually retried the exact same request 3 times, but it consistently breaks after processing for some time.
Could you please help me check the backend logs using my Request ID to see what went wrong?
Could you please help me look into the backend logs to see what went wrong?
Request ID:
1a1fa8d9-f1aa-459c-ad45-9395366e582f
Steps to Reproduce
I have manually retried the exact same request 3 times, but it still fails every time without a proper output.
Hey, thanks for the report. With just one “An unexpected error occurred,” it’s hard to say the exact cause. If it crashes after some processing time, it often points to either a request that’s too big or taking too long, or a network drop. Let’s narrow it down:
Does the error still happen if you switch to another model, like Sonnet or Composer? That’ll tell us if it’s specific to Opus 5.
Try the same request in a new chat. If the current thread has built up a lot of context, that can cause a drop.
Check your network: Cursor Settings > Network > Run Diagnostics. If you’re behind a corporate proxy, VPN, or Zscaler, go to App Settings Ctrl+Shift+, then search HTTP/2, turn on Disable HTTP/2, and try again.
A couple questions so we can dig deeper:
When does it fail, right away, on a large response, or after starting a tool or terminal step?
Is it a request with a lot of context, like many files or a long chat history?
Let me know what helps, and exactly which step the error happens on.
Thanks for the details, they really help clear things up.
I checked the Request ID. The request reaches the backend and streams normally for about 5 minutes, then the connection drops almost exactly at the 300 second mark. This is not really about Opus 5 itself. It is just that its longer turns with a bigger context take more than 5 minutes, so they hit this cutoff. Shorter Composer turns finish within the window. A clean cutoff at around 5 minutes points to something on your network path like a VPN, proxy, or corporate middlebox timing out long lived connections.
What to try:
Cursor Settings > Network > HTTP Compatibility Mode, switch it to HTTP/1.0. This uses long polling, avoids long lived streams, and usually fixes this kind of drop.
If you are on a VPN, try a different node or try connecting without the VPN. Your results correlate directly with the egress path.
Cursor Settings > Network > Run Diagnostics, and we can see what it reports.
Update Cursor. You are on 3.5.33 from May 2026. There have been a few improvements since then around retry and resume for streams that help in cases like this.
As a temporary workaround, split very long tasks into shorter turns so they fit within the 5 minute window.
Start with step 1. In your case it is the most likely to fix it. Let me know if it helped.