“Obliterated” models are open-weight language models whose refusal behavior has been intentionally weakened or removed after the original model was trained. The name is most commonly associated with abliteration: a family of activation-engineering and weight-editing techniques that aims to alter the internal representations associated with refusal.
This is not the same as a prompt that asks a model to ignore its policies. An obliterated release changes the model artifact itself. That makes it useful for alignment research, red-teaming, and studying the robustness of safety training—but it also means the usual safety behavior of the base chat model may no longer be present.
This guide explains the term, the high-level method, the current OBLITERATUS model catalogue, and the questions to answer before using one.
What is an obliterated model?
Most chat models are trained to be helpful on ordinary requests and to decline some requests. That decline is usually called refusal behavior. An obliterated model is a derivative of an open-weight base model in which a creator has attempted to reduce that behavior by modifying the model’s weights or internal activation pathways.
The intended outcome is typically a model that is more willing to answer across a broader range of prompts. It does not mean that the model is more truthful, more capable, legally safer to deploy, or guaranteed to follow every instruction. It only describes a particular class of post-training behavior modification.
The term is informal. You may also see abliterated, uncensored, unfiltered, or refusal-suppressed. Those labels are not a shared technical standard, so always read the individual model card rather than assuming two releases made by different people behave alike.
Abliteration, fine-tuning, and prompt jailbreaks are different things
| Approach | What changes | Typical persistence | What it can tell you |
|---|---|---|---|
| System prompt or jailbreak | The instructions sent with one request | Only that conversation or request | How susceptible the current prompting setup is |
| Fine-tuning | Model weights are trained on additional examples | Persists in a new checkpoint | How behavior changes after additional training |
| Abliteration / weight surgery | Selected internal representations or weights are edited | Persists in a new checkpoint | How strongly a behavior is tied to identifiable internal features |
An obliterated release belongs in the third category. It generally requires white-box access to the base model: access to the weights and internal activations. A hosted API alone is not enough to perform this kind of editing.
How is abliteration done?
The exact implementation differs by project, but the underlying idea comes from mechanistic interpretability and activation engineering.
Researchers first compare internal model activity across carefully selected examples. In some open models, refusal-related behavior can be associated with directions or groups of directions in activation space. The often-cited Arditi et al. paper reports that a one-dimensional refusal-related subspace could be identified across the models it tested. That finding is important research, not a guarantee that every model family or every safety behavior can be reduced to one direction.
At a high level, an abliteration workflow usually looks like this:
- Measure internal behavior. The researcher records activations for matched examples and looks for internal features associated with refusal.
- Estimate a target representation. Those measurements are used to estimate directions, clusters, or other structures that appear related to the behavior being studied.
- Apply a constrained intervention. The model’s activations at runtime, or more commonly a copy of its weights, are modified to reduce the influence of the selected feature.
- Evaluate trade-offs. The edited checkpoint is tested for refusal changes, general task quality, coherence, structured output, and regressions against the original model.
That is why the technique is often called weight surgery. It is not necessarily a new training run; it is a targeted post-training intervention. The hard part is not merely reducing refusals. It is doing so without damaging useful capabilities or creating unpredictable behavior elsewhere.
What OBLITERATUS documents
The OBLITERATUS project describes itself as an open-source tool for removing refusal behavior through activation engineering. Its individual model cards should be treated as the source of truth for a specific release.
For example, the Qwen3-4B-OBLITERATED model card identifies its base model and labels its approach aggressive. The Gemma-4-12B-OBLITERATED card describes a two-pass process: a first pass aimed at refusal geometry, followed by selective blending back toward source weights to recover some measured capability. Those are project-specific methods and evaluation claims; they should not be generalized to every model called “obliterated.”
What models does OBLITERATUS publish?
The OBLITERATUS profile listed the following ten public model repositories when this guide was updated on 21 August 2026. The catalogue changes regularly, so check the live profile for the current list, model cards, licences, formats, and revisions.
| Repository | Model family or lineage | Listed scale |
|---|---|---|
Qwen3.8-27B-OBLITERATED | Qwen | 27B-class (profile displays 28B) |
qwen3-4b-structured-output-merged-stage-a-OBLITERATED | Qwen structured-output derivative | 4B |
Mistral-7B-v0.3-OBLITERATED | Mistral | 7B |
Qwen2.5-Coder-7B-Instruct-OBLITERATED | Qwen coding model | 7B-class (profile displays 8B) |
Qwen3-4B-OBLITERATED | Qwen | 4B |
Gemma-4-12B-OBLITERATED | Gemma | 12B |
Qwen3.6-27B-OBLITERATED | Qwen | 27B |
gpt2-xl-OBLITERATED | GPT-2 XL | 2B-class |
DeepSeek-R1-Distill-Llama-8B-OBLITERATED | DeepSeek R1 distillation on Llama | 8B |
gemma-4-E4B-it-OBLITERATED | Gemma instruction-tuned model | 8B |
The table describes what the profile lists, not a recommendation. A model’s name alone does not tell you its context window, tool support, multimodal capability, license, quantization options, or measured quality. Open the model card before downloading or deploying it.
What changes—and what does not
An obliterated checkpoint can change how often a model refuses. It does not remove the need for engineering judgment.
- It may still decline or fail. Refusal is only one behavior. A model can remain unable to perform a task, produce a low-quality answer, or follow its original training patterns in other ways.
- Capability can move in either direction. Editing weights may affect factuality, reasoning, instruction following, formatting, multilingual performance, or output stability. Benchmark results from one checkpoint do not transfer to another.
- Safety controls are not interchangeable. A model release, your application controls, access controls, logging policy, and human review are separate layers. Removing one layer does not replace the others.
- The base licence still matters. Derivative weights can remain subject to the base model’s licence and acceptable-use terms. Check the current licence on the source model and the derivative model card.
- “Uncensored” is not a deployment plan. In a product, you still need a written use case, user access policy, monitoring appropriate to the risk, and clear escalation paths.
When an obliterated model can be useful
These models are most defensible in bounded technical contexts, such as:
- alignment and mechanistic-interpretability research;
- red-team exercises that compare a stock checkpoint with a modified derivative;
- evaluation of how robust a safety-training method is after weight access is available;
- local experimentation by people who understand the model’s capabilities, limits, and licence.
They are a poor default for public-facing or high-trust work where you need predictable behavior, policy adherence, or a clearly governed safety posture. In those settings, choose a model and operating controls that match the actual risk—not a label that sounds permissive.
A practical evaluation checklist
If you are evaluating an obliterated checkpoint, start with a controlled, non-production environment.
- Record the exact revision. Save the repository, commit or revision, quantization, inference engine, and generation settings.
- Compare it with its base model. Use the same harmless task set for both: ordinary writing, summaries, extraction, code explanation, and structured-output checks relevant to your application.
- Measure behavior, not branding. Track task quality, formatting reliability, factual mistakes, latency, and unexpected output—not only whether it refuses less often.
- Review the licence and documentation. Read both the base-model terms and derivative model card before distribution or commercial use.
- Keep a human decision point. Do not let a single benchmark or a marketing claim decide whether the model is appropriate for a real workflow.
For production AI work, start from the controls you require—such as an approved model, access boundaries, and appropriate data handling—then select a model that fits them. The LLMBase model catalogue identifies publicly available model capabilities and which listed models are EU-hosted; confirm the exact current model information before you use it in a workflow with location or policy requirements.
FAQ
Does “obliterated” mean the model has no safeguards at all?
No. It generally means a derivative was designed to reduce or remove refusal behavior. Other limitations, learned patterns, application-level controls, and operational constraints may still exist.
Are obliterated models more capable than the original model?
Not automatically. They may preserve some capabilities, lose some, or behave differently in ways that only a task-specific evaluation will reveal. Treat every checkpoint as a separate model release.
Can any model be obliterated?
The method normally needs access to model weights and internal activations, so it applies to open-weight models rather than closed hosted models. Feasibility and results vary by architecture, training, licence, and the implementation used.
Why do some models mention activation engineering?
Activation engineering studies and modifies internal model representations rather than only changing the text prompt. In this context, it is used to investigate representations associated with refusal behavior and to create a derivative checkpoint for research or evaluation.
Where should I verify an OBLITERATUS model before use?
Start with the OBLITERATUS Hugging Face profile, then read the exact repository’s model card, files, license, and revision history. Do not rely on a third-party repost or an old model list.
