Auto-summarization not performed in some cases?

[jrista (Jon)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’ve been running into an issue occasionally, but I think for quite some time, spanning many versions of Cursor. I only recently realized what was happening, I guess, and started manually forcing summarization, which resolved the issue.

In some cases, when context usage is around 70% or so, if I issue a prompt that is big enough (I don’t know the exact threshold, and it may in fact be variable), and it doesn’t necessarily take a “big” prompt, just one that surpasses some number of tokens that triggers the issue, then auto-summarization does not occur, and the agent/model do not process the request.

The prompt will initially issue…the agent and model will do some work for a little while, then suddenly the prompt is returned to the prompt editor and the agent reverts back to the last work it did before issuing the new prompt. The agent does not actually handle the new prompt or do any additional work.

I was not sure why it was doing this at first, and I checked status for Cursor, Claude, Grok, etc. No outages reported, and the issue was persistent. I then decided to manually trigger summarization, even though only about 70% of the context space was used (or at least, SO REPORTED…I posted a bug report not too long ago that noted the available context space for each model in the context usage indicator tooltip was not being reported properly for all models, at least, many models showed a lot less context space available than they were supposed to have). Once that manual summarization completed, I was able to continue my chat.

I do wonder if this issue may be related to how context space is USED and REPORTED, as there seem to be some discrepancies there that are inconsistent throughout the Cursor UI. In any case, it does appear to be a bug, and the reason why the prompt won’t actually issue and be handled by the model is unapparent given the way the UI actually behaves when this issue occurs.

It is not a particularly frequent issue, I don’t know exactly why it occurs, so I am not really sure of how to reproduce.

Steps to Reproduce

Specific steps unknown. Seems to be related to available context space, used context space (and the ratio therein), and prompt size. I suspect there is just some small window of prompt size vs. remaining context space available, that likely results in the issue occurring. I also suspect those things are variable, and depending on the prompt size and remaining context window space, the specifics are probably dynamic.

Expected Behavior

If a prompt is issued that would overrun the context window, auto-summarization should kick in.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.1.34
VSCode Version: 1.105.1
Commit: 609c37304ae83141fd217c4ae638bf5321856500
Date: 2025-11-25T16:35:52.391Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.0.0

For AI issues: which model did you use?

No specific model, has occurred with Opus, Sonnet, Grok, Composer 1, but is infrequent.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[deanrie]

Hey, thanks for the detailed report. This looks like a bug in the auto-summarization logic.

To help the dev team diagnose it, could you share:

1. Request IDs from failed attempts - when the prompt bounces back to the editor, use the chat context menu (top-right) > Copy Request ID
2. Console logs - when it happens again, open Help > Toggle Developer Tools and check the Console for errors

Also, try to estimate the token count in context when it occurs (hover over the context indicator in chat).

I’ll pass this to the team so they can investigate the auto-summarization issue. As a temporary workaround, keep using /summarize manually when you notice the context is about 60-70% full.

[jrista (Jon)]

Is there a way to get an estimate of the number of tokens the current prompt (being edited, not yet issued) is going to require? I guess that’s not a current feature, but, it might be helpful to have something like that. Especially when working with data, sometimes its hard to tell if a data file or something is going to be too large to fit the available context left in the window or not.

[deanrie]

Thanks. Right now, Cursor doesn’t have a built-in token count for an editable prompt before sending. I’ll take this as a feature request - it’s a useful idea.

For now, you can:

• Watch the context indicator and at around 60-70% manually run /summarize
• Split large inserts into parts or reduce the data before sending

[jrista (Jon)]

I haven’t run into the issue again yet. IT was rareish before.

FWIW, it is not necessarily “large” inputs that cause the problem. IT is more likely that they do, but, depending on exactly how much context window is free, when the next prompt is issued, it doesn’t necessarily take a large prompt. I have even seen this occur with 1-2 liners as well, although that has only happened a few times. Usually its a paragraph or two, roughly, in size, and then I guess it can depend on the size of any attached context (whcih again, doesn’t necessdarily have to be large…although, without the ability to explicitly attach code via identifiers (this was lost with 2.0), I am having to always attach full files, which may be leading to a slight increase in the frequency of this issue.)