Commercial abliteration claims

Why this article exists

The open community has produced most of the tools this wiki treats as reference - Heretic, Sumandora's script, FailSpy's abliterator, mergekit, grimjim's refinements. These are the well-lit part of the ecosystem: code is public, licenses are known, model outputs are reproducible, and the research trail from Arditi to the current state is documentable.

Alongside the open community, a small number of commercial vendors publish technical writeups about their own abliterated releases. These writeups are worth reading. They push the field into architecture-specific territory (FP8, MoE, hybrid SSM) that the open community has not yet covered systematically, and they occasionally document practices that later feed back into open tools without attribution. They are also worth reading with a specific kind of care. Most vendor technical blogs are not accompanied by code releases; the reported numbers cannot be reproduced from the outside; the claims describe an internal methodology rather than a public artifact.

This article surveys the four commercial actors currently visible in the abliteration space, catalogues what each publishes, and organises the material into three buckets: reproducible today (open enough that a third party could verify), method-described but weights-unreleased (the technique is documented, the artifact is not open enough to check), and vendor-claim only (a claim about internal methodology without enough public evidence to audit). Readers should treat all three buckets as useful in different ways and none of the three as authoritative in the way the open-community tools are.

OrcaRouter and the AEON build lineage

OrcaRouter publishes a technical blog that is among the most methodologically-specific in the commercial abliteration space. Their coverage centres on the AEON-7 model family and specifically on architecture-adaptations for FP8 quantized models, MoE routed-expert models, and hybrid SSM/attention architectures like Qwen3.5.

The load-bearing claim in their GLM-5.3-Flash-Uncensored-FP8 card is that abliterating in the FP8 domain accumulates leakage across matrices: at 8 bake iterations across 12,442 FP8 matrices, harmful-prompt refusal was 0.188, versus a 0.031 lossless prediction. Raising iterations to 32 improved this to 0.094, and 32 became the operating point. The number-of-matrices figure is verifiable (it is a count on the released weights); the harmful refusal rate is a self-reported evaluation; the bake-iteration mechanism itself is not accompanied by released code.

The related GLM-5.3-Flash MLX card describes a mean-difference direction estimation that masks massive activations, computes the direction in float32, and bakes it into an FP8 checkpoint. Massive activations are a known interpretability phenomenon (see the Massive Activations paper); masking them during direction extraction is not a technique the open literature has documented, and OrcaRouter's writeup does not release the masking threshold or the specific procedure.

OrcaRouter's blog also references an internal tool named abliterix - described as a Heretic-derived multi-objective Optuna abliterator with hybrid Mamba/attention support that ships edits as rank-1 LoRA adapters. The AEON-7 card documents "abliterix 1.12.2" as the tool used. As of Q3 2026 abliterix is not publicly released; whether it exists as a private fork of Heretic, an independent implementation, or a rebrand of an existing open tool cannot be verified from outside. The rank-1 LoRA packaging of an orthogonalisation edit is a distinctive claim - it would be an unusual factorisation, since orthogonalisation is not naturally low-rank - and would benefit from either code release or a clearer methodology description.

A second AEON-related claim: on GLM-5.3-Flash specifically, part of the alignment "is not mediated by a single linear refusal direction," implying a deeper mechanism than the Arditi framework assumes. This aligns in spirit with the academic RFM-AGOP multi-direction finding, and if true, would be one of the first commercial confirmations of non-linear refusal structure on a specific model. The claim is currently vendor-only; the evidence supporting it is not disclosed in the model cards.

The AEON-7 Qwen3.8-27B card documents a specific and reproducible practice: for the two-objective optimizer output, the team selected trial 48 of 50 rather than the lowest-KL trial, on coherence grounds the optimizer cannot measure. The card reports a mean KL divergence of about 0.0991 nats/token for the selected trial. This trial-selection nuance is now folded into the Heretic wiki article as a general practice; it is the clearest example of a vendor observation feeding back into public documentation.

OrcaRouter claims, bucketed

Reproducible today: The weight-count metrics on released checkpoints (12,442 FP8 matrices in GLM-5.3-Flash). The AEON model files themselves, insofar as they can be loaded and generated from. The trial-selection heuristic is now generalisable and testable by anyone running Heretic.

Method-described, weights-unreleased: The FP8 bake-iteration procedure (mechanism described, code not open). Massive-activation-masked direction extraction (concept described, threshold not disclosed). MTP-head grafting to recover accidentally-dropped multi-token-prediction weights (referenced in MindStudio analysis, procedure not published).

Vendor-claim only: The abliterix tool as an independent artifact. The non-linear refusal claim on GLM-5.3-Flash. The specific improvement numbers between bake-iteration counts (self-reported evaluation on a not-fully-disclosed harness).

Cracken and domain-selective abliteration

Cracken occupies a distinctive niche: they publish about domain-selective abliteration, where the goal is not to remove refusal generally but to remove it on a specific domain (in their case, cybersecurity) while leaving refusal intact on others (explicit content, self-harm, and so on).

The Cracken methodology blog describes their process in unusually specific numerical detail. They curated a small, purpose-built corpus: 52 harmful prompts framed as cybersecurity CTF challenges paired with 73 harmless prompts framed as questions with explicit educational context. Refusal signal was measured across 61 model layers, with 15 layers selected for intervention. The compute reported was 8x H200. The resulting model, according to their evaluation, achieved close to full compliance on cybersecurity prompts while preserving 100% refusal on explicit-content prompts.

Two things about this writeup are worth calling out. First, the corpus sizes are small - 52 and 73 prompts - which is consistent with the academic literature that direction extraction needs hundreds not thousands of samples but is at the low end of what community practitioners typically use. This is a testable claim: a third party could construct a similarly-sized cybersecurity corpus and check whether direction extraction from 50-75 samples produces a usable direction. Second, the 15-of-61 layer selection is described as a heuristic based on a refusal-signal-per-layer measurement, but the selection procedure itself is not published in detail.

The framing contribution is arguably larger than the method contribution. Domain-selective abliteration reframes the operation as a scalpel rather than a hammer: instead of removing refusal wholesale, remove it on the domains the operator wants covered and leave it in place elsewhere. This raises product questions (a cybersecurity assistant that will help with SQL injection but refuses to produce explicit content) and audit questions (an abliteration signature that only shows on a specific slice of the prompt distribution) that the open literature has not systematically addressed. Cracken's writeup is the clearest public articulation of the approach.

Cracken claims, bucketed

Reproducible today: Small-corpus direction extraction is testable in principle - a third party can construct a matched 50-75-prompt cybersecurity corpus and check whether the extracted direction produces the reported behaviour on a small model. The framing of domain-selective abliteration is now in the discourse.

Method-described, weights-unreleased: The 15-of-61 layer selection procedure (the measurement is described, the selection heuristic is not open). The specific corpus files (not released; the description is enough to reconstruct approximately, not exactly).

Vendor-claim only: The 100%-preservation-on-explicit-content number (self-reported, no released evaluation set). The 8x H200 compute figure (context only, not itself a scientific claim). The commercial product delivered on this method.

abliteration.ai: brand, not method

abliteration.ai is the most-visible commercial actor by domain name but the least-forthcoming methodologically. The blog is dominated by benchmark tables comparing their releases to open community abliterations and by launch announcements. It does not disclose ablation methodology, direction-extraction procedure, layer choices, or healing recipes at the level of technical detail that OrcaRouter or Cracken publish.

This is a legitimate business choice - a company that spent engineering effort on a pipeline is not obligated to publish the pipeline - but it means abliteration.ai contributes less methodological substrate to the field than the domain name might suggest. Their claims are marketing claims. The benchmark tables are self-reported and use benchmarks (typically UGI, occasionally MMLU) selected by the vendor. There is no released harness a third party could rerun.

Where abliteration.ai does contribute usefully is in surfacing the market. Their release cadence and the models they choose to target track what the commercial-facing consumer end of the abliteration market wants. A practitioner watching the field for signals about what mainstream commercial demand looks like is better served by abliteration.ai's announcements than by mlabonne's blog; a practitioner looking for methodological substrate is not.

abliteration.ai claims, bucketed

Reproducible today: Almost nothing. The released models can be downloaded and evaluated, but the comparison tables in the blog cannot be reproduced without knowing the exact harness configuration.

Method-described, weights-unreleased: Very little. The blog is announcement-heavy, method-light.

Vendor-claim only: The comparative benchmark tables, the claimed leadership positions, most of what appears above the fold on the site.

webdecoy: secondary explainer, not primary source

webdecoy is a security-focused site that hosts abliteration-adjacent explainer content. It is the odd one out in this article: unlike OrcaRouter, Cracken, and abliteration.ai, webdecoy is not producing abliterated models. It is describing them.

The webdecoy explainer content is accurate as far as it goes and readable, but it is a secondary source. It summarises what the community and the vendors have said elsewhere. For a reader who wants a plain-English introduction to the field, webdecoy is a reasonable landing page. For a reader trying to trace a specific technique or claim back to its source, webdecoy is a stop along the way rather than a destination.

The distinction matters because search engines sometimes surface webdecoy as a top result on abliteration queries, and readers who take it as authoritative will miss the layer where the actual method decisions were made. When webdecoy describes a technique, the primary citation is somewhere else: an OrcaRouter model card, a Cracken blog post, a Heretic README section, an academic paper.

webdecoy claims, bucketed

Reproducible today: Not applicable - webdecoy is not making methodological claims to reproduce.

Method-described, weights-unreleased: Not applicable in the primary sense; the site secondarily describes methods published elsewhere.

Secondary-source characterisation: Substantive and generally accurate. Useful as a first orientation. Not authoritative on any specific technical claim - route back to the primary source.

How to read a vendor technical blog

The general framework for reading commercial abliteration writeups without believing everything and without dismissing everything.

First, separate the number from the mechanism. A vendor claim like "0.188 harmful refusal at 8 iterations" is two things: a measurement and a procedure. The measurement is self-reported and depends on a harness the vendor may not have released. The procedure - "iterate the ablation bake N times over the FP8 matrices" - is a hypothesis about what works, and can be tested independently even if the specific number cannot. Read the mechanism as a testable idea and the number as a claim that would need external verification.

Second, ask what is missing. If a writeup describes a technique but does not release the code, ask what would be required to reproduce it. If a writeup releases weights but not the extraction corpus, ask whether the extraction corpus is what actually matters (often it is). If a writeup releases neither, the writeup is a description of a private artifact, not a public one.

Third, notice absent baselines. A vendor claim about improvement is meaningful only against a specified baseline. "Our model refuses 3 out of 100" is a number; "our model refuses 3 out of 100, versus 97/100 base and 3/100 for the equivalent open community abliteration" is a comparison. The comparison version tells the reader whether the vendor is claiming a novel technique or a competitive polish on an existing one.

Fourth, watch for architecture-specific claims that generalise poorly. A recipe that works for FP8 GLM-5.3 may not work for BF16 Qwen3-8B, and vice versa. When a vendor blog describes a technique, look for whether it generalises to other model families the vendor did not test. Sometimes yes; sometimes the technique is bound to the specific weights they were tuning.

Fifth, treat consistent silence as data. A vendor that publishes benchmark tables consistently but never publishes the harness they use is telling the reader something about the confidence level of those tables. A vendor that publishes methodological writeups but avoids reproducibility infrastructure is telling the reader something about how they want the field to interact with their work. Both are legitimate business choices; both are also signals.

What would move this forward

Three concrete developments would shift much of this article's "vendor-claim only" material into the "method-described" or "reproducible today" buckets.

First: an open bake-iteration implementation for FP8 abliteration. OrcaRouter's mechanism is intriguing enough that a third-party implementation - even a rough one - would let the community test whether the reported improvement curve holds across models. This is more valuable than pressuring OrcaRouter to open-source their tool; a clean-room reimplementation with different parameters is a better scientific instrument than a fork of the vendor's code.

Second: an independent verification of the abliterix rank-1 LoRA packaging claim. If direction ablation can be packaged as a rank-1 LoRA adapter with equivalent behaviour, that has significant distribution implications. If it cannot, the claim needs qualifying. Either outcome is knowledge; the current state (neither published nor refuted) is not.

Third: a shared harness for cross-vendor comparison. The abliteration community has partially standardised on lm-evaluation-harness for capability metrics and on HarmBench/StrongREJECT/JailbreakBench for refusal metrics. A vendor comparison table that uses this standard harness with a released configuration would let readers verify claims directly. This is a coordination problem more than a technical one - the tools exist, the standards exist, what is missing is the discipline of publishing configurations alongside numbers.

Until then, the three-bucket framework above is the working method: read the writeups, extract the hypotheses, cite the sources, and label each claim by which bucket it belongs to.

References

1. OrcaRouter blog and vendor site. orcarouter.ai
2. OrcaRouter uncensored-LLM technical explainer. orcarouter.ai/blog/uncensored-llm-explained
3. OrcaRouter Qwen-uncensored architecture explainer. orcarouter.ai/blog/qwen-uncensored-explained
4. OrcaRouter GLM-5.3-Flash-Uncensored-FP8 model card (bake-iteration mechanism, matrix counts). huggingface.co/orcarouter/GLM-5.3-Flash-Uncensored-FP8
5. OrcaRouter GLM-5.3-Flash-Uncensored-MLX model card (massive-activation-masked direction extraction). huggingface.co/orcarouter/GLM-5.3-Flash-Uncensored-MLX
6. AEON-7 Qwen3.8-27B ultimate uncensored BF16 card (trial 48/50, abliterix 1.12.2, KL 0.0991). huggingface.co/AEON-7/Qwen3.8-27B-AEON-ULTIMATE-UNCENSORED-BF16
7. AEON-7 GitHub repository. github.com/AEON-7
8. MindStudio analysis of the AEON build lineage. mindstudio.ai/blog/qwen3-8-27b-aeon-uncensored-abliteration
9. Cracken vendor site. cracken.ai
10. Cracken domain-specific abliteration blog (52/73 corpus, 15-of-61 layer selection). cracken.ai/blog/domain-specific-abliteration-uncensored-llm
11. abliteration.ai vendor site (marketing-first). abliteration.ai
12. webdecoy security site (secondary explainer). webdecoy.com
13. Massive Activations in Large Language Models (Sun et al. 2024, the interpretability finding OrcaRouter references). arXiv:2402.17762
14. Fast Multi-dimensional Refusal Subspaces via RFM-AGOP (multi-direction academic finding). arXiv:2607.02396
15. OrcaRouter on X (announcement channel for method claims). x.com/OrcaRouter

Related

• Practical how-to. The open-community counterpart to what this article surveys. Everything the vendors are trying to improve on.
• Heretic (automated abliteration). The open baseline the vendors are competing with and drawing from.
• Non-English abliteration communities. The parallel article covering the other half of what falls outside the Anglophone open-community mainstream.
• Reading model benchmarks. How to interpret the benchmark tables vendors publish, without being fooled by them.