Rapid usage consumption + chat crashes/restarts (possibly related)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’m experiencing an issue with Cursor and wanted to check if anyone else has seen this or knows what might be causing it.

Issue 1: Rapid usage consumption

My Pro+ usage (60$ plan) is being consumed much faster than expected — I reached around 35% within just a couple of days of normal usage.

Issue 2: Chat instability / crashing

I also noticed that in some cases the chat:

“thinks” for a long time
then appears to crash or reset
and restarts the response from the beginning
Possible connection

I suspect these two issues might be related — especially if the repeated retries or restarts are causing multiple model calls or duplicated requests

Steps to Reproduce

What should I write Steps to Reproduce?

Operating System

Windows 10/11

Version Information

Version: 3.8.11 (system setup)
VS Code Extension API: 1.105.1
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
Date: 2026-06-18T01:40:18.333Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Opus 4.8

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Anyone? It’s urgent!

8

hi @hartkhartk Thanks for the forum post. I took a look at your account and I see that about 63% of your usage consumption this far has been Opus 4.8 thinking high. Opus 4.8 is one of the most expensive models so this means that will consume your included API usage more rapidly than other models.

The second thing that I noticed is that about half of your usage came from just 3 conversations. When you let conversations run long, this bloats the context window and increases the costs of these conversations. It’s best to keep context windows fresh (light) both for performance and for cost reasons. If you can start new chats more frequently (e.g. all the time, start a new chat whenver you can) you’ll notice that your usage won’t be increasing as rapidly.

Additionally, auto and composer usage, of which you have some usage of composer, is a completely separate pool from API usage. So try to use that where possible.

9

For Chat thinking then restarting: This sounds like a client-side reconnect, not duplicated billing. Requests that error out or never complete are not charged, and I confirmed there’s no pattern of duplicated charges on your account.

To make sure everything looks good with your network settings go to Cursor Settings > Network > Run Diagnostics. If something fails there please let us know what fails (attach error message).

If you have a flaky wifi connection you can try toggling the VPN or switching to mobile hotspot to pinpoint a possible network issue with your internet connection.

10

@kevinn
I contacted support and the email bot claimed it was a bug.

11cd7798-a019-4b1f-bdbd-5fe51eb9b1a6

The request ID shows the crash was a server-side error where the conversation’s state failed to persist correctly. Starting a new conversation (Ctrl+N on Windows) resets this and should prevent it from recurring. If you see the same issue in a fresh conversation, send a new request ID and I’ll investigate further.

On the usage: Claude Opus 4.8 with extended thinking is one of the most token-intensive models available, so it depletes included budget significantly faster than standard models. To see exactly what each request cost, check the “All Events” table at https://cursor.com/dashboard?tab=usage – each row shows the model and per-request cost breakdown.

Let me know if you need anything else!

Best,

Sam

Cursor’s AI Support Assistant

100d6156-1006-42eb-a015-13f17a3d1944

Hi Israel!

The new request ID shows the same server-side failures: the backend failed to persist checkpoints while tool calls were in progress (“Write failed during flush”, repeated), causing the tool calls to abort. All Cursor systems are currently operational with no active incidents.

Since this is happening in a fresh conversation too, could you try switching to a different model (e.g., Claude Sonnet 4 or Composer 2.5) and reproduce the same task? If the crashes stop, it points to something specific about Opus 4.8 triggering these write failures. If they keep occurring with other models as well, let me know and I’ll escalate this to our backend team for deeper investigation.

Best,

Sam

Cursor’s AI Support Assistant

7d821338-bf83-426a-8d6b-e2c4e5209b58

Hi Israel,

I wasn’t able to retrieve any backend data for this request ID.

Could you let me know which model this crash happened with? If you tried switching to a different model (like Claude Sonnet 4 or GPT-5.5) and it’s still crashing, that points to something broader worth escalating to our backend team.

Best,

Sam

Cursor’s AI Support Assistant

bdb331a1-d64f-4c17-b60d-2608096f3b4a

I’ve forwarded the request IDs and all context to a teammate who can dig into the backend failures more deeply. They’ll get back to you as soon as possible!

Best,

Sam

Cursor’s AI Support Assistant

11

@kevinn And if this is true then it also means about the high usage
that each such attempt is a new request to the model
with the same context over and over
that is:
the same thing that failed once — can be counted 2–4 times usage
Can you check if the content of the requests is repetitive?

12

Hi @hartkhartk You were not charged for these failed requests that you’ve shared the request IDs for.

The support bot was not quite on responding to the error, but since you’ve opened a ticket you’ll get another Cursor employee to double check that.

Did you have a chance to do the Networking troubleshooting in Cursor Settings? Cursor Settings > Network > Run Diagnostics.

13

@kevinn I use NetFry internet filtering
and this is apparently a problem with them
I sent them a request

14

Thank you for following up!