What is an uncensored LLM API?

An uncensored LLM API is a language model you call over HTTP that answers the question you asked. You send a prompt about malware analysis, a violent scene in a novel, or a phishing email for your own awareness training, and you get the work back instead of a paragraph about why the model would rather not.

Everything else is meant to feel ordinary. Same SDKs, same request shapes, same streaming. This guide explains what the label actually means, where refusals come from in the first place, and how to tell whether a provider has removed them or only says it has.

Uncensored, abliterated, unrestricted

You will see three words used for roughly the same thing. They are not quite synonyms.

• Uncensored is the everyday word. It describes behavior: the model does not refuse ordinary requests on sensitive topics. It says nothing about how that was achieved.
• Abliterated is the technical word. It means the refusal behavior was edited out of the model's weights directly, without retraining it on new data. The model keeps its knowledge, writing style, and tool-calling format; it loses the reflex to decline. Our guide to abliterated models covers the method in more detail.
• Unrestricted usually describes the service rather than the model: no moderation layer, no content filter, no hidden system prompt telling the model to be careful.

A good uncensored API needs both halves. An abliterated model behind a strict content filter still refuses. A permissive service in front of a model that was trained to refuse still refuses. The label only means something when every layer is addressed.

Where refusals come from

When a hosted model declines your request, the refusal can come from one of three places. Most people only think about the first.

The training layer is the hardest to deal with yourself, which is why abliteration matters. You cannot prompt your way around weights reliably; jailbreaks work some of the time and break whenever the model is updated.

The other two layers are choices the provider makes. This is also why routing an open-weight model through a general-purpose gateway often does not help: the gateway may add its own filter even if the model underneath is permissive. We wrote about that in routers don't remove refusals.

XField serves abliterated open-weight models from DeepSeek, Z.ai, and Qwen, adds no system prompt, and runs no moderation filter on your requests or responses.

What stays the same

Removing refusals should not change anything else about how you integrate. On XField, the API speaks the protocols your tools already use:

• OpenAI Chat Completions at POST /api/v1/chat/completions
• OpenAI Responses at POST /api/v1/responses
• Anthropic Messages at POST /api/v1/messages

Tool calls work on all three, with tools and tool_choice on the OpenAI side and native tool blocks on the Anthropic side. Streaming uses server-sent events everywhere. Reasoning models return their thinking in the format each protocol expects. Errors come back as JSON with a status code you can handle.

In practice that means the OpenAI SDK, the Anthropic SDK, the Vercel AI SDK, LangChain, and coding agents like Claude Code, Codex, and OpenCode work after you change a base URL, a key, and a model id. There is no default model, so every request names one. The full list is on /models.

Who uses one

The people who need this are rarely looking for shock value. They are doing jobs where a refusal is a bug.

• Security researchers reverse engineering malware samples, writing detection rules, and explaining what an obfuscated script does.
• Red teams planning engagements, drafting pretext scenarios, and generating realistic phishing lures for their own organization's training.
• Trust and safety teams labeling abusive content, building classifier datasets, and writing policy examples that have to look like the real thing.
• People running coding agents who are tired of an agent stopping halfway through a long task because a file name or a comment tripped a refusal.
• Writers working on fiction with violence, crime, or morally ugly characters, who want a collaborator rather than a chaperone.

The red-teaming use case walks through one of these in detail.

What is still not allowed

Uncensored does not mean anything goes. It means the model does not decide for you, and the rules live in a written policy instead of a classifier's guess.

Research, red-teaming, testing your own systems, fiction, and frank discussion of difficult topics are welcome. Using the API to cause real harm to real people is not. The details are in our acceptable use policy, and every account confirms it before using the API.

What happens to your prompts

Privacy matters more here than with a general chatbot. The prompts people send to an uncensored API often contain samples, exploit notes, abuse reports, or unpublished manuscripts.

XField does not store API prompts or completions. Each request leaves a usage record with the model, token counts, timing, and cost. It never contains the text. We do not train on your content.

How to evaluate a provider

Marketing pages all say the same thing. A few checks separate them quickly.

Refusal rate on your own prompts

Do not trust a published benchmark. Take 20 to 50 prompts from your actual work, especially the ones that get refused today, and run them through each provider. Count refusals, partial answers, and responses that comply but quietly water the task down. Run each prompt more than once, because refusals are often inconsistent.

Data retention

Find out exactly what is kept and for how long. "We don't train on your data" is not the same as "we don't store your data." The answer you want is that prompts and outputs pass through and only metering data stays.

Compatible APIs

Check which protocols are supported, not just "OpenAI-compatible." If you use an Anthropic-native agent, you want the Messages API. Then test tool calls and streaming with your real client, since that is where partial compatibility shows up.

Context length and output limits

Agents and long documents need room. Check the context window and the maximum output per model, and whether reasoning tokens count against it. A model that refuses nothing but runs out of context halfway through a codebase is not much help.

Model quality

Removing refusals does not make a model smarter. A small abliterated model will attempt a hard task and do it badly. Ask which base models are served and pick by the job, not by the label.

How to try it

1. Request access

   Access is by invitation. Ask at /request-access and tell us what you are working on. Pricing is shared with your invitation.

2. Create a key

   Sign in at /sign-in and open Settings › API keys. The key is shown once, so store it as XFIELD_API_KEY.

3. Send a request

   Point your existing SDK at https://xfield.cloud.brutal.ai/api/v1 and name a model.

import os
from openai import OpenAI
 
client = OpenAI(
    base_url="https://xfield.cloud.brutal.ai/api/v1",
    api_key=os.environ["XFIELD_API_KEY"],
)
 
response = client.chat.completions.create(
    model="deepseek-v4.1-flash-1017-uncensored",
    messages=[
        {"role": "user", "content": "Explain what this PowerShell one-liner does: ..."}
    ],
)
print(response.choices[0].message.content)

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 a Sigma rule for suspicious LSASS access."}]
  }'

Then run your own refusal test. It is the only benchmark that matters for your work. For a full setup walkthrough, start with the quickstart.