Repeated connection issues sometimes coinciding or followed by a terminal crash.
Side effect of any text input being blocked. Starting voice typing sometimes allows text input temporarily one prompt at a time. New agent session is needed to resolve which loses previous session data.
Steps to Reproduce
-Seems to happen towards the end of complex agent sessions with near max token usage.
-Happens primarily with http2 but also reproduced after downgrade.
-No VPN, No internet connection issues.
Expected Behavior
Connection should be stable.
Terminal should not crash.
Exisiting agent session should recover and be functional.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Sonnet, Opus
Seems to happen more with claude models but also happens with gpt and gemini
Additional Information
This issue is incredibly frustrating because I lose a ton of progress towards the end of complex agent sessions and the system seems to refund the single disconnected prompt only. However, a lot of the prior tokens used in the session are therefore wasted since a new session with all the same fresh context is required. This issue is costing me both significant time and token spend. I believe because I was only doing light development work previously that I wasn’t running into this. But now that I’ve shifted to doing daily development off of a max plan this issue is making the workflow and cost become unsustainable. Note this is on my own cursor individual license, I also have a separate cursor license at my primary job as a SWE and I’ve only occasionally had connection issues due to VPN with none of the side effects I experience here.
Continue or Try Again buttons do not seem to function during this error. I can close the connection warning via x and sometimes send an additional prompt but it auto cancels any additional work immediately and usually retriggers the connection warning. Additionally I often cannot type in the text input box of the errored agent session.
A restart of Cursor will sometimes reset the text input and also sometimes allow one or two prompts to go through but then often re-triggers the connection error. I avoid doing that because it’s an unstable state.
My general work around is to both restart cursor and start a new agent session and feed it some of the previous context from the errored session.
I have not tried to feed it an entire transcript, I can try that, although most of my sessions seem to have transcripts in the 10’s of thousand line range so idk how well that will work compared to what the errored session had indexed. Of course, re-analyzing the prior transcript also has usage overhead which costs very real dollars pretty quickly over many sessions.
I do try to start new sessions for new components and this does happen with average size sessions ~1-5k lines of code written.
I will send a request_id and screenshot on the next error.
With http/2 it was happening every other session.
With http/1.1 it was happening approx every 5.
Although that could be coincidental.
In terms of usage billing regarding errored requests; should these be marked as errored?
After reviewing my usage I don’t see any recent errored requests even though I have had many connection errors for requests in the last ~2 weeks. I do see a couple older ones.
On the usability front I’m pretty frustrated because at this point I’ve used almost all of my Ultra usage limit with ~2 weeks left in the cycle and the session switching and restarting costs a very significant loss in usage credits and development time; easily double digit percentage wasted even with reusing previous chat history.
Thanks for the detailed follow-up and for trying http/1.1.
The behavior you’re describing - input blocked, Continue/Try Again not working, session becoming completely unusable - aligns with known context overflow issues the team is actively working on.
Regarding billing for errored requests: Errored requests should show in your usage dashboard. If you’re not seeing them, there may be an issue with how these specific errors are being tracked. When you get the next connection error, please send: