Is this a problem just me, or does Sonnet 4.6 seem really confused today? He doesn’t seem to remember what he just said, he seems really confused, and he contradicts himself: first he makes a point, and then in the next chat message he says the exact opposite. Did something happen?
Steps to Reproduce
Operate normally with AI
Expected Behavior
He should respond effectively and logically (without contradicting himself), just as he has done so far.
Hey, we checked the request by Request ID. Infra-wise everything looks good. The request reached Sonnet 4.6 and completed with no errors or timeouts. So on Cursor’s side there were no issues and no fallback to another model.
I don’t see similar recent complaints about 4.6 on the forum, so there’s no clear pattern. LLMs can get “stuck” inside a long thread. They may forget earlier context or start contradicting themselves, especially as the chat history grows. A few things that usually help:
Start a new chat instead of continuing the current one, that’s often enough.
If the task is long, split it into shorter sessions and provide key context explicitly, like files via @ and the exact code snippets.
If Sonnet 4.6 contradicts itself, quote its earlier message in the chat and ask which option is correct, this often straightens it out.
Try the same prompt on another model like GPT-5 or Gemini 3 Pro. If they give a reasonable answer, the issue was likely the current Sonnet session, not the model overall.
If you have a specific reproducible case (prompt + what it replied + what you expected), send it over and we’ll take a closer look.
Hi Dean,
after trying both Sonnet 4.6 and the new Opus 4.8 I can say that they seem to work quite well, it seems to me, however, that they often avoid reading the rules e.g. rules.mdc (which they should always read) because they make mistakes that if they had read and followed the rules they would not have made.
Glad that 4.6 and Opus 4.8 are behaving more reasonably now.
By the rules, whether rules.mdc gets read automatically depends on its frontmatter:
alwaysApply: true means the rule is always injected into the context, so the model sees it in every request.
globs: ... means the rule is pulled in when there are files in the context that match the glob.
Only description (Agent Requested) means the rule isn’t injected right away, and the model decides on its own whether to pull it in. This is where it can end up skipping it.
If you want the rule to apply every time, make sure it has alwaysApply: true set, not just description. More details on rule types: Rules | Cursor Docs
So I can check more precisely, please send:
The frontmatter of your rules.mdc (the first lines between ---)
A short example where the rule should’ve applied but the model ignored it
Here’s an example: I have two versions of my software (in the same project), and the AI often confuses features that belong to one version rather than the other, even though they’re specified in the rules.
Maybe it also depends on how many rules there are in the rules.mdc file? Mine has 200 lines—is that too many? Is there a limit I shouldn’t exceed?
Thanks for the example. Your frontmatter looks fine. When you set alwaysApply: true, the rule is injected with priority into every chat, no matter what you put in description and globs, so it really does get into the context. There’s no conflict between these fields.
About length. There’s no hard limit, and rules don’t get trimmed. 200 lines isn’t “too much” formally, but a big always-applied block can dilute the model’s focus. The more instructions are always sitting in context, the easier it is for the model to miss or mix things up. This is especially true in your case with two software versions in one project.
What usually helps in this situation:
Split the rules into a few files instead of one big one. Keep general stuff in alwaysApply: true, and move version-specific details into separate rules with globs that target the files or folders for that version, like globs: "v1/**" and globs: "v2/**". Then the model only gets the relevant rules for the current code area, and there’s less confusion between versions.
Keep the always-applied rule short and specific. Include only the most critical invariants, not everything.
To confirm the rule is actually being pulled in, check the chat. Enabled rules show up in the request context. If a rule with alwaysApply: true doesn’t appear in the context at all, it might be that bug from the thread I linked earlier. Let me know and we can dig in.