Downgraded Grok 4.6 / Composer 2.5 environment inherits v4.7 regressions and 5x token bloat

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi everyone,
For the past 3 days, Cursor has been borderline unusable for me. Due to the recent regressions with Grok 4.7 and Composer, I decided to downgrade my setup to Grok 4.6 and Composer 2.5.Surprisingly, they are now exhibiting the exact same broken behavior. They fail at basic logic, ignore direct instructions, and act completely degraded. To make matters worse, my token burn rate has instantly multiplied by 5x. Even for minor, single-file edits, the dashboard shows an absurd amount of tokens being consumed per turn because of several fix-attempts staying into the same loop. Anyone else having these problems? Is this a systemic backend bug—likely related to broken context windows, looping system prompts, or server-side state accumulation?

Steps to Reproduce

Ask the llm for a simple fix, like adding an empty line to an menu helpfile. Comes with a solution that does not work. Tried another approach, new solution that also does not work. Overwrites code that worked properly. Does not understand anymore what you ask him while before it did.

Expected Behavior

Understanding like before what you asked for precisely. Do what you asked for precisely and leaving working code intact.

Operating System

Linux

Version Information

Version: 3.22.7
VS Code Extension API: 1.128.0
Commit: 37076c6c3f9e253c0fa2305197e45befd13a2260
Date: 2026-09-24T05:01:24.589Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 7.0.0-34-generic

For AI issues: which model did you use?

FIrst mainly grok 4.7, did not work, so downgraded tot grok 4.6 did not work, downgraded again tot composer 2.5 which was already not working great, but seems even dummer now…

Does this stop you from using Cursor

Yes - Cursor is unusable

5

At the moment, it seems to be performing very poorly again. I really hope this gets fixed soon and that a new Composer model will be released in the near future.

6

Hey @visserja72, thanks for the report!

I looked at your recent sessions. We haven’t changed the model, reasoning level, or prompts for Grok 4.6 or Composer 2.5, and your Grok 4.6 requests look the same as they did last week.

One thing that does stand out is chat length: each of your recent chats ran for roughly 90 to 370 model steps and filled the whole context window, so the earlier part of the conversation got summarized. Once that happens the model loses detail about earlier edits, and that’s usually when it starts repeating fixes or undoing code that already worked. Every step in a chat that size also re-sends the full history, which is where most of the token use comes from.

A few things that should help:

  1. Start a new chat for each task, even small ones like the help file change.
  2. Grok 4.7 now includes a 500k context window that might be worth trying out!
8

Does it really? Whenever I see my chat’s context get summarized mid-stream, the first thing the agent usually seems to do is regather itself by looking at the modified code (and likely the plan) and just continues on it’s merry way.

I never start a new chat for work being done for a specific plan. Same chat for the entire plan, no matter what and I’ve not seen any symptoms akin to “amnesia”. I have projects with lots of rules and skills, but nothing in those direct the agent on what to do after a summary occurs.