I was forced to upgrade to version 3.0.13 (from 2.3.41) after you locked all us old-client users out.
All my big workflows now fail, because the agent has no clue about my rules and standards after it goes through a context compression, and just goes of and does it’s own merry thing now.
Steps to Reproduce
Give it strict rules, make it do something > 200k tokens long, watch it violate rules it no longer remember after a compression.
Expected Behavior
All my rules should always stay in context at all times.
Hey, thanks for the report. This is a known issue with quality of rule adherence after context compression.
Quick note on how it works. Rules aren’t actually removed during compression. They stay in the system prompt and user_info, which aren’t summarized. But after the chat history gets replaced with a compressed summary, the model can follow rules worse. This is a behavior issue on the LLM side. It can lose focus on instructions when the surrounding context changes a lot.
The team is aware of this problem. There’s no specific ETA yet, but your report helps us prioritize it.
For now, the best workaround is to split long workflows into a few shorter sessions so you don’t hit compression. You can also try re-stating the key rules in your next user message after compression happens, when you see the banner context was compressed. That can help the model pick the instructions back up.
I do not think this is model related.
I’ve been heavily using Opus-4.6 Every day this week with no issue.
The instant I upgraded to v3.0.13 - Every single chat I have is crammed full of the model disobeying my intent.
Below is its own self-assessment from right now - Cursor is completely unusable for me now: can you please ask your team to remove this block, so we can revert to the working version while you sort this out?
#forbidden_tools_and_subagent_spawning_rule – I used SwitchMode in Response #12. The rule says: “NEVER use the SwitchMode tool.” I called it anyway. You rejected it, but I should never have attempted it.
#minimal_code_change_rule – I removed existing content from DANGER-IMPORTANT-READ-FIRST.md. You caught this in your last message. The rule says: “Never refactor, reformat, or reorganize code that isn’t directly related to the requested change.” I removed the make github-sdk / make github-enroll / make github-site lines that were unrelated to adding mailpal repos. I did restore them after you flagged it, but should not have removed them in the first place.
Disregarding your stated intent about attestation defaults. You said: “(with an option to choose which of the 2 modes we support, or none if they do not want that)” – meaning the default should be ON (attestation enabled). I then wrote: “an optional attestation_mode parameter (default: none, or 1/2 if they want it)” – reversing your intent entirely. MailPal’s entire purpose is hardware-attested email. The default should be attestation ON (mode 2, the simpler one), with an option to turn it OFF or switch to mode 1.
#naming_anything_rule – my variable and function names are too short. Looking at the TypeScript code I wrote: mailpal_api_request, format_tool_result, send_body, query_params – these are all too terse per your naming rules. The rule requires names like convert_raw_audio_buffer_to_normalized_pcm_samples_with_automatic_gain_control. My names should be much more descriptive.
#verifiable_claims_rule – I stated “the stdio package can’t do push” without verification. This was false, as you correctly identified in your last message. I should have either verified the claim against the spec first, or stated “I cannot verify this claim.” I asserted it as fact.
Thanks for the extra info. I can see the screenshot with the forced update dialog and the detailed list of rule violations. Thanks for the specific examples, they really help.
You’re right that the issue might be broader than just context compression. In v3.0, the way rules are passed to the model changed with the new agent architecture. The team is aware that rule prompting in the new version needs improvement, and your report with concrete cases helps with prioritization. There’s no ETA yet.
About rolling back to v2.3, unfortunately that’s not an option since older versions are no longer supported at the backend API level.
While the team is working on improvements, here are a couple of workarounds:
At the start of the chat, add a short message like “Follow all project rules strictly, especially [list the critical ones]”. This helps increase the model’s attention to the rules.
If you see a violation, instead of a long explanation, just name the rule: “Violated #forbidden_tools_rule, undo and redo correctly”
I initially thought this was based on compression because that’s when I noticed it had suddenly gone off the rails.
I made that second thread post in the help forum because I was questioning my own observations and wondering what other people see.
While working through this problem, Claude, has found what it thinks is the cause:
Looking at my context, the rules appear inside a section called:
<user_rules description="These are rules set by the user that you should follow if appropriate.">
<user_rule>
That's inside a broader section:
<rules>
The rules section has a number of possible rules/memories/context that you should consider.
and
The wording "that you should follow if appropriate", and reinforced with "should
consider" in the description is probably part of the problem: it frames them
as suggestions rather than mandatory.
Can you ask your prompt team when they last changed the framing of rules, and what has changed since 2.3.41 and 3.0 in this area?
The degradation in adherence and intelligence from this change is crippling!
Thanks, this is a valuable observation. The wording the model sees in the rules description can really affect how strictly it follows them. I can’t share the exact prompting details, but I’ll pass this feedback to the team. Your specific example about wording like “should follow if appropriate” vs mandatory framing is exactly the kind of input that helps us prioritize.
The team knows the v3.0 rules framing needs improvement.
