The Problem
Running FLUX.2 image generation models typically requires a Python ML stack (PyTorch, CUDA, or MPS) with substantial RAM and GPU resources. On Apple Silicon or Linux systems with 8GB RAM, the standard stack cannot even load the model. This repo removes that dependency entirely: it is a pure C implementation with zero external dependencies, using memory-mapped weights to run on hardware where the Python stack fails.
What This Does
This is a complete FLUX.2-klein-4B inference engine written in C. The core files are flux.c (main inference loop), fluxtransformer.c (denoising), fluxvae.c (image decoding), fluxqwen3.c (text encoder), and fluxkernels.c (math operations). It supports both text-to-image and image-to-image via in-context conditioning, with optional BLAS or Metal acceleration.
The repo includes a CLI (main.c), a library API (flux.h), and a test harness (runtest.py with reference images in testvectors/). A Makefile provides three build targets: mps (Apple Silicon), blas (Intel/Linux with OpenBLAS), and generic (pure C). The README claims MPS performance matches PyTorch's optimized pipeline.
How To Use It
Setup: Build with the appropriate target, then download the model weights (~16GB) using downloadmodel.sh or downloadmodel.py.
Build (choose your backend)
make mps # Apple Silicon (fastest) or: make blas # Intel Mac / Linux with OpenBLAS or: make generic # Pure C, no dependencies
Download the model (~16GB)
./downloadmodel.sh or: pip install huggingfacehub && python downloadmodel.py
Generate an image
./flux -d flux-klein-model -p "A woman wearing sunglasses" -o output.png
Configuration: No environment variables or config files required. The -d flag points to the model directory. Optional flags include --show and --show-steps for terminal image display (requires Kitty or Ghostty).
Running it: The entry point is main.c, compiled to the flux binary. For image-to-image, pass -i input.png with a descriptive prompt.
Real-World Use
A typical workflow: a content pipeline on a headless Linux server generates images on demand. The pure C implementation means no Python runtime, no CUDA toolkit, and no GPU requirement beyond what the machine has. Memory-mapped weights keep peak RAM around 4-5GB, so an 8GB server can batch-generate images. The library API (flux.h) allows embedding generation directly into a C application without spawning a subprocess.
Code Health & Issues
Med - No CI/CD pipeline: No .github/ or CI config detected. No automated build or test gate, which is risky for a project with this much numerical code. Low - Single-maintainer risk: Forked from antirez/iris.c, this is a solo project with zero stars. Bus factor is one; there is no evidence of external review or contribution. Low - Test coverage is narrow: runtest.py and test_vectors/ cover 1/2/4-step generation and img2img, but there is no fuzzing or edge-case testing for malformed prompts or model files. Low - License present: LICENSE file exists; no compliance issues flagged.
The codebase is otherwise clean: no secrets in the repo, a clear Makefile, and documented build paths.
The Bottom Line
This is a serious engineering effort that solves a real deployment problem: running FLUX.2 on memory-constrained hardware without a Python stack. The zero-dependency design and memory-mapped weights are genuinely useful. The lack of CI and single-maintainer status are the main risks; treat it as a capable reference implementation rather than a production-ready dependency.