stable-diffusion.cpp is a diffusion-model inference engine written in plain C and C++, able to run image and video models such as Stable Diffusion, Flux, Wan, Qwen-Image and Z-Image without a Python runtime anywhere in the stack. It is aimed at developers who would rather compile a binary and run it than maintain a Python environment, at people generating images on modest or unusual hardware, and at anyone who needs diffusion inference embedded inside a C or C++ application.
What it does
The project takes a text prompt and produces an image, and increasingly a video, using model weights you supply. The list of supported families is broad and has grown fast: the GitHub topics alone cover Stable Diffusion 1.x and 2.x, Flux and Flux-dev, Qwen-Image, Wan, Z-Image and Z-Image-Turbo, and LTX-Video, and the README's news log records a steady run of additions through 2025 and 2026 — Wan 2.1 and 2.2, Qwen-Image and Qwen-Image-Edit, FLUX.2-dev and FLUX.2-klein, Z-Image, LTX-2.3 and LTX-2.5, and day-zero or day-one support for newer releases like Qwen-Image-2.1 and MiniMax-H3.
Both text-to-image and image-to-image work are in scope; txt2img and img2img are among the repository's own topics. Since April 2026 the project also ships an embedded web UI, so the command line is not the only front end. Everything here is inference. There is no training or fine-tuning code in the picture.
How it works
The engine is built on ggml, the same tensor library behind llama.cpp, and the project describes itself as working in the same way as llama.cpp. That inheritance is the whole design. Model execution is implemented directly in C and C++ against ggml rather than sitting on top of PyTorch, so there is no interpreter, no package manager and, as the README puts it, no external dependencies — the result is a small self-contained program rather than a multi-gigabyte environment.
The same inheritance brings ggml's portability. As the video notes, the project runs on plain CPU as well as CUDA, Metal and Vulkan, which means the same source tree covers a laptop with no discrete GPU, an NVIDIA workstation and an Apple Silicon machine.
Getting started
The repository is the runtime, not the weights, so the shape of the work is: clone it, build it for the backend you have, point the binary at model files you already downloaded, and run a prompt. The MIT license puts no obstacle in the way of shipping the result inside something else. If you would rather not touch a terminal for every generation, the bundled web UI gives you a browser front end over the same engine.
One warning is worth taking from the README directly: the project states that it is under active development and that the API and command-line options may change frequently. If you build anything on top of it, pin to a specific commit and read the diff before you move forward, because a flag that worked last month may not work today.
When to use it / when not
It is a strong fit when:
- Python is unwelcome or impractical — a container you want kept small, an air-gapped box, an embedded target, a C++ application that needs generation in-process.
- You want one artifact to deploy instead of a dependency tree to reproduce.
- Your hardware is not a standard CUDA machine and you need CPU, Metal or Vulkan to be first-class rather than an afterthought.
- You want recent model families quickly; the news log shows support landing close to release.
It is the wrong tool when your workflow depends on the Python ecosystem around diffusion models — training and fine-tuning scripts, node-based pipeline editors, the large body of community extensions — since none of that transfers to a C++ binary. It is also not the safest foundation if you need a stable interface today, given the project's own note about churn.
Alternatives
The obvious comparison is the standard Python and PyTorch diffusion stack, which remains the richer ecosystem and the place new research lands first, at the cost of a heavy install and a fragile environment. stable-diffusion.cpp trades that breadth for a single dependency-free program. The other useful reference point is llama.cpp itself: if you already run text models that way and like the trade, this is the same bargain applied to image and video models, from the same underlying library.
Anyone who has fought a CUDA-versus-PyTorch-versus-driver install to generate a single image should look at this seriously, as should engineers packaging generative imaging into products where a Python runtime is a liability. With more than seven thousand stars, an MIT license and a release cadence that has kept pace with Flux, Wan, Qwen-Image and Z-Image, it has proven it is not a toy port. Treat it as a fast-moving dependency rather than a settled platform, pin your version, and it will do exactly what it claims.