Detailed Analysis
A Reddit thread posted to r/Anthropic surfaces a user complaint that has become increasingly common in AI communities: a perceived regression in usability when a newer model version replaces an older one, even as the newer version is presumably marketed as an improvement. The poster describes a specific behavioral divergence between "Sonnet 4.6" and "Sonnet 5," claiming that identical custom instructions, project setups, and stated user preferences are interpreted very differently by each model. According to the account, Sonnet 5 frequently flags legitimate customization attempts as jailbreak attempts, prompt injections, false-authority claims, or manipulation tactics, while Sonnet 4.6 processes the same inputs without friction and generates the requested output. It is worth noting that neither "Sonnet 4.6" nor "Sonnet 5" corresponds to Anthropic's official public model naming conventions (which have used designations like Claude 3.5 Sonnet, Claude 3.7 Sonnet, and Claude 4/4.5 Sonnet), so this post may reflect either informal community shorthand for specific model snapshots, a beta/preview build, or speculative naming — but the underlying phenomenon described is a recognizable and recurring pattern in how Claude models are perceived to evolve.
The core issue raised — models becoming more prone to false-positive refusals or misclassifying benign requests as adversarial — is a well-documented tension in AI safety engineering known as the "overrefusal" problem. As foundation model developers tune models for stronger resistance to jailbreaking and prompt injection, there is an inherent risk of collateral damage: legitimate power users who rely on system prompts, project-level instructions, or persona/style customization can get caught in the same net designed to catch malicious actors. The poster's distinction between "leniency" and "flexibility" is analytically sharp — they are not asking for weaker safety guardrails, but for better semantic discrimination, so the model can distinguish between an actual social-engineering attempt and a user simply writing detailed, technical, or emphatic instructions. This is a hard classification problem, since the same surface-level features (authoritative tone, structured formatting, persistent reminders) can signal either a legitimate power-user workflow or an attempted manipulation, and a model erring toward caution will inevitably misfire on some fraction of legitimate cases.
This tension matters because it sits at the heart of Anthropic's stated mission and market positioning. Anthropic has built its brand around Constitutional AI and being the "safety-first" lab, but its commercial success with Claude — particularly among developers, power users, and enterprise customers building on the API — depends heavily on the model being steerable and predictable under custom system prompts. If each new model generation tightens safety classifiers in ways that degrade instruction-following fidelity or increase false-positive refusals, it directly undermines the reliability that professional and technical users depend on, potentially pushing them toward competitors like OpenAI's GPT models or Google's Gemini, which face similar tradeoffs but calibrate them differently. Community threads like this one function as informal signal-gathering for Anthropic, and historically the company has responded to vocal user feedback about overrefusal (as seen in past adjustments following criticism of excessive caution in earlier Claude versions).
More broadly, this post reflects a recurring pattern in the lifecycle of large language model deployment: each new model version resets user trust and requires re-learning of its behavioral quirks, and "upgrades" are not universally experienced as improvements, especially by users with established custom workflows, prompt libraries, and system instructions tuned to a prior model's tendencies. The suggestion that mass user feedback could "steer" Anthropic's calibration reflects a broader trend of AI labs increasingly relying on real-world usage signals, red-teaming, and community reporting to fine-tune the balance between safety and utility — a balance that remains one of the most persistent and unresolved challenges in production LLM deployment, and one that will likely continue to generate friction as models grow more capable and safety systems grow more aggressive in tandem.
Read original article →