LiteLLM with an uncensored OpenAI-compatible endpoint

How LiteLLM reaches an OpenAI-compatible endpoint

LiteLLM picks a provider from the prefix on the model name. For any server that speaks OpenAI's /chat/completions, the prefix is openai/, followed by that server's own model id. The OpenAI-compatible endpoints doc puts it in one comment: add the prefix "so litellm knows to route to OpenAI".

The same doc says to leave the base URL alone apart from the /v1 suffix. Every uncensored build in this catalog takes the OpenAI wire format, so one prefix covers all of them. Version checked: litellm 1.106.3, the current release on PyPI on 25 October 2026.

The three values LiteLLM needs

model

openai/glm-5.3-uncensored

openai/ plus any id from the models page

api_base

https://api.uncensoredllm.ai/v1

Ends in /v1; nothing after it

api_key

sk-ullm-live-…

Created in the console; keep it in ULLM_API_KEY

Create the key in the console. It starts with sk-ullm-, is shown once, and spends a prepaid balance that starts at $10. Model ids are on the uncensored model list.

Call the endpoint from the LiteLLM Python SDK

One call, no config file. The response has the OpenAI shape, so code written for the OpenAI SDK reads it the same way.

Swap the id after openai/ to change builds. Nothing else in the call changes, because every build sits behind the same base URL and key.

A fallback chain across three uncensored builds

The Router takes a list of named deployments and a fallbacks map. Per the reliability doc, a call that still fails after num_retries moves to the next name, and fallbacks run in order.

Two details decide whether the chain helps. First, all three entries use the same key, so a 401 or a 402 comes back the same from every build; fallbacks cannot fix those. They help when one build fails on its own: a 404 for an id that left the catalog, a 429, a 5xx or a timeout. Second, the docs page states that a request that fails before the model answers is not charged. A request that falls through is billed once, at the price of the build that answered.

The names are aliases. Your application asks for uncensored-primary and never sees a model id, so moving to another build is one line in the list, not a change to the app. num_retries=1 gives a failing build one more try before the chain moves on. A retry that fails before the model answers is free as well, so the setting costs latency, not money.

The same chain in the LiteLLM proxy config.yaml

The proxy reads the same deployments from a file and serves them on an OpenAI-format endpoint of its own. The os.environ/ form reads a value from the environment, which keeps the key out of the file. The prices under model_info are this catalog's, written into the file when this page rendered, so LiteLLM's spend tracking matches what the API charges.

The proxy listens on port 4000. Point any OpenAI SDK at it with the master key, and ask for uncensored-primary as the model. LiteLLM's custom pricing doc marks the two *_cost_per_token keys as tracking only; they change nothing about what is billed.

Context window and content policy fallbacks

context_window_fallbacks handle LiteLLM's ContextWindowExceededError. The reliability doc requires enable_pre_call_checks: true under router_settings for that check, and without it requests go to the provider whatever their size. The check needs a window to compare against, and the three builds above publish none in the catalog. For a context fallback, add a fourth entry for minimax-m3-uncensored, which lists 262,144 tokens, and map uncensored-primary to it.

content_policy_fallbacks fire on a provider's content-filter error, LiteLLM's ContentPolicyViolationError. Mapping a filtered model on another provider to uncensored-primary sends those requests here. A refusal written into a normal reply is a successful response, not an error, so no fallback sees it.

Which uncensored builds to chain

Put the build you want most first: the backups bill only on the requests that reach them. When this guide was written, all three had been steady since 12 October on the daily real-model check, which sends a fixed prompt to every model each day and records whether the answer still matches. The column below is today's verdict.

Windows from the live catalog on 2026-10-27; verdicts from /proof at render.

Two GLM builds and a DeepSeek build means a family outage on one side still leaves an answer. The rest of each family is on the uncensored GLM and uncensored DeepSeek pages.

What a batch through the chain costs

The worked example: 10,000 requests of 1,200 prompt tokens and 350 reply tokens, all answered by one build.

Computed at render from the catalog prices on 2026-10-27: requests × 1,200 × input price, plus requests × 350 × output price.

A real month sits close to the first row, plus a backup's price on the requests that fall through to it. Every per-token rate is on the pricing page.

Check the key before LiteLLM

This lists the ids the key can call. It is free; run it before blaming the config.

A 200 with a list of ids means the key and base URL are right. A 401 says which way the key is wrong:

Both bodies as the API returned them on 25 October 2026.

Troubleshooting LiteLLM errors on this endpoint

LiteLLM maps each status to an exception class, per its exception mapping doc: 401 is AuthenticationError, 402 is PaymentRequiredError, 404 is NotFoundError, 429 is RateLimitError.

Not Found on every call

The OpenAI-compatible doc's advice: make sure api_base ends in /v1. Check also that the model name starts with openai/.

404 model_not_found on one build

The id after openai/ is not in the catalog. The chain moves on to the next build; fix the id from the list the curl above prints.

402 insufficient_balance

The prepaid balance is at zero, so every build in the chain answers the same. Top up in the console; a refused request is not charged.

Questions