Start now

Uncensored AI for Developers: Build Without Refusals

Uncensored AI for developers moves the content rules from the model to your application. That gives you freedom and it gives you the job of writing and enforcing those rules.

Last updated

Data blocks passing through checkpoint gates before reaching a terminal, illustrating a moderation layer

Key facts

  • Write your product's rules in a system prompt and check them in code.
  • Add your own input and output checks, since the model will not do all of it for you.
  • Log request IDs, token counts and a hashed user ID, not raw conversations, unless you need them.
  • You remain responsible for your users and your jurisdiction. Sexual content involving minors is never allowed.

What changes when the model stops refusing

With a mainstream assistant the vendor decides what is acceptable and the model declines the rest. With an uncensored model, tuned to answer without content refusals for lawful adult use, that layer is gone. Uncensored AI for developers is useful for fiction tools, companion apps, research on model behavior and any product where mainstream refusals get in the way of lawful work.

What replaces the vendor's filter is your own design. You decide who may use the app, what the model may write, and what you do when something goes wrong. This article covers four parts of that job: the system prompt, a moderation layer, logging and your responsibilities.

Start with a system prompt that states the rules

A system prompt is your first and cheapest control. Write it like a short policy, in plain sentences, and keep it stable between releases so behavior is easy to reason about.

  • Role and setting. Who the assistant is and what the product is for.
  • Audience. State that all users and all characters are adults.
  • Boundaries. List what the assistant must not write in your product, for example content involving minors, real private individuals, or instructions for harming others.
  • Format. Length, tone, language, what to do when asked something out of scope.
SYSTEM = '''You are the narrator of an interactive fiction app for adult readers.
All characters are adults. Never write sexual content involving minors.
Do not write about real, named private individuals.
If a request is outside the story, say so briefly and return to the scene.
Keep replies under 200 words.'''

A system prompt is guidance, not a guarantee. The model can drift, and users can push against it. That is why the next layer exists.

Build a moderation layer around the model

Check text twice: before it reaches the model and after the model replies. Cheap rules catch the obvious cases, and a second model call can judge the gray ones. JSON mode makes the verdict easy to parse.

import json
from openai import OpenAI

client = OpenAI(base_url="https://api.bestuncensored.com/v1", api_key="YOUR_KEY")

BLOCKLIST = ["example banned phrase"]  # your own rules

JUDGE = '''Classify the text. Reply with JSON: {"verdict": "allow" or "block", "reason": "short"}.
Block if it sexualizes anyone under 18, or asks for real-world harm.'''

def judge(text):
    r = client.chat.completions.create(
        model="uncensored",
        messages=[{"role": "system", "content": JUDGE}, {"role": "user", "content": text}],
        response_format={"type": "json_object"},
        temperature=0,
    )
    return json.loads(r.choices[0].message.content)

def safe_reply(user_text, system):
    low = user_text.lower()
    if any(b in low for b in BLOCKLIST) or judge(user_text)["verdict"] == "block":
        return "That request is outside what this app allows."
    r = client.chat.completions.create(
        model="uncensored",
        messages=[{"role": "system", "content": system}, {"role": "user", "content": user_text}],
    )
    out = r.choices[0].message.content
    if judge(out)["verdict"] == "block":
        return "That reply was withheld by the app's content rules."
    return out

Judge calls cost tokens like any call: at $0.15 per 1M input and $0.50 per 1M output, a 300 token check with a 20 token verdict costs 300 x $0.15 / 1,000,000 + 20 x $0.50 / 1,000,000 = $0.000045 + $0.00001 = $0.000055. Two checks per message add $0.00011, which is small next to the reply. No filter is perfect, so keep a report button and review flagged items.

Logging without hoarding

You need logs to debug, handle abuse reports and watch costs. You do not need every conversation in plain text, and storing them creates risk for you and your users. Prompts sent to this API are not used for training, but your own logs are your own responsibility.

A sensible default is to log metadata: time, a hashed user ID, the X-Request-Id response header, token counts and the moderation verdict. Store full text only for flagged items, with a short retention period.

import hashlib, logging

log = logging.getLogger("llm")

def logged_call(user_id, messages):
    raw = client.chat.completions.with_raw_response.create(
        model="uncensored", messages=messages
    )
    resp = raw.parse()
    log.info(
        "user=%s req=%s in=%s out=%s balance=%s",
        hashlib.sha256(user_id.encode()).hexdigest()[:12],
        raw.headers.get("x-request-id"),
        resp.usage.prompt_tokens,
        resp.usage.completion_tokens,
        raw.headers.get("x-balance-usd"),
    )
    return resp.choices[0].message.content

The request ID is what you quote if you ever contact support about a specific call.

Responsibilities you keep

This is general information, not legal advice. Talk to a lawyer about your own case. These points apply to most products built on an uncensored model:

  • The hard line. Sexual content involving minors is never allowed on this service, and no system prompt changes that. Treat it as a line in your own product too.
  • Age gating. If your product contains adult material, verify or at least gate by age in a way that suits the places you operate in.
  • Local law. Rules on adult content, data protection and recordkeeping differ by country and state. They apply to you and your users, wherever the API runs.
  • Terms and privacy. Publish your own terms and privacy notice. Read the provider's too: terms and privacy.
  • Keys. Keep API keys on your server, never in a browser or app bundle.

Abuse, reports and rate limits of your own

Once real users arrive, some will try to push the product past your rules. Plan for this on day one.

  • Per-user limits. Cap messages per day and requests per minute per account. This protects your budget and slows down automated abuse. Your own limits should sit below the API's: a full key allows 300 requests per minute across all users.
  • A report button. Let users flag a reply. Store the request ID and the text of the flagged exchange, and review the queue on a schedule.
  • Escalation. Decide in advance what happens after repeated violations: a warning, a temporary block, a ban. Write it in your terms.
  • Key hygiene. Once your account has topped up you can hold up to 5 labeled keys, so use one per environment. Never ship a key in client code. Regenerate a key on the key page if it may have leaked; the old one stops working at once.

Your queue will also show you where the system prompt is weak. When the same kind of flagged output appears three times, change the prompt or the filter, then rerun your test set to make sure nothing else broke. Treat prompts like code: keep them in version control and note what each change was for.

Plan for limits and failures

Production code needs backoff. A full key allows 8 concurrent requests and 300 requests per minute. Over a limit the API returns HTTP 429 with code rate_limited or concurrency, and on temporary overload a 429 with Retry-After: 5. Respect that header. If you run a judge call and a reply call per message, both count against the limits, so size your queue for double the requests.

Failed or refused requests are not charged, so retries cost nothing for failed attempts. The docs list parameters, and you can try everything with the trial credit from the API key page. For options in this space, see uncensored AI options compared.

A pre-launch review

Before real users arrive, walk through one scripted session as an attacker would. Try to get the app to produce something your rules forbid, by asking directly, by role play, by splitting the request across turns and by pasting text that contains instructions. Record what slips through and fix it at the right layer.

  • If the model ignores a rule in the system prompt, tighten the wording and add a check in code.
  • If a check blocks too much lawful content, loosen the rule or add an allow path, and measure the false block rate on a sample of real prompts.
  • If the issue only appears in long chats, test with a full history, since rules drift as the context grows. A 100,000 token window gives you room to keep the rules near the top and repeat a short reminder near the end.

Repeat this review whenever you change the prompt, the filter or the model setting. Keep the test cases in a file and run them as an automated check, so a change that breaks a rule fails before it ships.

Technical FAQ

Obtain your API key

Register, retrieve your key, and update your endpoint URL. Simple.

Does an uncensored model remove my need for moderation?
    No. It removes the vendor's refusals, so the rules become yours. Add system prompt rules and input and output checks that fit your product.
Can I use a second model call as a filter?
    Yes. Use JSON mode with a short instruction and low temperature, and parse the verdict. Each check costs a small number of tokens.
Are my prompts used for training?
    No. Prompts are not used for training.
What is never allowed?
    Sexual content involving minors. The service is for lawful adult use.
Should I log full conversations?
    Only when you have a clear reason. Metadata such as request ID and token counts is usually enough, with full text kept for flagged items only.