Stopped Chats Continue to Use Tokens and Try to Access Resources

[Leland_Hepworth]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

This bug happened after/while I was encountered the bug described in this other bug report:

To-dos Selected Build in New Agent Not Using Selected Model to Build this Plan

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug I built a plan using Opus 4.5, and I want to build individual To-dos with Sonnet 4.5. However, when I build the To-do, Opus 4.5 is used. I’m unsure if this is because Opus was the model used to create the plan, and I won’t test other combinations, due to tokens being wasted. Steps to Reproduce Build a plan using one model (i.e. Opus 4.5) At the top of the plan document, change the “Model used to build this plan” select…

It involved building a todo item in a new chat. When I saw that the chat had been created using Opus instead of Sonnet, I stopped the chat. I checked my usage and only about 20k tokens had been used on the Opus chat. I tried switching the model to Sonnet to see if I could do that as a possible workaround, but after that I didn’t try re-submitting the initial prompt yet. I left That Cursor chat open and idle while I went to write that other bug report. After a while I noticed attempts to fetch from websites and a terminal command prompt were in the chat. There was no other output text in the chat window, and I later verified that no files in the codebase were edited. I checked my usage, and that Opus chat’s token usage had grown to about 600k. I deleted the initial prompt and entered “stop” in the Sonnet prompt. That prompt processed, and afterward the Opus chat’s token usage stopped growing, although it’s unclear whether that was the reason for the stop or something else.

Steps to Reproduce

It’s unclear whether this was an intermittent issue specifically related to building todo items or if it could happen when stopping any chat, and I’m not willing to waste more tokens testing it further. But here are the steps I took:

1. Build a plan using one model (i.e. Opus 4.5)
2. At the top of the plan document, change the “Model used to build this plan” selection to something else (i.e. Sonnet 4.5).
3. At the bottom of the plan, click the bubble next to one or more To-Do list item(s) to select those item(s).
4. Click the “Build in New Agent” button at the right of the To-Do section header.
5. The selected To-Do(s) are built in a different model (in my case, Opus 4.5)
6. Immediately stop the chat.
7. Check prompt token usage to get an approximate baseline usage at around the time the chat was “stopped.”
8. Change the model (I’m unsure if this step is relevant or not)
9. Wait and see the chat trying to fetch from websites or use terminal commands.
10. Check the chat token usage to see a significantly higher number of tokens used.

Expected Behavior

Stopping a chat ends token usage. The previous prompt re-enters the text entry area, and I shouldn’t see any output appearing above it, including attempts to fetch from websites or use terminal commands.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 2.4.27 (system setup)
VSCode Version: 1.105.1
Commit: 4f2b772756b8f609e1354b3063de282ccbe7a690
Date: 2026-01-31T21:24:58.143Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26100

For AI issues: which model did you use?

Opus 4.5, unfortunately

For AI issues: add Request ID with privacy disabled

Can’t disable privacy mode on company team account

Additional Information

When I entered the Sonnet “stop” prompt, the timed-out and therefore skipped fetch prompts remained, but the ones that were still pending approval, as well as the approval prompt for the terminal command disappeared. See screenshot attached for the final state of that chat.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[liquefy]

Sometimes, when for example a command is running in chat and you click stop, it does not stop the chat, but just the command, but chat continues. Try to check that when you stop the chat, that in the prompt window it is actually stopped, it might still display it is running. Not sure this is your case, but it fooled me once or twice.

[Leland_Hepworth]

@liquefy I don’t think that’s the case for me, but good to check. When I pressed the stop button, I got back the chat prompt input with the auto-generated prompt that Cursor make when it kicks off the selected to-do build in new chat action. Being returned to the input text box also meant that the stop button turned back into the submit button, so that was no longer an option to stop the execution. That’s why I tried submitting a prompt that just said “stop”, thinking this new prompt’s execution might override the previous prompt which was still executing in that agent.

[deanrie]

Hey, thanks for the detailed report and screenshots. This is definitely a bug. Stop should fully stop execution, not just reset the UI.

The team is aware of the Stop button issue, especially with terminal and browser actions. Your case helps a lot. I forwarded it to the team with the details about plan mode and the “Build in New Agent” scenario.

For now, if you hit this again:

• Fully close the chat (Ctrl+W on the tab), not just Stop
• Check the Usage dashboard right after you press Stop, so you can catch it if usage keeps going up

Let me know if you can share a screenshot from the Usage dashboard. It will help the team understand the token growth pattern.

[Leland_Hepworth]

@deanrie

@deanrie

Let me know if you can share a screenshot from the Usage dashboard.

These are the Opus and the the Sonnet prompt inputs mentioned above.

[Leland_Hepworth]

@deanrie I had this issue happen again. Like last time, I was building a single todo item from a plan. I clicked the stop button, then used Ctrl+W to close that chat in the chat pane, which automatically opened my next most recent chat in the pane. I monitored the chat’s usage and saw that it continued to grow:

Once it looked like the usage had stopped going up, I tried building that todo item again. After the chat started, I noticed that in the agent panel, the first agent had a question mark next to it. So I tried clicking on it to see what it was doing, but that froze the Cursor instance:

Once I closed and re-opened Cursor, the second agent had stalled out while doing its initial thinking. So I started a third agent and let it run. Here is the usage of all three agents:

Note that the bugged first agent used more tokens than the third agent that actually completed the task. My theory on this is that the bugged chat tries to use tools that it no longer has access to, such as reading or editing code files. It then tries to achieve its goal through other means, probably continuing to find issues and roadblocks along the way, which require further workarounds and more tokens.

Here’s the final state of the first chat:

Again, there’s evidence that it’s trying to fetch from websites. The third chat did not need to do this; all the relevant information could be found in the plan and related code files.

---

It’s a little bit of a side note, but how do the used tokens on the usage page compare to the used tokens in the chat’s context?

Here is a screenshot of the context used in the third chat:

It’s a little tricky because the auto model is being used so we don’t know which actually model is used. But even if we assume it’s the model with the largest context window, that’s 272k tokens. 21.5% of that is under 60k tokens, but the usage page indicates that about 350k tokens were used on that chat. Notably, that many tokens would require the chat to be summarized to fit in the context window, which it never did in this instance.

[Leland_Hepworth]

@deanrie Do you have any update on this issue? I haven’t experienced it since, but I’ve been deleting chats I need to stop. It would be nice to know whether or not this issue has been resolved, so that I don’t need to worry about working around it anymore.

[deanrie]

Hey, thanks for the follow-up.

Honest update: the bug is tracked and the team knows about it, but there’s no ETA for a fix yet.

Since you mentioned the workaround of deleting chats helps, that’s still the most reliable approach right now. Based on what you saw on Feb 6, closing the tab with Ctrl+W alone doesn’t seem reliable.

A couple of quick questions:

1. What version are you on right now? There have been a few updates since 2.4.27, and I want to confirm whether this still happens on a newer build.
2. If it happens again, please try to note the exact timestamps so the team can match them to the server logs.

If I hear any updates, I’ll reply here.

[Leland_Hepworth]

@deanrie

What version are you on right now?

Version: 2.5.26 (system setup)
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100

I’ve been keeping up with the updates available in Help > Check for Updates…

@deanrie

If it happens again, please try to note the exact timestamps so the team can match them to the server logs.

I’ll let you know if anything happens, but deleting the chat seems to be working around it, so I’m not seeing the chats continue to grow in usage afterwards. And I won’t intentionally try to trigger the bug without the workaround, as that costs me in usage tokens.

[Leland_Hepworth]

It’s been almost 22 days since the last reply, so I’m commenting to keep the bug report open. Are there any updates on whether or not this has been resolved? It would be nice to know so that I we don’t have to be so mindful about working around the bug to avoid wasting tokens.

[deanrie]

Hey, thanks for the ping. I get that it’s annoying to work with a workaround for this long.

Honest update: the bug is logged and the team is aware, but there’s no concrete timeline yet. I added your follow-up to the report to help with prioritization, especially since this is actually costing tokens on a Team account.

A couple questions:

1. What version are you on right now? There have been a few updates since 2.5.26, and there were fixes to the stop behavior. I want to check if this still reproduces on the latest version.
2. If you update and try without the workaround deleting the chat, let me know if anything changes. I get that testing is risky because of token usage, so no pressure.

For now, deleting the chat instead of using Stop is still the most reliable option.

I’ll update here if there’s any news from the team.

[Leland_Hepworth]

Version: 2.6.21 (system setup)
VSCode Version: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Date: 2026-03-21T22:09:10.098Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100

And I was mostly replying to keep this post open, as your forums would automatically close it after 22 days of inactivity.

[zahrevsky (Vlad Zahrevsky)]

It seems that I have encountered the same bug.

In my case, after clicking the Stop button, the output in the chat completely stopped, but the agent was still editing code files and executing commands in the console.

The agent executed several commands in the console, and during all this time, I couldn’t stop it in any way other than closing the Cursor completely. There was no indication in the chat window that the agent was working.

Version: 2.6.22 (Universal)
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

[Leland_Hepworth]

I may have encountered this error again. I had just started an agent that would run a long process, and I wanted to use the new fork session feature to duplicate the chat to re-use the initial context setup and start drafting a new prompt to work on a related feature so that the prompt was ready by the time the first agent finished. I was surprised when I saw the forked session was in the same place as the first agent; I assumed it wouldn’t copy the in-progress work; we don’t want two chats working on the same task. So I stopped and deleted the second chat, but I couldn’t stop Cursor because my first chat was still processing. But after being deleted, that second chat kept re-appearing in the agents list. If I clicked on it, the chat was blank, and I could delete it again, but it kept re-appearing. There’s an issue in the Cursor usage page right now, so all chats only display that they are using 0 tokens, so I can’t track the second chat to see if it is still active.

Now that I the first chat has finished, I tried restarting Cursor. The chat doesn’t seem to be appearing within that running Cursor, but when I restart Cursor again the second chat re-appears again.

[Leland_Hepworth]

That chat kept reappearing, and I ended up archiving it, although I’m unsure if that resolved its reappearance or if the model was finally done outputting.

Now that the Cursor usage page is properly showing tokens, here are the results for those two chats, with the bottom one being the original session, and the middle one being the forked session that was immediately stopped (the top one is unrelated):

The significantly larger token usage, high in cache read, is the sign that the model continued to try to troubleshoot its situation, even though the session was deleted in Cursor.

[Leland_Hepworth]

Responding to keep the post open.

There have been a few more times since I last posted when a stopped and deleted chat keeps re-appearing and keeps using tokens, but I was unable to stop Cursor because another chat was still running.

@deanrie do you have any updates on this?

[deanrie]

Hey Leland. Thanks for keeping the thread active and for the detailed reports on the forked session. That’s a helpful new signal, and I’ll add it to the existing report.

To be honest, we’re tracking the bug, but I can’t share a specific ETA for a fix yet. Related cases like hitting Stop during background work and zombie chats after deleting or forking are on the team’s radar, but they touch different code paths, so we’re fixing them step by step.

A couple quick questions to strengthen the report:

1. What version are you on right now? Starting in 2.6.22 we changed some Stop behavior, so I want to confirm if this still reproduces on the latest build.
2. For the forked session case from 09.04, do you have the exact time down to the minute when you forked and then deleted or archived it? That’ll help the team pull server logs and see what kept sending tokens.

For now, the workaround is the same: delete the chat instead of using Stop, and archive it if it keeps reopening. If I get an update on the fix, I’ll post it here.

[Leland_Hepworth]

@deanrie

What version are you on right now?

I just updated to the latest version, and I’ve been staying up-to-date pretty much every weekday with what’s available.

Version: 3.2.21 (system setup)
VSCode Version: 1.105.1
Commit: 806df57ed3b6f1ee0175140d38039a38574ec720
Date: 2026-05-03T01:46:14.413Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

@deanrie

Starting in 2.6.22 we changed some Stop behavior, so I want to confirm if this still reproduces on the latest build.

My reply from 25 days ago noted a change in the behavior, possibly making things worse. To reiterate, a chat that was stopped and deleted would re-appear in the agent list. Even restarting Cursor did not immediately eliminate this behavior. I ended up archiving it instead of trying to delete it again, but I’m not sure if that stopped the behavior or just masked it. And due to the issue with the Cursor Usage page at the time, I couldn’t see if the chat increased token usage over time. Notably, because something was adding that agent back to the agents list even after being deleted, that may mean the workaround no longer works.

@deanrie

For the forked session case from 09.04, do you have the exact time down to the minute when you forked and then deleted or archived it? That’ll help the team pull server logs and see what kept sending tokens.

Like I said previously, it’s the middle chat in the screenshot in my recent reply. So that would be April 9th at 9:11 AM US Mountain Time (so 3:11 PM UTC). That was the time the forked chat was created. I would have stopped and deleted it shortly after, but it kept popping up and I kept deleting it. I’m not sure when I was finally able to restart Cursor, see that the behavior persisted, and ultimately archive the post.

[deanrie]

Hey, Leland. Thanks for the version update and the timestamp. That’s exactly what the team needs to match it up with the server logs.

A couple notes:

On the reappearing chats after deletion case from 09.04: this looks like a separate issue from the original Stop bug, and a fix for it went out recently. In 3.2.21 build 03.05 the fix might not be included yet, so if you see it again on the current or a newer version, tell me right away and I’ll file it separately. If it stops reproducing after a couple updates, that’s also good, let me know.

On the original Stop bug: no progress yet, so I can’t share an ETA. The workaround of deleting the chat is still the best option for now. I know it’s annoying to rely on a workaround for this long, especially when it involves real tokens on a Team account. I’ll post here as soon as I have any update on the fix.

One small request: if the reappearing symptom happens again on 3.2.21 or later, please try to screenshot the agents and Usage at the moment it happens. No need to force it, only if it happens on its own. This will help us confirm whether it’s the same bug or a new regression.

[mohitjain (Mohit)]

Hey @Leland_Hepworth,
We’ve shipped a number of updates recently that would have likely addressed this. If you’re still running into it on the latest version of Cursor, please create a new thread with:

• Your Cursor version (Help > About)
• Your OS and version
• Steps to reproduce

That way we can investigate with fresh context. Going to close this one out for now.