Uncensored AI models and LLMs

Base models, instruct models, and where refusal enters

A model is pretrained on a very large amount of text, which gives it language, facts and reasoning but no notion of being an assistant. A base model does not answer questions so much as continue text. It has no concept of refusal because it has no concept of being asked.

The assistant is created afterwards, by fine-tuning on conversations and then on human or model preferences. This is where the model learns to be helpful, to follow instructions, to keep a persona — and, in the same pass, to decline. Refusal is not a rule bolted on top; it is a habit learned alongside every other conversational habit, from the same process.

That is the reason removing it is delicate. The refusal behaviour and the instruction-following behaviour were installed together, and a clumsy attempt to remove the first damages the second.

The two ways refusal gets removed

Both require open weights. You cannot modify a model you can only reach through an API, which is why every model in this category is an open-weight one.

Fine-tuning

Continue training on examples where the assistant answers rather than declines. Straightforward, and blunt: you are moving a large number of weights that also encode other behaviour, so quality elsewhere can degrade. Done well it works; done carelessly it produces a model that complies and is noticeably worse at everything.

Refusal-direction removal

Refusal turns out to be represented compactly inside the model — close to a single consistent direction in its activation space, identifiable by comparing internal states on prompts it accepts against prompts it declines. Suppress or project out that direction and the behaviour goes with it, leaving the rest of the model largely untouched. Published work describes this as ablating the refusal direction; it is widely reproduced and now the more common approach.

The second method is why a well-made uncensored model is not a downgrade. It is the same model with one narrow reflex turned down, rather than a differently trained one.

What the removal costs

Honestly: something, usually small, and worth knowing about.

Refusal training and calibration are entangled. A model trained to decline when uncertain is partly trained to notice uncertainty, and reducing the first can make the second quieter. In practice this shows up as a model that is slightly more willing to give a confident answer where a hedge was warranted — which is exactly the failure mode you should be watching for anyway.

The other cost is variance. Refusal training makes behaviour predictable across a whole category of prompts. Remove it and responses in that category become as variable as responses anywhere else, because the model is now sampling rather than following a learned script.

The properties that matter beyond refusal

Choosing a model on refusal alone is how people end up with a permissive assistant they stop using after a week. Four other properties determine whether it is any good.

Context window

How much of the conversation the model can still see, measured in tokens. This is the hard ceiling on long work. A token is roughly three quarters of an English word, and both your messages and the model's replies consume the budget.

Reasoning

Whether the model works through a problem before answering. This measurably helps on multi-step tasks and costs latency on everything else, which is why it belongs on a separate model rather than switched on everywhere.

Instruction following

Whether four constraints in a prompt produce four constraints in the output. The least glamorous property and the one you notice most.

Sampling configuration

Temperature, nucleus and repetition penalties change behaviour substantially. A model that loops or drifts is often misconfigured rather than bad — which is a property of the platform, not the weights.

Quantisation, and why the same model differs between hosts

Models are usually served compressed. Quantisation reduces the numeric precision of the weights so a model fits in less memory and runs faster, at some cost in quality. The cost is small at moderate compression and becomes obvious at aggressive levels, showing up first in exactly the places you would not want: long-range coherence, arithmetic, and code.

This is a large part of why the same open model feels different on two services. One may be running it at a compression level chosen to maximise how many users fit on a GPU. Serving configuration — quantisation, context limit, sampling defaults, chat template — is as much a product decision as which weights were downloaded.

The three Tartarus AI models

Selected per conversation from the model picker. Which you can reach depends on your plan.

All three are configured so refusal is not the constraint. They differ in whether they think before answering and in what their sampling is tuned for, not in how permissive they are.

Running one yourself

Worth saying plainly, because for some readers it is the right answer. Open-weight models with reduced refusal training are freely downloadable, and the tooling to run them locally is mature. If your requirement is that content never leaves your machine, that is the only approach that actually guarantees it.

The trade-offs are the usual ones. A capable model needs substantial VRAM, and the size you can run is set by the hardware you buy. You become responsible for serving configuration, updates and uptime. And you lose the things a service adds around the model — history, search, an API with quotas, a stop button that actually stops generation upstream.

A hosted service is the same trade as any hosted service. It is worth making deliberately rather than by default.