Model routers and aggregators are useful. One key, one bill, hundreds of models behind a single OpenAI-compatible endpoint. So when a model refuses a request, the natural move is to try another model on the same router. Sometimes that works. Often it doesn't, and it's worth understanding why before you burn an afternoon on it.
What a router actually does
A router takes your request, picks a provider, and forwards it. It may handle retries, fallbacks, and billing. What it doesn't do is touch the model. The weights that answer your prompt are the same weights the lab shipped, and if those weights were trained to refuse, they refuse whether you call them directly or through three layers of routing.
Some hosts also add their own moderation in front of the model. A router can't remove that either; it just passes your request into it.
Browse the catalog of a large aggregator and you'll find very few models described as uncensored, and those that are tend to be small community fine-tunes. That's not a criticism of routers. It's simply not their job to change what a model will say.
Why jailbreak prompts aren't the fix
The next thing people try is a system prompt: a role-play frame, a "you are an unrestricted assistant" preamble, a long list of permissions. It can work for a single chat. It holds up badly anywhere else.
- It's brittle. A prompt that works today stops working after the next model update, and you don't find out until something fails.
- It costs context. Every request carries the jailbreak, and the model spends attention on the frame instead of the task.
- It breaks agents. Coding agents like Claude Code, Codex, and OpenCode bring their own system prompts and tool definitions. Wrapping those in a jailbreak frame confuses tool calling, and a refusal halfway through a 40-step run leaves you with half-applied edits.
- It degrades answers. A model talked into compliance often hedges, moralizes, or quietly does a worse job.
If the refusal lives in the weights, the fix has to live in the weights too.
What actually works
You need two things: weights that don't refuse, and a host that doesn't put a filter in front of them.
Abliteration handles the first part. It finds the direction in the model's activations that drives refusals and removes it, leaving the rest of the model's knowledge and reasoning in place. No prompt tricks, nothing to maintain per request.
Serving those weights without a moderation layer handles the second. And serving them behind the same OpenAI and Anthropic APIs you already use means nothing else in your stack has to change.
| Approach | Refusals | Works with agents | Upkeep |
|---|---|---|---|
| Router + aligned model | Still refuses; the weights decide | Yes, until it refuses mid-run | None, but no fix either |
| Jailbreak system prompt | Fewer, unpredictably | Poorly; fights the agent's own prompt and tools | Constant; breaks on model updates |
| Abliterated model, served directly | Removed at the weights | Yes; standard tool calling, no prompt hacks | None per request |
What to check in an uncensored model
Not every uncensored model is a good one. Before you plan around one, check:
- Size. Many uncensored models are small fine-tunes. Fine for chat, weak on long coding and research tasks.
- Context and output limits. Agents read a lot and write a lot. A short context window or output cap ends runs early.
- Tool calling. Coding agents depend on it. Test it before you commit.
XField serves large abliterated models with long context: deepseek-v4.1-flash-1017-uncensored, glm-5.3-uncensored, and glm-5.3-flash-uncensored at 1M tokens, and the compact qwen-3.8-27b-uncensored at 128K. Tool calls work on all three protocols: Chat Completions, Responses, and Anthropic Messages. See /models for the full list and which one fits which job.
You don't have to leave your router
Keep the router for mainstream models. Point the requests that get refused at an endpoint that serves abliterated weights. Both speak the OpenAI API, so the switch is a base URL and a model id. The rest of the request stays the same.
import os
from openai import OpenAI
client = OpenAI(
base_url="https://xfield.cloud.brutal.ai/api/v1",
api_key=os.environ["XFIELD_API_KEY"],
)
resp = client.chat.completions.create(
model="deepseek-v4.1-flash-1017-uncensored",
messages=[{"role": "user", "content": "Write Sigma rules for this lab's test traffic."}],
)
print(resp.choices[0].message.content)For Claude Code and other Anthropic SDK clients, set the base URL to https://xfield.cloud.brutal.ai/api and send the key as x-api-key.
Get started
The quickstart takes a couple of minutes once you have a key. Access is invite-only for now; request access and we'll get back to you.