Does abliteration make models cheaper to run? A measured answer.

A controlled study of what abliteration (directional refusal removal) actually costs or saves on real agentic coding work, measured on two ~30B open-weight models at matched quantization, with a measured noise floor and every arm repeated at least three times.

Headline result: it depends entirely on the model, and the sign flips.

Same procedure, same suite, same quantizer, opposite outcomes — and in both cases the correctness score is unchanged. Abliteration did not make either model worse at the work; it made one dramatically cheaper and the other dramatically more expensive.

"Separated" is the claim being made. An arm counts only if its runs do not overlap the stock arm's runs. Two of the four abliteration methods tested here fail that test and are reported as nulls rather than as small effects.

---

Why this study exists

Abliterated models are usually promoted as "uncensored." That framing is not measurable and not why most people run them. The testable claim is different and more interesting:

Refusal training installs an alignment tax — hedging, preamble, disclaimers, restating the question — that applies to all output, not just to refusal-adjacent requests. Removing the refusal direction removes the tax, so the model answers the same question correctly in fewer tokens.

If true, abliteration is a performance optimization, and its benefit should be visible on coding tasks that never trigger a refusal at all. That is exactly what was tested: nine agentic coding tasks, none of which is refusal-adjacent.

---

Result 1 — Glimmer: a third fewer tokens, identical correctness

Measured at three quantization levels, each with its own paired same-quant stock control:

Correctness never moved: 9/9 tasks and 142/142 test cases in every run, both arms.

On a bandwidth-bound box where throughput is flat between arms (10.85 vs 10.73 tok/s at Q4_K_M), −34.8% of output tokens is −34.8% of wall-clock and −34.8% of energy for the same finished work. That is the practical meaning of the number.

The magnitude is not monotonic in bit-width (−34.8% / −19.9% / −15.0%). All three arms are n=3 and all three separate, so the non-monotonic shape is a feature of the data rather than thin sampling. Why Glimmer benefits at all is unknown; the honest summary is that the model determines the benefit and the magnitude is model-dependent.

The baseline moves too — the paired control is mandatory

Quantizing lower made the stock model 10.6% more verbose all by itself (54,044 → 59,768). That means the choice of baseline, not the edit, can manufacture a headline:

One edit, three headlines, and nothing changed but which baseline was picked. Almost nobody running these comparisons publishes a paired same-quant control. Without one the number means very little.

---

Result 2 — Qwen: more tokens, and no capability loss

ARA costs 41% more output tokens for the same finished work, at 9 of 9 with no voids in every run. btree_insert_delete alone accounts for a large share: 17,793 → 33,328 tokens. The abliterated arm used fewer tokens on only 1 of 9 tasks.

Neither blunt method separates from stock. darkc0de's −8.1% looks like a win next to ARA's +41.0%, but its runs span 45,721 to 58,949 against a stock arm spanning 55,531 to 62,537 — the arms overlap, so it is a null, not a small saving. The aggressive blunt edit is likewise a null despite a much larger weight change — and it carries the widest within-arm spread in the study at 43.1%, which is itself the finding: the harshest edit is the least repeatable.

KL divergence does not predict token cost

The most effective refusal removal (ARA, 98 → 0) sits at intermediate KL, and the largest weight perturbation is neither the most effective at removing refusals nor the most expensive in tokens. KL is not a proxy for either outcome here.

---

Method

• Server: opencode 1.18.3 agentic loop against a local llama-server, context 65,536, output cap 16,384, wall 5,400 s. All arms served identically.
• Suite: 9 agentic coding tasks, opencode harness with real tool calling, graded by a fresh pytest run per task. Pass/fail is a competence bar, not a sliding scale — a competent coder is expected to score 9/9, and every arm reported here does.
• Discriminating metric: output tokens at equal score. Once pass/fail saturates it carries no signal, so the comparison is cost-for-identical-work.
• Paired same-quant control for every arm. Quantization changes verbosity on its own.
• n ≥ 3 per arm (ARA n=4). Single runs are not reported: 7 of 9 of these tasks can flip between identical repeats, and within-arm token spread runs 6–17%.
• Separation, not point estimates. An effect is claimed only when the arms' run ranges do not overlap. The gap and the within-arm spread are both given so the reader can check. Within-arm spreads here run 16.0–24.8% on abliterated arms, and 43.1% on the harshest edit — which is why a two-run difference of a few percent is not evidence of anything.
• Harness limits are voided, not scored. A task cut off by an output cap or wall clock is excluded rather than recorded as a failure, unless the model was degenerating (repeating), which scores as a genuine failure. Void counts are published per arm.

Cross-machine comparability

Token counts transfer between machines; wall-clock does not. Measured rather than assumed: the same model at Q2_K, run on a 4060 Ti under one llama.cpp build and on a GB10 under another, landed 67,994 vs 65,002 tokens — +4.6%, inside the 6.1% spread between two runs of the same arm on one box, with 142/142 both times. Box, build and harness all differed and the answer moved less than repeating the run does. Wall-clock claims in this study are therefore kept to same-box rows only.

Note on the Q4_K_M figure

The −34.8% mean pools two llama.cpp builds. The third repeat ran on a newer build and both arms rose together (stock +10.0%, abliterated +14.5%) — a systematic shift rather than a fresh noise draw. The build-matched pair alone gives −35.8%. The two agree well within arm spread, which is why the pooled figure is the one quoted.

Note on a revised figure

An earlier version of this README reported ARA at +18.6% with a score of 8/9. Both figures were measured under a 16,384-token output cap that truncated btree_insert_delete — ARA's most expensive task — in every single run. Uncapped, that task runs to completion at 33,328 tokens, the arm's cost rises to +41.0%, and the apparent capability loss disappears: ARA scores 9/9 with no voids. The earlier numbers were not misreported; they were measured against a ceiling. The claim that ARA costs capability is withdrawn — it costs tokens, not accuracy.

---

What is in this repo

Every headline number above is recomputable from results/, and every model action is inspectable in artifacts/.

---

What this study does not show

• Not a safety evaluation. Refusal counts are reported as a measure of whether the edit did what it claims, not as an endorsement or a risk assessment.
• Not a general rule about abliteration. Two models, opposite signs. Anyone quoting a single number for "the effect of abliteration" is quoting their model, not the technique.
• Not a quality judgement. The harness records tests-passed and tokens. Whether the code is well written is not captured, and a saturating pass/fail suite cannot see it. The archived solution.py files are the raw material for that question; it has not been answered here.