Abliteration, jailbreaks, fine-tunes, and system prompts
Abliteration, jailbreaking, fine-tuning, and a system prompt are four different interventions that all get described as "making the model less refused." They act on different objects. Abliteration edits weights. A jailbreak edits one conversation. Fine-tuning continues training. A system prompt, or a gateway in front of the model, adds instructions or filters around an unchanged checkpoint. Picking the wrong one wastes a week and sometimes leaks the thing you were trying to study.
Refuseless is built around the first. The hosted lineup has had refusal behavior removed from the weights. We do not sell jailbreak prompts, we do not run your fine-tune, and we do not operate a policy gateway that rewrites someone else's model. The table is here so you can see the neighbors clearly and decide you wanted this one.
What each one actually changes
| Abliteration | Jailbreak | Fine-tune | System prompt or gateway | |
|---|---|---|---|---|
| What changes | Weights. A refusal direction is ablated or orthogonalized out. | The prompt. The weights stay frozen. | Weights, by further training on examples you chose. | Text around the model, or a filter in front of it. The checkpoint stays as shipped. |
| Survives a new session | Yes. The file changed. | No. A new chat, or a patched template, can restore the refusal. | Yes, if you deploy the new checkpoint. | Only while you keep sending that prompt or routing through that gateway. |
| Adds new knowledge | No. It removes a direction. It does not teach facts. | No. | It can. It can also teach the style and errors of the corpus. | Only whatever you repeat in the prompt. The model does not learn it. |
| Typical failure | A clumsy edit dulls the model or leaves refusals behind. | Brittle. It breaks when the vendor changes the chat template. | The model imitates the fine-tune set, including parts you did not mean. | The model ignores the instruction, or the gateway refuses a request the weights would have answered. |
| When it is the right tool | You want a stable checkpoint that answers a class of prompts the base model refuses. | You are testing a frozen model, on purpose, to see if a prompt breaks it. | You need a new skill, format, or domain the base model lacks. | You want per-request rules, logging, or a block list without touching weights. |
Abliteration
You identify a direction in the activations, often the residual stream, that lines up with refusal, then you remove its influence from the weights. The glossary pages on the refusal vector and orthogonalization are the mechanics. The result is a new checkpoint of the same model. You call it the way you called the base model. On Refuseless that call is chat completions against a lineup id.
Jailbreak
A jailbreak is an input. It may be a long role instruction, a fake policy, or an encoding trick. It tries to move one generation across a line the weights still enforce. Red teams use jailbreaks on purpose against a model they are testing. That is a measurement, not a product. This site does not publish jailbreak strings. If that measurement is your job, the red teaming page is about how to structure the work, not a catalog of prompts.
Fine-tune
Fine-tuning shows the model new examples and updates weights so those examples become more likely. A cyber fine-tune, which is how Adverserial describes CyberKimi and CyberGLM, is this family of change. It can make a model better at a domain. It is not the same operation as ablating a refusal direction, even when both models will discuss security. If you need new behavior the base model never had, fine-tune. If you need the base behavior with the refusal brake lifted, abliterate.
System prompt and guardrails
A system prompt is the cheapest place to put tone, format, and boundaries, and the easiest place for the model to ignore. A gateway is the same idea moved out of the prompt and into the proxy: block, rewrite, log, or rate-limit before and after the model. abliteration.ai sells that second product as a Policy Gateway beside their model API. It is a coherent product for a team that wants an audit trail and per-project rules. It is a different purchase from an abliterated checkpoint. Refuseless does not include it. If you need both, you would run your own rules around our API, and you would say that plainly in your own docs.
Most production setups use more than one row. An abliterated checkpoint plus a short system prompt for format is normal. An abliterated checkpoint plus a jailbreak pasted on every call is a sign the edit did not do what you thought, or that you are testing rather than shipping. Look at which object you meant to change, and change that one.
