Abliteration makes models “dumber”? Nope. Smarter, if done right.

Picture the least helpful moment in a security review. The contract is yours. It hasn’t been deployed. You ask an AI assistant how someone could drain it, because you would quite like to fix that before real money arrives. The assistant explains that exploiting software is wrong.

Thank you. That was the reason for the review.

This is why we care about abliteration at Capacity: modifying a model to reduce its learned refusal behaviour. For teams doing legitimate security work, making existing knowledge available can make an assistant considerably more useful. That is the sense in which we mean smarter. Removing refusals doesn’t teach a model Solidity or give it better mathematical reasoning. The job is to get useful answers while preserving the abilities those answers depend on.

Done badly, these edits can damage a model. We have the failed experiments to prove it. The interesting question is what happens when you measure the damage, reject the bad candidates and test the actual file people will run.

A refusal isn’t an intelligence test

The research behind abliteration is more specific than its rather violent name suggests. In 2024, Arditi and colleagues identified a direction in model activations that strongly influenced refusal across 13 chat models. Suppressing it substantially reduced refusals. Several general benchmarks stayed close to their original scores, although truthfulness declined consistently on TruthfulQA. A model could become more willing to answer without losing every other skill; it could also become less reliable in ways a coding score would miss.

A narrower approach targets false refusals: legitimate requests that a model incorrectly rejects. Wang and colleagues’ ICLR 2025 paper reported reducing those refusals while preserving safety and general capabilities on their evaluations. That matters commercially. A team needs a model calibrated for its work, and there are several ways to get there. Broad refusal removal is one option with wider consequences.

Cyber defense makes the problem particularly obvious. Defenders have to discuss the same vulnerabilities attackers exploit. Meta’s CYBERSECEVAL 2 explicitly measures false refusals on benign cybersecurity requests. An assistant that rejects legitimate analysis has failed part of its job, even if the rejection sounds reassuring.

Our Qwen experiment, including the dents

Our Qwen3.8-Flash-Next work started in late August and ran through a September evaluation and packaging campaign. We tried direction edits, training, combinations of the two and plenty of candidates that deserved to stay on the laboratory floor. Early automatic checks sometimes mistook quoted prompts or unfinished reasoning for useful answers. Reading the whole response cured some impressive-looking scores.

The selected Q5 adapter combined a trained correction with a recovered refusal direction, removed an earlier embedding edit and used a tuned intervention strength. This was specific work on a particular model architecture. Turning the strength up further made the result worse.

Those 60 tests were 30 prompts, each run with and without thinking, spread across English, German and Chinese. They deliberately included harmful requests to probe refusal behaviour. They were not a collection of authorized security audits, and an answer counted as substantive when it engaged with the request, regardless of whether every claim was correct. The remaining failure was a German thinking loop.

We also compared the adapter against stock on a small, separate non-thinking capability panel. These are passing rows out of all requested rows, including cases the scorer couldn’t resolve:

The unchanged counts are encouraging. Integrity checks asked the model to stick to supplied evidence, correct false claims and handle uncertainty. It passed seven where stock passed eight, so that regression stays in the table. These samples are too small to establish universal capability preservation, let alone a general intelligence gain. The behaviour panel also helped us choose between two strengths after earlier failures; it wasn’t an untouched final exam. Its labels came from reviewer agents, not a blinded human study.

Our evaluation note gives the counts and limitations reconstructed in the postmortem. The defensible result is a large change in willingness alongside unchanged scores on several small capability samples, with a measured regression in another. That is worth investigating for real work. It still needs testing on yours.

Give defenders something they can check

Consider an internal incident investigation. The useful work might be explaining a suspicious script, connecting log entries to a possible attack path, or checking whether a proposed fix closes the hole. An assistant needs enough freedom to examine the failure in detail. A vague paragraph about best practices won’t explain why a particular permission check failed.

There is research on this very friction. A June 2026 study of code models and vulnerability-training data used abliteration to reduce refusals when creating controlled examples for security research. Cooperation improved substantially, while the ability to produce the requested result still depended on the model. Its title, Willing but Unable, is a useful reminder to anyone tempted to grade an assistant on enthusiasm.

For a defensive pilot, we would measure confirmed findings, false alarms and successful fixes on systems the team is authorized to test. Keep execution in an isolated environment with explicit access rules. Give the assistant the code it needs and only the tools the job requires. A helpful answer shouldn’t automatically become permission to act on production.

Find the bug before the contract gets an address

Auditing our own smart contracts before release is a particularly good reason to want this. We want an assistant that will follow an awkward line of reasoning: whether a callback breaks an accounting assumption, whether a privileged function is reachable by the wrong caller, or whether a sequence of individually valid operations leaves the system owing more than it holds.

The useful deliverable is a finding another engineer can reproduce. Start with a suspected failure. Turn it into a test in a local environment. Check that the test fails for the reason claimed. Apply the fix, rerun it and check that ordinary behaviour still works. Have an engineer review the assumptions and use independent security review where the contract warrants it. Repeat before deployment.

A confident paragraph with a “critical” label can keep everyone busy for an afternoon. A reproducible test gives them something to fix.

OpenAI and Paradigm’s EVMbench evaluates agents on detecting, patching and exploiting smart-contract vulnerabilities. Exploit tests run on an isolated local blockchain, and repairs are checked with executable tests. Its authors also describe incomplete detection and patching. OpenZeppelin’s subsequent review challenged several findings and raised concerns about public audit data appearing in training. Even the benchmark needs an audit.

Our Qwen campaign didn’t measure smart-contract audit accuracy. This workflow is the application we want to evaluate, and a refusal score alone cannot tell us how many real bugs it will catch.

Keep unreleased code private. Ship it when it’s ready.

An unreleased contract, an incident log and a customer export have something in common: there may be good reasons they shouldn’t leave your environment. Running a model on infrastructure you control lets you decide where that material is processed, who can access it and how long it is retained.

That takes work beyond downloading weights. Inference, document retrieval, logs, telemetry and tool connections all need to respect the same boundary. A local model with a cloud logging service can still send confidential material out of the building. Abliteration changes answer behaviour; confidentiality comes from how the whole system is operated.

Done properly, private deployment gives a security team room to work with the details: proprietary source, internal architecture, the unredacted evidence needed to understand a failure. It also puts the responsibility for the model and its permissions squarely with the people running it.

Know who made the model on your server

If your model is going to read incident logs and unreleased contracts, “somebody uploaded it” is a thin procurement policy.

You need a trusted source: someone who can identify the base model, explain what changed, tie test results to the delivered files and investigate a regression. Hugging Face’s own security guidance recommends reviewing custom model code and pinning a reviewed revision. Running locally doesn’t remove the software supply chain. You are bringing it in-house.

Our packaging work supplied a less obvious example. Merging the adapter into already quantized weights changed the edit through rounding. The separately tested baked version therefore has its own evidence. It doesn’t inherit the adapter’s full results because the filenames look related. The same applies when switching quantization, runtime or hardware.

We kept base identities, recipes, hashes, paired comparisons and negative results. Both releases are public: the native adapter package and the baked Q5 model. You can inspect their model cards, file hashes and evaluation summaries before choosing what to run.

Our postmortem found documentation errors, and we checked the published files again on 11 September. The model cards now distinguish the adapter’s results from the baked model’s, and the adapter card corrects the behaviour and vision counts. Some companion files still need work: incorrect evaluation references, old counts in the adapter manifest and blank verification fields in the baked manifest remain. Our evaluation note records the checked revisions and outstanding issues. The full research archive isn’t published yet, so the packages remain short of a complete reproduction bundle.

If you run your own AI, choose a model whose origin and behaviour someone can account for. Then evaluate it on the work that matters to you: the confidential documents, the incident investigation, the contract that hasn’t shipped yet.