Terrible, no-thinking results using ''Cursor Grok 4.6 Extra High''

Discussions
1

One example: I’m working on a browser extension that summarizes NYTimes ‘Opinion’ articles. It made a change, and I asked it to show me the new results. It answered by copying an earlier result that it found in the chat history.
I’d appreciate any suggestions on how to ensure that stupid reasoning doesn’t take place.
A transcript is available

3

Hey, thanks for the feedback. What you’re describing, where the agent pulled an old answer from the chat history instead of rerunning the task, usually happens when there’s a lot of context in the chat and the model “grabs onto” a previous result.

A couple things that help:

  • Start a new chat for the specific task. The longer the session, the higher the chance the model will mix old and new context. A fresh chat almost always gives a cleaner result.
  • Be explicit: “rerun it and show the actual output, don’t reuse the previous result from the chat.” A direct instruction noticeably reduces this behavior.
  • For tasks where fresh data matters, like your article parsing, ask the agent to run the action or script first, then show the real output, not a summary.

On the reasoning quality in Grok 4.6, I’ve shared your feedback with the team. If you can include the Request ID from the request where the agent reused the old result right side top of the chat menu > Copy Request ID it’ll be easier to look into that specific case.

Let me know if switching to a new chat helps.

4

Thanks, Dean. You’re doing a great job of handling a deluge of problems.
Look at
1ca73439-b9a7-45cd-9aed-bd2450da9191
3542dd69-7ea0-440b-a149-e82be9825104

I already had this rule:
Your existing user rule (“History is not state… recompute or re-read”) is exactly the missing enforcement Grok skipped;

But it didn’t make any difference. So now I also have:

a repo .cursor/rules/ file that names ASC API + Xcode plist + “never grep transcripts for factual answers” would make that default for Nunus work.

Starting a New Chat did indeed help.

Thanks,

Allen

9

Thanks, Allen. Those Request IDs cleared everything up.

Here’s what happened. Your chat got so long that Cursor collapsed the early history into a summary, about 20 minutes before the request you pointed out. When that happens, the agent is told where the full saved chat transcript is, so it can restore context it can’t see anymore. In your case, the model went into that transcript, found older article summaries, and returned them instead of re-running the extension. So it treated the transcript as a source of a ready-made answer, not as background context. That’s why the same request worked correctly in a new chat. There was no collapsed history there, so there was nothing to “peek” at.

This isn’t intended behavior, and it isn’t anything in your setup. I shared both Request IDs with the team, including the fact that the model went to the transcript even with your rule “history is not state”.

What works best for now:

  1. Stick with your approach, start a new chat for each “show me new results” check.
  2. If you stay in a long chat, phrase it as an action: “Run the extension on this article right now and paste the exact output you get. Don’t take anything from earlier in this chat.”
  3. Your repo rule “never grep the transcript for factual answers” is a good extra guardrail, and it should help with the remaining cases.

Let me know if this shows up again in a fresh chat, and include the Request ID if it does.