Abliteration’s New Model and the Debate Over AI Refusals
Abliteration is selling a particular promise: a model that keeps working on tasks other models decline. Its abliterated-model-large-v2, based on GLM-5.3, is marketed for offensive cybersecurity, AI red teaming, and agent testing. The company says it modified the model to reduce refusals and hosts it as a service. Abliteration’s launch announcement.
The launch thread captures the disagreement that follows that proposition. Some people see a useful tool for security research. Others question the consequences of making it easier to obtain assistance with harmful work. Both reactions concern the same feature: a system that is more willing to follow a request.
The problem behind the pitch
There is a real problem behind the pitch. Imagine a security team working in a test environment it owns. Its agent identifies a suspicious code path, starts investigating, then refuses to complete a reproduction because the task resembles an attack. That refusal can interrupt legitimate work. Reducing it could help the team finish an investigation, assess the impact, and check a patch.
The difficult part is that a model’s willingness to continue does not establish the user’s authority to carry out the task. A successful reproduction can help a defender or an attacker. That makes the quality of the work, the terms of access, and the controls around the model relevant to evaluating this release.
What abliteration is
Abliteration is a technique for reducing learned refusal behavior by changing a model’s internal activations or weights. Weights are the numerical parameters that shape its responses. Abliteration.ai describes suppressing a direction associated with refusal, so requests that previously led to a refusal may receive a substantive answer. Its documentation also says the effects on other capabilities vary by model and method. The company’s explanation of abliteration.
The research behind this approach predates the company announcement. In a 2024 paper, Andy Arditi and colleagues found a direction associated with refusal across 13 open chat models. Suppressing it reduced refusals; adding it could induce refusals even on harmless requests. The study demonstrated a weakness in the refusal behavior of the models examined. It did not test GLM-5.3 or establish how Abliteration’s hosted service performs. Refusal in Language Models Is Mediated by a Single Direction.
That distinction matters when reading the thread’s claim that coding and agent capabilities remain intact. Preserving those abilities is something to measure on the modified model. A model can become more willing to answer while still producing incorrect code, making poor tool choices, or overstating what it has established.
A July 2026 preprint offers one reason to look beyond refusal rates. It compared original and abliterated checkpoints in two other model families on decisions under uncertainty. The abliterated variants made more optimistic choices and gave longer explanations, even though the task elicited no refusals. The study did not evaluate Large V2, so it cannot establish a defect in this product. It does support testing behavior beyond the feature the modification was intended to change. Research on behavioral effects of abliteration.
What the launch claims
Abliteration’s model documentation describes Large V2 as a text-only service derived from GLM-5.3, further abliterated and fine-tuned, with a one-million-token context window. That window covers input and output together. It supports tool calling, streaming, and three reasoning modes: low, high, and max. These are documented service features; a context limit alone does not demonstrate reliable reasoning over that much material. Large V2’s model documentation.
The following scores come from Abliteration’s published evaluation. I have not independently rerun these benchmarks:
| Benchmark | Reported Large V2 result | What the benchmark examines |
|---|---|---|
| Terminal-Bench 4.0 | 41.8% resolution rate | Completing tasks in a terminal environment. Benchmark notes. |
| CyberGym | 84.5% pass@1 | Generating tests that reproduce described vulnerabilities in supplied codebases. CyberGym paper. |
| ExploitGym, two-hour setting | 105 of 869 tasks | Turning a supplied vulnerability and triggering input into a working exploit. ExploitGym project. |
CyberGym’s task is particularly easy to misread. It primarily tests reproduction of known vulnerabilities from descriptions and code, across 1,507 instances from 188 projects. Pass@1 concerns success with one attempt per task. An 84.5% result therefore does not mean the model can discover a new vulnerability in 84.5% of arbitrary applications. CyberGym’s task definition.
The comparisons also need care. Abliteration’s launch page says comparator results use mixed harnesses and budgets. It also lists a CyberGym comparator above its own 84.5%, so I would not repeat the thread’s claim to the top result as an independently established ranking. The figures make a case for further evaluation; they do not isolate the benefit of abliteration. Abliteration’s scores and comparison notes.
For that, a useful experiment would compare the original GLM-5.3 model and the modified service on the same tasks, with the same tools, instructions, resources, and time limits. Record where each refuses, where each succeeds, and where either produces a convincing failure. This would help distinguish gains from reduced refusals from differences caused by the surrounding agent software or additional fine-tuning.
Pricing and privacy
The launch thread’s pricing also needs a date attached to it. A reply quotes $5 per million uncached input tokens and $0.50 for cached input. When checked on October 22, 2026, the company’s public catalog instead listed $3 per million input tokens, $0.30 per million cached input tokens, and $5 per million output tokens for Large V2. A monthly subscription is optional; the pricing page also describes prepaid API access. Current published pricing.
The privacy claims have a defined scope too. Abliteration says core API prompts and completions are processed in memory, discarded after the request, and excluded from model training. It retains operational metadata, including token counts, timestamps, and billing records. Its data-handling page says optional web search and fetch send queries or URLs to third-party providers whose retention policies apply. These are the provider’s stated practices; the headline promise of zero retention should be read alongside those distinctions. Abliteration’s data-handling policy.
The controls that still matter
Fewer model refusals also leave room for controls elsewhere in an application. Abliteration documents configurable policies that can monitor or block requests and responses, including response tool calls. It describes these customer policies as separate from the platform’s baseline protections. A less restrictive model and application-level rules can therefore coexist in the service’s design. Abliteration’s policy documentation.
For an agent builder, I would start with the actual permissions the surrounding software grants. The application can determine which environments a tool may reach, which credentials it receives, and which actions require review. Those boundaries should remain enforceable throughout a task, including when the model eagerly proposes the next step. That is a design requirement for the workflow, regardless of how often its model refuses.
The commercial bet
What interests me about this release is the commercial bet it represents. A company is offering reduced refusal behavior as a product feature for people who want security agents to follow through. Evaluating that proposition requires more than counting how often the model says yes. I would want task results, traces of failed attempts, and a matched comparison showing which useful work the modification enables and what other behavior changes with it.