Workflows/Create Uncensored AI Bots with Rakazo

Agents / WORKFLOW

Create Uncensored AI Bots with Rakazo

Create persistent Rakazo bots with Huihui’s uncensored Qwen3 8B. Choose local Ollama or the documented 48 GB RunPod Serverless Load Balancer vLLM setup.

Verified sourceSource checked 10/18/2026

LOCALRENTED GPU

Freshness 13 out of 100. Repository age: 539 days old, Apr 27, 2025. Measures age, not quality.

Popularity 93 out of 100. 9,122,623 downloads in 30 days; 2,121 lifetime likes. Checked Oct 18, 2026. Measures adoption, not quality.

What do these scores mean?

Two ways to compare models. Neither score measures answer quality, benchmark performance, or whether a model fits your machine.

Freshness · release age

A new release starts at 100. The score halves every 180 days: 100 × 2^(−age in days / 180). When the release date is unavailable, a repository date is a fallback—not proof of when the model was released. Missing dates stay unscored.

Check the date source

Popularity · adoption

Downloads over the past 30 days carry 80% of the score; lifetime likes carry 20%. Both use a logarithmic scale, capped at 10 million downloads and 100,000 likes. If likes are unavailable, downloads carry all the weight. Missing download statistics stay unscored.

round(80 × min(1, log10(1 + downloads) / 7) + 20 × min(1, log10(1 + likes) / 5))

Check the statistics source

Scores as of Oct 18, 2026. Statistics checked Oct 18, 2026. Statistics are marked for refresh after 72 hours.Full scoring method

Before you begin

Hardware

Choose the serving route. A configured context ceiling is not a benchmark of 128K prompt speed or quality.

Machine	Package and memory	Context
Local Mac / PC · 16 GB+ system memory	Ollama quantized package · around 5 GB weights, plus runtime/context	Match Rakazo to the context configured in Ollama
RunPod · one 48 GB GPU	BF16 · vllm/vllm-openai:v0.11.0	131072 configured with YaRN; memory use grows with context

SELF-HOSTED BOTS / LOCAL OR RENTED INFERENCESOURCE-LINKED SETUP

Create Uncensored AI Bots with Rakazo

Run Rakazo on your computer with Huihui’s Qwen3 8B Abliterated. Choose local Ollama or a RunPod Serverless Load Balancer, connect the model, and create persistent AI bots.

Choose a package Run its commands Check the result

BEFORE YOU BEGIN

The documented package

This setup uses the package documented for this task. Review its source and supported platforms before starting.

These requirements describe the GPU you rent. Use Windows, Mac or Linux as the browser client; your saved computer’s VRAM does not limit this setup.

CURRENT SETUP

Qwen3 8B · Uncensored Variant · community-modified weights

Local quantized weights are around 5 GB before runtime and context. The 128K configured context belongs to the 48 GB RunPod BF16 recipe, not the local 16 GB starting point.

Freshness unavailable. Date pending.

Popularity unavailable. Stats pending.

What do these scores mean?

Two ways to compare models. Neither score measures answer quality, benchmark performance, or whether a model fits your machine.

Freshness · release age

Check the date source

Popularity · adoption

round(80 × min(1, log10(1 + downloads) / 7) + 20 × min(1, log10(1 + likes) / 5))

Check the statistics source

Scores as of Oct 18, 2026. Statistics check pending. Statistics are marked for refresh after 72 hours. These statistics are due for a refresh.Full scoring method

View weight source

THE WORKFLOW

Set up Qwen3 8B · Uncensored Variant from your own computer

Run the app on your own computer; only model inference runs on the rented GPU. The instructions below update to match your selection.

CHOOSE YOUR SETUPRented GPU

Rakazo runs on your Mac/PC; RunPod runs model inference on one 48 GB GPU.

Before you begin

A computer with Docker Desktop (Mac/Windows) or Docker Engine + Compose plugin (Linux), plus curl and OpenSSL. On Windows, use the WSL2 Ubuntu shell for the commands below. A RunPod account with billing enabled if using the cloud route. Access to the Hugging Face model. At the time of this guide, the model page states that access requires accepting its conditions. Accept them while signed in, and create a Hugging Face read token if needed for worker downloads. This is not your RunPod API key. A RunPod API key for requests to the hosted endpoint. Create one from RunPod credentials, or from the endpoint Test → Generate key control if present. In the RunPod console, open Settings → API Keys (credentials), or use the endpoint Test → Generate key control if shown.

Docker Desktop Get started on RunPod · affiliate Accept the Huihui model conditions

Prepare your local terminal

Rakazo stays on your computer. Mac: start Docker Desktop and use Terminal. Linux: start Docker Engine with the Compose plugin and use Bash. Windows: install WSL2 with the command below in Administrator PowerShell, then open Ubuntu and enable Docker Desktop’s Ubuntu WSL integration. All subsequent shell commands run in Bash. On macOS, enter bash before the hidden API-key prompt.

Docker Desktop for Windows

PowerShell

wsl --install -d Ubuntu

Install Rakazo locally

Start Docker. Then use Terminal (macOS/Linux) or Ubuntu WSL2 (Windows): Open http://127.0.0.1:5173. Create your local Rakazo account. The published-images installer generates .env with secrets and starts the web app, API, worker, database, and default Docker computers. It does not require a separate Node.js install. Keep the .env and Docker database volumes if you want to preserve bots, accounts, and history. See the official Rakazo quick start. Already installed? Do not reinstall or delete volumes. Open Docker Desktop and start your existing stack. For the published-images install, from ~/rakazo you can use docker compose --env-file .env -f docker-compose.images.yml up -d.

official Rakazo quick start

Bash

mkdir -p ~/rakazo && cd ~/rakazo
curl -fsSLO https://raw.githubusercontent.com/elie222/rakazo/main/infra/compose/install-images.sh
bash install-images.sh

Create a RunPod Load Balancer endpoint

In RunPod, go to Serverless → New Endpoint / Create an endpoint → Docker / Deploy from container image. Choose Load Balancer for direct HTTP requests, not Queue (/run or /runsync). Do not choose Deploy from LLM API for this recipe.

RunPod's endpoint types load-balancing worker documentation

Configure the container image

Paste the flags below into RunPod’s Container start command field. Do not prefix them with docker run or vllm serve; the image supplies the entry point. Qwen3 8B has 32,768 native context and supports 131,072 with YaRN scaling. Use both the context limit and scaling arguments below. This is the BF16 model, not a 4-bit quantized checkpoint.

Setting	Value
Container image	vllm/vllm-openai:v0.11.0
Registry authentication	No credentials (public image)
Container disk	128 GB (image, model download, and compilation cache)
Expose HTTP ports	8000 only
Expose TCP ports	Leave blank
Endpoint type	Load Balancer, not Queue
Health check endpoint	/health

Qwen3 model card — long contexts vLLM 0.11 arguments

Plain text

--model huihui-ai/Qwen3-8B-abliterated --max-model-len 131072 --rope-scaling '{"rope_type":"yarn","factor":4.0,"original_max_position_embeddings":32768}' --enable-auto-tool-choice --tool-call-parser hermes

Set environment variables and health routing

Enter each environment variable below as a separate key/value pair. Add HF_TOKEN with your Hugging Face read token after accepting the model’s access conditions; use RunPod’s Secret selector where available. HF_TOKEN is not your RunPod API key. Expose HTTP port 8000 and keep PORT and PORT_HEALTH set to 8000 so requests and health checks reach vLLM.

verified RunPod load-balancer path

Plain text

PORT=8000
PORT_HEALTH=8000
HEALTH_CHECK_PATH=/health

Select the GPU and workers

Select CUDA 12.8 and newer available versions. Incompatible hosts can fail with an unsatisfied cuda>=12.8 requirement. Apply the settings below and click Deploy. Choose Load Balancer when creating the endpoint; its type cannot be changed from Queue afterward.

Setting	Value
Compute type	GPU
GPU configuration	Select a 48 GB GPU tier with availability (one GPU per worker)
GPU count	1
Max workers	1
Active workers	1 (avoids a scale-from-zero wait, billed even when idle)
Idle timeout	Leave its default (irrelevant to keeping an active worker always on)
Execution timeout	600 seconds; this does not guarantee the HTTP request timeout
Scaling type	Request count (the supported mode for Load Balancer endpoints)
Allowed CUDA versions	12.8 and newer, not All versions
Cached model / volumes	Optional for this setup

RunPod CUDA scheduling guidance

Wait for the model, not just the worker

Open Workers → Logs and look for the configured model length and Application startup complete. KV cache capacity varies with the GPU and runtime; the number below is an example, not a required value. Cold starts can take several minutes for downloads and compilation. A Running status alone is not enough: test the API next. In Releases, confirm that the running worker uses your latest configuration. A 128K serving limit does not guarantee long-prompt speed or quality.

Plain text

Using max model len 131072
GPU KV cache size: 194,656 tokens
Application startup complete.

Test it inside RunPod

Open the endpoint → Test, select GET, enter /v1/models, and click Send. Look for HTTP 200, huihui-ai/Qwen3-8B-abliterated, and max_model_len: 131072. Do not use GET /: vLLM can return 404 at the root while healthy. Next, use Terminal to test actual generation.

Setting	Value
Method	GET
Application path and query	/v1/models

Test actual generation from Mac / Linux Terminal

Use Bash: in macOS Terminal, enter bash first; on Windows use Ubuntu WSL2. Find the endpoint ID on RunPod’s Overview page and replace the placeholder below. Enter your RunPod API key at the hidden prompt. Look for HTTP 200 and a generated reply in choices[0].message.content. Create the API key in RunPod credentials or the endpoint’s key-generation control; creating an endpoint does not automatically create a new key.

Bash

export RUNPOD_ENDPOINT_ID='REPLACE_WITH_YOUR_ENDPOINT_ID'
printf 'RunPod API key: '
read -rs RUNPOD_API_KEY; echo

curl -sS -i --max-time 60 \
  "https://${RUNPOD_ENDPOINT_ID}.api.runpod.ai/v1/chat/completions" \
  -H "Authorization: Bearer ${RUNPOD_API_KEY}" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "huihui-ai/Qwen3-8B-abliterated",
    "messages": [{"role": "user", "content": "Say hello in one sentence."}],
    "max_tokens": 100,
    "stream": false
  }'

unset RUNPOD_API_KEY

Connect the RunPod API to Rakazo

Rakazo blocks public OpenAI-compatible servers unless explicitly allowed. Open ~/rakazo/.env and find:

Plain text

# RAKAZO_OPENAI_COMPAT_ALLOW_PUBLIC=1

Enable the public endpoint setting

Remove the leading # and space so the setting actually takes effect:

Plain text

RAKAZO_OPENAI_COMPAT_ALLOW_PUBLIC=1

Restart Rakazo and enter the connection settings

Then, from the Rakazo installation folder, restart the API and worker containers so they read the changed environment: Do not use docker compose down -v; that deletes persistent volumes and can remove your database. Rakazo's self-hosting documentation and .env.example explain the public-host gate. In Rakazo → Settings → Models → Connect a model, fill the actual on-screen fields: Choose Continue. You can Skip Server integrations for web search and scheduled routines; Rakazo includes web_search, web_fetch, and scheduling tools. Gmail, Calendar, and other connected services are separate integrations. Sources: Rakazo built-in web tools, Rakazo self-host.

Setting	Value
Provider	OpenAI-compatible
Server URL	https://ENDPOINT_ID.api.runpod.ai/v1
Model	huihui-ai/Qwen3-8B-abliterated
Supports thinking	Off
Maximum output tokens	2048
Context limit	131072
Supports images	Off (text-only model)
API key	The RunPod rpa_... API key (not HF_TOKEN)

self-hosting documentation Rakazo built-in web tools Rakazo self-host

Bash

cd ~/rakazo
docker compose --env-file .env -f docker-compose.images.yml \
  up -d --no-deps --force-recreate api worker

Test the agent, not just chat

Create a bot using the RunPod model. For a first, non-destructive tool test, ask: Use web_fetch to read the public homepage at https://example.com. Report the page title and URL, and tell me which tool you called. Then check the actual tool activity, not just the model's text. A bot that says it fetched a page without an executed tool has not passed this test. Next, test local bot-computer access: In your sandbox, create test.txt containing Rakazo tool test, read it back, and quote the file's contents. Show the tools used. If the bot asks for unrelated GitHub credentials, do not provide them. A GitHub login is not required to use Rakazo's built-in public web tools. This is a model/tool-selection limitation, not evidence that the RunPod API is down. Sources: Rakazo Docker and web-tool instructions, tool definitions. For authorized security testing, constrain the scope to a domain you control, begin with non-destructive public-page and response-header checks, and require evidence for findings. Do not claim an automated pentest succeeded without executed tools and validated findings.

Rakazo Docker and web-tool instructions tool definitions

MORE WAYS TO USE THIS SETUP

Phone, routines, and uptime

RunPod hosts the model, not Rakazo’s backend.

Keep the backend running and manage GPU billing

RunPod runs only the language model. Rakazo's API, database, memory, schedules, and bots still run on your local computer. If that computer is off, your mobile Rakazo app cannot use its backend or run scheduled routines, even though RunPod remains online. To run 24/7 and use the phone away from home, deploy Rakazo itself to an always-on host with HTTPS and proper access controls; see Rakazo's server guide. Billing: For immediate availability, Active workers = 1 avoids scale-from-zero delays but incurs continuous GPU charges. When finished, reduce active workers to zero (if you accept cold starts) or disable/delete the endpoint if no longer needed. Merely closing Terminal, the RunPod browser tab, or Rakazo does not stop an always-on GPU worker.

Rakazo's server guide

MORE WAYS TO USE THIS SETUP

What runs where?

Your local bots and remote inference have different responsibilities.

Rakazo API / database / worker

Local Mac/PC (or optional always-on host). Accounts, bot state, memory, schedules, history, tool orchestration

Rakazo Docker computer

Same host / configured sandbox backend. Browser, shell, files, execution

Ollama (optional)

Local Mac/PC. Local model inference

RunPod vLLM Load Balancer

Remote GPU. OpenAI-compatible model inference; does not store Rakazo accounts

Rakazo mobile app

Phone. Client connecting to the same Rakazo backend

MORE WAYS TO USE THIS SETUP