draw-things-community publishes the model code behind the Draw Things app

What is public and what is not

draw-things-community is described as a community repository that maintains public-facing code that runs the Draw Things app, and the README is careful about the boundary.

Currently, it contains the source code for their re-implementation of image generation models, samplers, data models, trainer within the app. Over time, as they move more core functionalities into separate libraries, this repository will grow.

So the repository is a window onto a larger private codebase rather than the codebase itself. The app itself is distributed on the App Store, and what is open here is the model and sampler implementation that the app calls into.

The mechanism for that is in the Roadmap and Repository Sync section, and it is the most unusual thing about the project. The Draw Things app is managed through a private mono-repository, and they do per-commit sync with the community repository in both ways. Thus, internal implemented features would be leaked to the community repository from time to time and it is expected.

Read that as a workflow rather than a leak. The community repository is a mirror of selected paths in a private monorepo, updated commit by commit in both directions. The same section says they do not plan to publish a roadmap for the internal monorepository, and whether they would like to publish a roadmap for the public community repository would require further deliberation and feedback from the community.

For a user, the practical consequence is that the contents of the repository change on the maintainers' schedule, not yours. There is no release branch to pin.

The CLI for local inference and LoRA training

The most useful thing in the repository for a developer who does not want to install the app is the Swift Package Manager CLI, and the README documents it in two parts.

The gRPCServerCLI target can be built locally with:

swift build --target gRPCServerCLI

and run with the executable name form, not the target form:

swift run -c release gRPCServerCLI /path/to/models

The CLI options can be inspected with:

swift run -c release gRPCServerCLI --help

The second CLI is draw-things-cli, for local inference and LoRA training, built with:

swift build --product draw-things-cli

and its surface inspected with:

swift run -c release draw-things-cli --help
swift run -c release draw-things-cli generate --help

A minimal generation run looks like:

swift run -c release draw-things-cli generate --model flux_2_klein_4b_q6p.ckpt --prompt "a small red cube on a table"

The model path and the prompt are the whole interface, and the model file extension in the example, a .ckpt, tells you what the loader expects.

On macOS, draw-things-cli defaults to the same model directory used by the sandboxed Draw Things app:

~/Library/Containers/com.liuliu.draw-things/Data/Documents/Models

and you can override that with --models-dir or DRAWTHINGS_MODELS_DIR. Sharing the sandboxed container's model directory by default means a person with the app and a person with the CLI see the same models without copying them, which is a thoughtful default even though it ties the CLI to the app's container layout on macOS.

Homebrew, and the packaged gRPC server binaries

There are two distribution paths for the binaries, and they cover different cases.

The first is Homebrew, which installs the latest CLI with:

brew install --HEAD drawthingsai/draw-things/draw-things-cli

The --HEAD flag is what to notice. It installs from the head of the repository rather than from a tagged release, which is consistent with the per-commit sync model and with the fact that the repository's releases are the app's own version numbers rather than CLI version numbers. The verification step is:

draw-things-cli --help

The second path is the prebuilt self-hosted gRPCServerCLI binaries, which are provided through the repository's Releases page. The README says the latest version should be available there, and that these binaries give a quick way to host the Draw Things gRPC Server on Mac or Linux systems without downloading the Draw Things app. The app then connects to these self-hosted servers through its Server-Offload feature within your network.

That Server-Offload detail is the design point. The app is the client, the server is the thing doing the inference, and the two can be on different machines. A team with one workstation holding the models and several people generating from it is the deployment this makes possible, and it is why the server side is packaged for both macOS and CUDA Linux rather than being an app-only feature.

On macOS, you download the gRPCServerCLI-macOS binary, put it under /usr/local/bin or anywhere comfortable, and launch it with the path to the host models:

gRPCServerCLI-macOS /the-path-to-host-the-models

If the Draw Things app is installed, the model path can simply refer to the app's own container directory:

gRPCServerCLI-macOS ~/Library/Containers/com.liuliu.draw-things/Data/Documents/Models

The CUDA path on Linux, and the version constraints

The Linux story is the CUDA-accelerated gRPCServerCLI, and the README is specific about the hardware and the software versions involved.

It supports RTX 20xx, RTX 30xx and RTX 40xx, and should support A100 up to H100 NVIDIA cards. The Docker image uses CUDA 12.4.1 as the base, which requires NVIDIA graphics driver version 550.54.15 or above.

The simplest way to start is Docker with the NVIDIA Container Toolkit, and the verification step is a GPU check from inside the container:

docker run --gpus all drawthingsai/draw-things-grpc-server-cli:latest nvidia-smi

If it shows your GPUs, you are OK.

The driver version floor of 550.54.15 is the constraint to check before anything else, because it is older than what many current installations carry and it is tied to the CUDA base in the image rather than to the host's CUDA toolkit. The card list is also a real boundary: consumer Ada and Ampere cards are named, and the data centre range from A100 to H100 is described as expected rather than confirmed.

The container image carries the NVIDIA Deep Learning Container License, and the README reproduces the notice that pulling and using the container means accepting its terms, with a copy made available in the container at /NGC-DL-CONTAINER-LICENSE.

So there are two licences in play for the Linux route, the GPL-3.0 of the source and the NVIDIA container licence of the image, and the second one is a runtime acceptance rather than a distribution question.

Contributing, the CLA, and the repository layout

The Contributions section is short and sets expectations clearly.

While they expect the development to be mainly carried out by the maintainers, they welcome contributions from the community, and they require a Contributor License Agreement to make this more manageable. If you prefer not to sign the CLA, you are still welcome to fork this repository and contribute in your own way.

That last sentence is the practical instruction for anyone who cannot sign a CLA, and it is worth reading as a fork policy rather than a formality. There is a CLA/ directory in the repository, so the agreement is in-tree, and the alternative path is explicitly your own fork rather than a contribution back.

The top level entries show a large multi-platform build. There are Apps/, Libraries/, Tools/ and Vendors/ directories, plus Scripts/, external/ and a signatures/ directory, along with AGENTS.md and the CLA directory.

The build system is Bazel with Swift, and the platform split is explicit. There are MODULE.bazel and MODULE.bazel.lock for the Bazel module, a Package.swift and Package.resolved for SwiftPM, and separate WORKSPACE.darwin and WORKSPACE.linux files with matching .bazelrc.darwin and .bazelrc.linux files and a .bazelversion. A Swift format configuration sits in .swift-format.json.

Two files at the root are the clearest sign of how the sync works. SYNCLIST presumably records what is synchronised, and force_sync.sh is the script that does it. That is a very different arrangement from a project where a human decides what to open, and it explains the per-commit sync language in the README.

The licence is GPL-3.0, the primary language of the repository is C, and the release history shows three releases in October 2026, v26.1014.0 on 2026-10-15, v26.1011.0 on 2026-10-12 and v26.0928.0 on 2026-09-28, with the last push on 2026-10-20.

Where draw-things-community fits, and where it stops

The comparison worth making is with the other ways to run Stable Diffusion style models locally, and with the app itself.

Against a standalone open source inference stack, the difference is that this is the code from a shipping commercial app rather than a from-scratch project. The models, samplers and trainer are the ones the app's users actually run, and the trainer is the same one used for LoRA work, which is the part that is usually hardest to reproduce. The cost is that the repository is a mirror, so the interface can change under you when the maintainers move code around in their private tree.

Against the app, the difference is the split between client and server. The app is the interface and the client; the gRPC server is the part that does the work. Offloading the server means a team can share one set of models and one GPU, and the README is explicit that the app connects to these self-hosted servers through its Server-Offload feature within your network.

The limits are structural. The synchronisation model means there is no stable public API to depend on, and the roadmap for the internal monorepository is deliberately not published, so a change to the public tree can arrive without notice and with no changelog explaining the intent. The Homebrew install uses --HEAD, which is the honest reflection of that. The Linux CUDA route requires a specific driver floor and a container image under a separate NVIDIA licence, and the supported card list is explicit about what is confirmed and what is expected.

There is also a licensing asymmetry worth thinking about for anyone shipping something built on this. GPL-3.0 applies to the source here. The README says the project is maintained through a Contributor License Agreement, and the terms of what you may do with the code depend on which licence you take it under and on whether you are distributing it.

For a developer who wants to script generation, self-host a shared inference server, or read how these samplers and the trainer are implemented, the repository is unusually accessible. For anyone building a long-lived product on it, the sync model is the thing to weigh.

Editorial conclusion

draw-things-community suits a developer who wants to run the Draw Things inference and training code outside the app, whether to script generation, to self-host a gRPC server for a team, or to study how the samplers and trainer are implemented, since the CLI and the server binaries are published rather than only the sources. It is the wrong tool if you want the app itself, since the application ships on the App Store and the community repository holds the public facing code that runs it, and it is the wrong tool if you cannot sign a Contributor License Agreement, since the maintainers require one and the alternative is forking. Before adopting it, read the Roadmap and Repository Sync section, because the code arrives by per-commit sync from a private monorepo rather than by a curated release, so the repository contents move on their own schedule.

Frequently asked questions

Official sources

1. drawthingsai/draw-things-community on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases