Open-source project
techjarves/Uncensored-Local-Studio avatar
techjarves/Uncensored-Local-Studio

Uncensored AI Studio: a bundled desktop shell for Stable Diffusion, llama.cpp, Whisper and Kokoro

Uncensored local AI studio for Windows, Linux, and macOS. Zero-setup GUI for Image Generation, GGUF LLMs, Text to Speech & Speech to Text

1,327 stars335 forksJavaScriptMIT

At a glance

What is it?
The project packages four local inference engines behind one Electron-style GUI and auto-selects a GPU or NPU backend. The interesting decision is mutual exclusivity between the image and text engines, and the hard ceiling is single-file checkpoints only.
Who is it for?
Adopt it if you want SD 1.5 or SDXL single-file checkpoints, GGUF chat models, whisper.cpp .bin files and Kokoro TTS behind one installer and you accept that image and text engines cannot run at the same time. Skip it if your workflow depends on Flux, LoRA or ControlNet companion files, or on multi-file diffusion pipelines, because the README lists those as unsupported.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 18 days ago.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What problem the bundled studio is trying to remove

Running local image, chat, speech and voice models usually means four separate installs. Each has its own Python or C++ toolchain, its own model directory convention, and its own way of picking a compute backend. The README frames Uncensored AI Studio as the opposite: a zero-setup, self-contained desktop application for Windows, Linux and macOS that ships the runtime, the models and the GPU backends together, with no global system environment changes. The target user is someone who wants Stable Diffusion, a GGUF chat model, Whisper transcription and Kokoro speech synthesis on their own machine without assembling four environments. The project is MIT-licensed and the primary language is JavaScript, which fits the desktop-shell role: the heavy work is delegated to compiled backends, and the app orchestrates them. The name signals the other half of the pitch. The README says it runs with no censorship, tracking, subscriptions or login, and describes inference as local with no internet, telemetry, cloud logging or API keys. That framing is aimed at people who already know they want an offline stack and are choosing between assembling one and downloading one.

Four engines behind one window, and the exclusivity rule

The architecture section is the most useful part of the README because it explains a constraint rather than a feature. Text and image engines are mutually exclusive by default, and the stated reason is memory: loading both at once risks exhausting system RAM or VRAM. In practice you switch workspaces inside the UI. The image workspace runs a dedicated stable-diffusion.cpp backend node with weights in app/models/. The text workspace runs a portable llama.cpp server with .gguf weights in app/llm-models/, and a small Qwen2.5 Coder starter model can be pulled from the Text Chat panel itself. Speech-to-text is a localized whisper-cli process reading models from app/speech-models/, and text-to-speech uses kokoro-js on the server side. So the data flow is not a single pipeline. Each workspace starts its own backend process, reads from its own model directory, and stops when you leave. That design keeps peak memory bounded at the cost of not being able to generate an image while a large language model sits resident, which is exactly the kind of trade-off a bundled app has to make and a hand-rolled setup often avoids by running separate terminals.

Backend selection is automatic, which cuts both ways

The README states that the app auto-detects hardware and loads CUDA for Nvidia, ROCm for AMD, Vulkan for Intel, AMD and Nvidia, Metal on macOS, or OpenVINO for Intel NPUs. A live performance monitor inside the web UI tracks CPU, RAM, GPU and VRAM. Automatic selection is the right default for the stated audience, since choosing between ROCm and Vulkan on an AMD card is a common source of wasted evenings. The cost is that when detection picks wrong, the user has no documented override in the material provided. Nothing in the README describes a settings key, environment variable or config file for forcing a backend. If your card is misidentified, the troubleshooting section is where you would look, and that section was not included in the excerpt available here. Treat automatic backend choice as a convenience you cannot yet audit from the documentation alone.

Supported checkpoints, and the formats that will not load

This is where the project draws clear lines, and the README is unusually direct about them. Stable Diffusion 1.5 checkpoints in .safetensors or .ckpt are listed as best compatibility. SDXL checkpoints work as single files but need more RAM and VRAM. Single-file SD or SDXL GGUF checkpoints are marked limited, and only complete single-file checkpoints are supported. OpenVINO image model folders go in app/openvino-models/ and are Intel NPU only, downloaded through the Model Manager after running the OpenVINO setup. CoreML image models require macOS on Apple Silicon and the CoreML setup path. Then the refusals: Flux, HiDream, Hunyuan, Wan, Qwen Image and Z-Image workflows are listed as No, because they typically need separate diffusion, VAE and text encoder files rather than a one-click checkpoint load. LoRA, ControlNet, VAE-only, text-encoder-only and diffusion-only files are also No, since companion files are not loaded as standalone image models. If your current workflow depends on stacking a LoRA on an SDXL base, this app is the wrong tool, and it says so plainly. The known-good list is short and named: Juggernaut XL v9 Lightning and DreamShaper XL Lightning at roughly 6.6 GB each, DreamShaper 8 and CyberRealistic V8 and Rev Animated at around 2 GB, plus an LCM DreamShaper OpenVINO build at 2.7 GB for Intel Core Ultra NPU testing.

Getting it running: what the documentation actually specifies

The README's Getting Started section branches into Windows Setup, Linux Setup and macOS Setup, and the folder architecture is documented separately. What the supplied excerpt gives concretely is the directory contract rather than the installer commands. Image weights belong in app/models/. GGUF chat models belong in app/llm-models/, and the README notes that vision models may also need a matching mmproj file. Whisper GGML or whisper.cpp .bin models belong in app/speech-models/. Kokoro expects .json manifests plus model assets, with the destination truncated in the excerpt. OpenVINO image folders belong in app/openvino-models/. Models can arrive two ways: paste a Hugging Face URL into the Model Manager, or drag and drop local weights to import them. The README also links a setup and demo video at youtu.be/yeFvP3SWMak. Because the per-platform install commands were not included in the material available here, I cannot state them. Anyone evaluating this should open the repository's Getting Started section directly rather than rely on a summary, and should check whether the Linux and macOS paths carry the same backend coverage as Windows, since OpenVINO and CoreML are platform-bound.

Where the zero-install claim meets reality

Zero-install portability is a real benefit and a real constraint at the same time. Bundling Node.js, the models and the GPU backends means no global environment changes, which is genuinely useful on a locked-down machine or a shared workstation. It also means the app owns its own copies of everything. A bundled llama.cpp build is a snapshot: when upstream adds support for a new quantization format or a new model architecture, you get it when the app ships an update, not when you pull the repository. The same applies to stable-diffusion.cpp and whisper.cpp. The README does not describe an update channel, and no releases were retrieved for this repository, so there is no evidence in the material about how frequently bundled engines get refreshed. That is the maintenance question to ask before committing. The second constraint is disk. Two SDXL checkpoints at 6.6 GB each plus a GGUF chat model plus Whisper weights add up quickly, and the mutual-exclusivity design does not reduce storage, only peak memory.

How it differs from ComfyUI and from a hand-built stack

The closest comparison in the local image space is ComfyUI, which is a node-graph front end where you wire the diffusion model, VAE, text encoders, samplers and LoRAs together yourself. That approach handles Flux, multi-file pipelines and LoRA stacking because the graph makes no assumption about single-file checkpoints. Uncensored AI Studio makes the opposite assumption and gains simplicity from it: pick a checkpoint file, put it in app/models/, generate. The difference is not quality, it is the shape of the input. A graph tool accepts arbitrary component combinations and asks you to understand the pipeline. This app accepts one file and hides the pipeline, which is why the README can list Flux and ControlNet as unsupported without that being a bug. The second comparison is the DIY stack: llama.cpp server in one terminal, a Stable Diffusion web UI in another, whisper.cpp in a third. That setup lets all engines stay resident simultaneously, which this app deliberately prevents. If you routinely switch between chat and image generation in the same minute, the exclusivity rule will annoy you, and a multi-terminal setup is the better fit.

Licence and the cost of keeping four engines current

The repository is MIT-licensed. That covers the application code, and it is a permissive licence with no copyleft obligation on your own work. It does not automatically describe the bundled engines or the model weights. stable-diffusion.cpp, llama.cpp and whisper.cpp are separate projects with their own licences, and the checkpoints named in the README carry their own terms, which vary by model and by source. The README has a Licensing section, and that is the place to check before redistributing a build or shipping it inside a product. I am not giving legal advice here; the point is that an MIT badge on the repository is not a statement about everything in the download. On maintenance, the honest position from the available material is that upgrade cost is unknown. No releases were retrieved, so there is no release cadence to reason about, and the README does not document how backend binaries are versioned or replaced. If you adopt this, the thing to watch is not the GUI. It is whether the bundled llama.cpp and stable-diffusion.cpp builds track upstream closely enough for the models you plan to load six months from now.

Editorial conclusion

Adopt it if you want SD 1.5 or SDXL single-file checkpoints, GGUF chat models, whisper.cpp .bin files and Kokoro TTS behind one installer and you accept that image and text engines cannot run at the same time. Skip it if your workflow depends on Flux, LoRA or ControlNet companion files, or on multi-file diffusion pipelines, because the README lists those as unsupported. Before installing, confirm which backend your hardware maps to (CUDA, ROCm, Vulkan, Metal or OpenVINO), check that your chosen checkpoint is a complete single file rather than a diffusers folder, and read the MIT licence text for the bundled engines rather than assuming one licence covers everything shipped.

Official sources

  1. Issues
  2. License: MIT
  3. README
  4. techjarves/Uncensored-Local-Studio on GitHub
Community notes

Community notes