DeepSeek V4.1 Flash refusals reportedly cut from 81.6% to 4.3% across 838 prompts

Imagine buying a safe and discovering that its combination lock can be removed with a screwdriver in a single evening. That is roughly the picture painted by a viral X post about DeepSeek V4.1 Flash. The author says someone removed most of the model's refusals using OBLITERATUS, a free, open-source tool released by Pliny.

What exactly is being claimed

The post offers only a handful of facts. According to its author, the original model refused 81.6% of 838 test prompts. After modification, the refusal rate fell to 4.3%. The tool is described as free and open, but the post provides no further technical details.

What we do not know is equally important. It is unclear exactly which prompts were included in the 838-item set, how a refusal was defined, or who performed the measurement. There is no information on how the model's performance changed on ordinary tasks such as coding, reasoning, and long-context work. The post does not link to a reproducible experiment, and its reach is modest, at around 4,600 views. The figures should therefore be treated as a claim, not as a verified result.

Why this is possible in principle

A language model's refusal behavior does not reside behind a separate "button." It is shaped through training and encoded in the weights. Researchers have long shown that, in many models, refusal behavior corresponds to a relatively narrow direction in their internal representations. If that direction is identified and "subtracted" from activations or weights, the model stops responding to prohibited topics with refusals. This is known as refusal ablation and, in the community, also as "abliteration." The name OBLITERATUS hints at this class of methods, although the post does not confirm the specific implementation.

The key property of this approach is that it requires access to the weights but does not require expensive additional training. For any open model, the usual question is therefore when a refusal-free version will appear, not whether one will appear.

What developers and product teams should do

First, do not treat built-in alignment as your only line of defense. If your product uses an open model, refusals in the base version do not guarantee safety. You need your own input and output filters, separate moderation, and logging. A typical stack includes a prompt classifier, response checks, and limits on dangerous actions available to an agent.

Second, if you use third-party fine-tuned checkpoints from Hugging Face or similar platforms, verify their provenance. A model with a familiar name may behave very differently from the official release. Run your own red-team suite before production deployment, especially for agents with access to tools and data.

Third, for teams releasing open weights, this is a reminder about the threat model. Alignment encoded in the weights protects against accidental misuse, but not deliberate modification. Additional measures are needed: licensing, usage monitoring through an API version, and separate releases for different risk levels.

Limitations and conclusion

There is only one source: a social-media post with an emotional headline. For developers, this is not a reason to panic, but a reason to revisit assumptions. If you build on a closed API, your situation is different: the weights are unavailable, so this technique will not work. If you build on open models, add a question to your checklist: what happens when the refusals disappear? The answer should include a security layer that you control, not only the model developer.

The DeepSeek V4.1 Flash story is unlikely to be the last of its kind. The more capable an open model becomes, the sooner tools for removing its restrictions will emerge—and the more important the security architecture around it becomes.