In the chat panel of Cursor IDE, using the @Branch feature automatically inserts the diff between the current branch and the main branch.
However, when chatting normally with the model right now, this content gets incorrectly auto-inserted on every turn, causing context usage to increase dramatically—roughly 15k per turn, so a few turns can exhaust grok-4.6’s context window.
Based on my previous experience with Cursor, the content of Cursor’s first conversation turn is also abnormally large. I suspect that Cursor auto-injects the git diff main content on the first turn, and under the bug in the current version, all turns now auto-inject this content.
My suggested changes:
Fix the bug.
Expose this behavior of auto-injecting the diff and provide an optional toggle, since it may not always match the user’s expectations.
Steps to Reproduce
in chat pannel:
send first any message with/without @branch (15k tokens conversation)
send next any message with/without @branch (31k tokens conversation)
Hey, thanks for the detailed report and for the link to the similar thread, it’s the same issue and we’re tracking it.
Quick version: the @Branch flag can get stuck on the conversation context. When that happens, the diff between your branch and main gets re-injected on every turn, so the context grows fast. Expected behavior is that the diff is only attached to the message where @Branch is actually added, and it won’t be re-sent after that.
What you can do right now:
Start a new conversation, this resets the persistent context, including a stuck branch diff.
If you see the @Branch chip in the current conversation, remove it.
A large context size on the very first turn around 10 to 15k is normal, system prompt, rules, project structure. It’s not related to this issue.
To confirm this on your case, please share the Request ID of the turn where you think the diff got re-injected. You can find it via the top-right chat menu > Copy Request ID. Then we can check what was included in the context.
I can’t share a fix timeline yet, but I’ll post an update in the thread when we have one.
Thanks, I grabbed all three Request IDs and passed them to the team so they can check what was in the context via our internal logs and confirm the diff was re-inserted on those exact turns.
While they’re looking into it, the most reliable workaround is to start a new conversation. That resets the persistent context, including the stuck branch diff. If you see the @Branch chip in the current chat, remove it.
We’re tracking this issue, but I can’t share an exact fix timeline yet. I’ll reply in the thread once I have an update.