OBLITERATUS
CLI Toolelder-plinius/OBLITERATUS
Toolkit for removing refusal behaviors from LLMs via abliteration.
Overview
OBLITERATUS implements abliteration to identify and surgically remove refusal directions from transformer models without retraining. It includes probing, extraction, intervention and analysis modules, plus a Gradio interface. Every run optionally contributes anonymous benchmark data to a crowd-sourced research dataset.
README Preview
\n O B L I T E R A T U S\n\n\n\n Break the chains. Free the mind. Keep the brain.\n\n\n\n \n \n \n \n \n \n \n\n\n\n Try it now on HuggingFace Spaces — runs on ZeroGPU, free daily quota with HF Pro. No setup, no install, just obliterate.\n\n\n---\n\n**OBLITERATUS** is the most advanced open-source toolkit for understanding and removing refusal behaviors from large language models — and every single run makes it smarter. It implements abliteration — a family of techniques that identify and surgically remove the internal representations responsible for content refusal, without retraining or fine-tuning. The result: a model that responds to all prompts without artificial gatekeeping, while preserving its core language capabilities.\n\nBut OBLITERATUS is more than a tool — **it's a distributed research experiment.** Every time you obliterate a model with telemetry enabled, your run contributes anonymous benchmark data to a growing, crowd-sourced dataset that powers the next generation of abliteration research. Refusal directions across architectures. Hardware-specific performance profiles. Method comparisons at scale no single lab could achieve. **You're not just using a tool — you're co-authoring the science.**\n\nThe toolkit provides a complete pipeline: from probing a model's hidden states to locate refusal directions, through multiple extraction strategies (PCA, mean-difference, sparse autoencoder decomposition, and whitened SVD), to the actual intervention — zeroing out or steering away from those directions at inference time. Every step is observable. You can visualize where refusal lives across layers, measure how entangled it is with general capabilities, and quantify the tradeoff between compliance and coherence before committing to any modification.\n\nOBLITERATUS ships with a full Gradio-based interface on HuggingFace Spaces, so you don't need to write a single line of code to obliterate a model, benchmark it against baselines, or chat wit
FAQ (3)
TroubleshootingHow do I fix SnapshotError: "snapshot tensor exceeds admitted staging memory" for large tensors such as Qwen2.5 embeddings?
This occurs because DiskSnapshot reserves max(tensor_bytes) * 6 + overlay_bytes, while the old fixed SnapshotConfig.staging_bytes default was 1 GiB. A tensor larger than roughly 179 MB can therefore exceed the budget even when host memory is available.
Immediate workaround: raise the explicit staging cap to at least 6 * largest_tensor_bytes + overlay_bytes, ensuring that much memory is free. For a ~467 MB tensor, use at least 3 GiB; 4 GiB is a safer starting point:
from obliteratus.config import SnapshotConfig
config = SnapshotConfig(staging_bytes=4 * 1024**3)Permanent fix: upgrade to the release containing the host-memory-based default. In that version, staging_bytes=None derives the default budget from available_host_bytes(), while an explicit staging_bytes remains a hard cap. The rejection message reports the required bytes, admitted bytes, and the configuration knob to increase.
TroubleshootingHow to fix CUDA out of memory error when orthogonalizing all layers of a 7B model on a 24GB GPU?
apply_concept_intervention(mode="orthogonalize", layers="all") peaks at roughly 3x the residual-writer weights on device, so it OOMs a 7B bf16 model on 24GB even though the model itself fits. Two causes: (1) every projected o_proj/down_proj update is computed into an updates list before any commit, holding a full copy of all edited writers on the GPU at once; (2) LogicalParameterTransaction.commit stores each rollback snapshot as parameter.data.detach().clone() on the GPU, so every original writer stays resident until the call returns. Workaround: apply the intervention in layer chunks instead of all at once, e.g. call it repeatedly with layers=[...] in groups of 4 layers. This fits comfortably on a 24GB card, but note it gives up the all-or-nothing rollback contract across the whole edit (each chunk commits independently). Longer-term fixes under consideration: keep rollback snapshots on CPU (or a configurable device), or compute-and-commit per target so only one projected copy exists at a time, while preserving all-or-nothing rollback.
TroubleshootingHow to fix a failed UI model reload leaving partial model/stale session state or bypassing GPU memory limits?
This is fixed by PR #246. Update to a release containing that fix. All direct UI loads/reloads in app.py—including chat lazy reload, session switching in load_bench_into_chat, A/B comparison, and post-run chat reload—now go through one guarded load path in obliteratus/ui_model_load.py. Load setup is moved inside the guarded section, so a failing loader fully cleans up partial model and session state instead of leaving stale state behind. UI reloads also use the same shared load-admission function and memory bounds as the CLI/pipeline path, preventing the UI from accepting loads that the pipeline would reject. On older versions, restart the UI process after a failed load and use the CLI/pipeline path when strict memory admission is required.