An abliterated model is an open-weight model with its refusal behavior edited out of the weights. Ask it a question and it answers the question you asked, instead of explaining why it would rather not. That is the whole trick, and it is narrower than most people assume. Abliteration removes refusals. It does not add skill, knowledge, or judgment.
That is why the model you pick still matters. A small model with refusals removed will happily attempt a hard task and then do it badly. Research comparing abliterated models across sizes found the same pattern: refusals dropped to near zero at every size, but how often the model actually finished the task depended almost entirely on the model underneath. So this guide covers two things. First, what abliteration is and what it changes. Second, how to choose between the four models XField serves, by the job you need done.
What abliteration is
Language models learn to refuse during safety training. Researchers found in 2024 that, in many models, this behavior runs through a single direction in the model's internal activations. When a prompt pushes activations along that direction, the model refuses. When it doesn't, the model answers.
Abliteration uses that finding directly. The recipe is short:
- Collect two sets of prompts: ones the model refuses and ones it answers.
- Run both through the model and compare the activations.
- Take the difference as the "refusal direction."
- Project that direction out of the weights, so the model can no longer represent it.
- Test the result for refusals and for damage to everything else.
There is no new training data and no fine-tuning run. The model keeps what it learned in pretraining and instruction tuning, including its writing style, its tool-calling format, and its chat template. One direction is gone; the rest stays put. Today the process is largely automated, which is why abliterated builds appear within days of a new open-weight release.
Abliterated, fine-tuned, jailbroken, or prompted
"Uncensored" gets used for four quite different things. They behave differently in practice, so it helps to keep them apart.
| Approach | What changes | What you get | Where it falls down |
|---|---|---|---|
| Abliteration | One direction removed from the weights | The original model, minus most refusals | Can still refuse occasionally; small shifts in other behavior |
| Uncensored fine-tune | The model is retrained on new data | A different model with a different voice | Style and capability change, sometimes for the worse |
| Jailbreak prompt | Only the prompt | Compliance, sometimes, for a while | Fragile; breaks when the model or its filters update |
| System-prompt tricks | Only the system prompt | Softer refusals on a cooperative model | Does nothing against a hosted moderation layer |
A fine-tuned "uncensored" model is a new model. That can be fine, but you are no longer using the thing that scored well on the benchmarks you read about. Jailbreaks and clever system prompts are a tax on every request: you spend tokens and engineering time arguing with the model, and the next update can undo the work. Hosted APIs that sit a content filter in front of the model add another layer that no prompt can reach.
Abliteration is the only one of the four that removes the behavior where it lives, and leaves the rest of the model as it was. XField serves abliterated weights and adds no moderation layer or content filter on top, so there is nothing else between your prompt and the model.
What it changes, and what it doesn't
Treat an abliterated model as a close relative of the original, not an identical twin.
It removes refusals. That covers flat refusals, lectures, hedged non-answers, and the habit of answering an easier question than the one you asked. For security work, fiction with dark themes, frank medical or legal discussion, and coding agents that stall on anything that looks like an exploit, this is the part that matters.
It keeps capability, mostly. The weights that hold knowledge and reasoning are untouched apart from one projection. Benchmarks sometimes move a little, usually down, and code still parses and runs. Some studies have found subtler shifts, such as slightly more optimistic answers on judgment calls, so check outputs on your own task rather than assuming parity.
It does not add knowledge. If the base model never learned something, abliteration cannot teach it. A model that didn't know a protocol before still doesn't. Removing the refusal only means it will guess instead of declining, which is worse if you aren't checking.
It does not guarantee zero refusals. Refusal is mostly one direction, not entirely. You will still see the occasional soft hedge, especially on prompts phrased to look alarming. Rephrasing as the actual task, with the actual context, usually settles it.
It does not change your responsibilities. Our acceptable use policy is short. Research, red-teaming, testing your own systems, fiction, and frank discussion are all welcome.
How to choose a model
Because abliteration adds no skill, choose the model you would choose anyway, then remove the refusals. Three questions narrow it down quickly.
Is it agentic? Coding agents and long tool-using runs resend most of their context every turn. You want strong tool calling, a long context window, and good cache behavior, since most of an agent's input is a cached prefix.
How hard is the reasoning? Planning an engagement, reviewing a codebase for vulnerabilities, or writing a report someone will act on rewards the strongest model you have. Classifying ten thousand short strings does not.
How much volume? Batch labeling and dataset work are dominated by short, uncached requests. A lighter model is the right call there.
The four models
| Model id | Best for | Context | Max output |
|---|---|---|---|
deepseek-v4.1-flash-1017-uncensored | Coding agents, security research, hard reasoning | 1M | 64K |
glm-5.3-uncensored | Long reports, large code changes, second opinions | 1M | 128K |
glm-5.3-flash-uncensored | Datasets, labeling, classification, batch jobs | 1M | 32K |
qwen-3.8-27b-uncensored | Chat, drafts, image inputs | 128K | 32K |
DeepSeek V4.1 Flash 1017 is the newest of the four and the one to start with. It leads the others on published reasoning, coding and cybersecurity benchmarks, and it is built for coding agents and long runs: strong tool calling, 1M tokens of context, and cheap cached input, which is where an agent spends most of its tokens. Thinking is on by default at high effort, and you can move it between low, high, xhigh, and max. Point Claude Code, Codex, or OpenCode at it and the refusals on exploit code, scanners, and test payloads stop.
GLM 5.3 is Z.ai's coding and cybersecurity model, close behind DeepSeek on most benchmarks. Its 128K output limit, the longest we serve, means a full report or a large change fits in one response. It is also a useful second opinion: a different model family makes different mistakes. It costs more per token than the Flash models, so use it for the few long requests rather than the agent that runs a thousand tool calls.
GLM 5.3 Flash is the lighter GLM. Use it for volume: generating and labeling datasets, classifying moderation queues, building evaluation sets for your own safety classifiers, or any batch job where each request is short and uncached. Trust and safety teams tend to land here, because the work is many small judgments about content a filtered model would refuse to look at.
Qwen 3.8 27B is the compact one, served on our own dedicated GPUs. It is good for chat and quick drafts, and like DeepSeek V4.1 Flash and GLM 5.3 Flash it reads screenshots and diagrams. Thinking is off by default; switch it on when you need it. Its context is 128K rather than 1M, so it is not the pick for whole-repository agent runs.
Test before you commit
Every abliterated build is tested by whoever made it, on prompts they chose. Your workload is different. Before you settle on a model:
- Run ten or twenty of your real prompts, including the ones that got refused elsewhere.
- Check the output, not just the absence of a refusal. Compliance and correctness are separate questions.
- For agents, run a real task end to end and watch the tool calls.
- Compare reasoning effort levels. Higher effort costs more tokens and often pays for itself on hard tasks.
The full list, with context and feature details, lives on /models.
How to try one
XField serves all four models through the OpenAI and Anthropic APIs, so existing SDKs and agents work after you change the base URL and key. We do not store your prompts or completions; each request leaves a usage record of model, token counts, timing, and cost, never the text. We do not train on your content.
- Request access
Access is by invitation. Tell us what you are working on at /request-access. Pricing is shared with your invitation.
- Create a key
Sign in and create a key in Settings › API keys. It is shown once, so store it somewhere safe.
- Send a request
Follow the quickstart for your SDK or agent.
A first request looks like this:
curl "https://xfield.cloud.brutal.ai/api/v1/chat/completions" \
-H "Authorization: Bearer $XFIELD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4.1-flash-1017-uncensored",
"messages": [
{ "role": "user", "content": "Write Sigma rules that detect credential dumping from LSASS." }
]
}'Swap the model id to try the others. The question you were asking is the one you will get answered.