Version 0.1.0 returns typed probabilities instead of prose
Rizzo Flow 0.1.0 accepts a shared state and asks a local model to judge boolean, choice, score, or numeric questions about it. Each candidate answer becomes a letter, and the server reads the model's score for those letters after one forward pass. There is no text decoding loop and no generated JSON to repair. The response shape is controlled by Python rather than by a model following formatting instructions.
That design is narrow on purpose. A support ticket can become an urgency boolean, a department choice, and a frustration score in one request. Questions share the state's KV cache instead of processing the same document again. The native endpoint can also abstain or mark a numeric estimate outside its supplied anchors. It cannot explain the choice in prose, discover an option you forgot to include, or prove that its highest probability is correct.
The default first run downloads 4.4 GB of weights
The code setup needs Python 3.11 or newer, git, and uv. After that, rizzo download fetches a machine-specific llama.cpp build and the fine-tuned Spark-X2.5 model. The default 4B Q8_0 file is 4.4 GB. Smaller choices include a 2.6 GB 4B quantization and 1.8 GB or 1.1 GB variants of the 1.7B model, though the README says the smaller model is much less accurate.
Hardware selection covers CUDA, Vulkan, Metal, ROCm, SYCL, and CPU builds, with the project pinning llama.cpp release b11081. That breadth comes with boundaries. The maintainers say their own complete measurements cover one Windows and NVIDIA machine, while other hardware evidence comes from community reports. Open issue 18 describes a Windows 11 Intel system that crashed on startup with both CPU and Vulkan paths across 2 model sizes.
What happened when we ran it
Our measurement setup used a fresh Debian container with 3 CPUs, 8 GB of RAM, no secrets, and no elevated privileges. Installing commit b9ba007 took 21 seconds, pulled 53 packages, and used 73 MB on disk. The build completed in 7 seconds. Pip-audit found 0 known vulnerabilities in the installed Python environment.
Pytest completed in 14 seconds with 75 passed, 0 failed, and 13 skipped. The repository had 193 files, about 7,933 lines of source, and a 12.6 MB checkout. It includes a tests directory but 0 CI workflow files and no Dockerfile. Our run validates the package and available unit suite; it does not validate the downloaded 4.4 GB model on a GPU or reproduce the project's decision benchmarks.
A 0.648 project score still needs domain calibration
The README reports 0.648 accuracy for its 4B fine-tune on the typed-decisions test split, compared with 0.574 for the base model on the same machine. It also reproduces Jev's published 0.727 figure from that dataset card, rather than presenting it as a local rerun. The authors spell out another limitation: the gold labels came from a model, not human judges. These are useful internal comparisons, not permission to reuse a threshold in your application.
Rizzo Flow includes temperature scaling because probability quality changes with weights, quantization, backend, and workload. A calibration file is tied to that fingerprint so a CUDA fit does not quietly load on Vulkan. You still need labeled domain data, a separate calibration split, and a held-out test. The known-limitations section says the model underuses abstention and can answer confidently when evidence is absent.
Jev compatibility ends at 26 answer options
The compatibility route accepts Jev-shaped boolean, choice, and score requests, and clients can point at localhost by changing a base URL. Rizzo always reports its local model identity. It allows at most 26 options per choice, compared with the hosted API's documented 255, and the compatibility format disables abstention. The README also says official SDK compatibility was designed but not tested against the real SDKs.
Security differs between the 2 route families at commit b9ba007. /v1/systemone and /v1/models use the Bearer authorization dependency when RIZZO_API_KEY is set. /v1/decisions does not. Open PR 16 adds the same check and tests to the native endpoint, but it was still unmerged on October 8. Combined with no rate limiting and serialized concurrent requests, that makes localhost or a protected internal network the sensible boundary.
The 21-item open queue contains production fixes
GitHub showed 852 stars, 58 forks, 10 open issues, and 11 open pull requests on October 8. The repository was created on September 21 and last pushed on September 25, while issue discussion continued through October 7. There is no tagged GitHub release. Several merged September fixes came from hardware reports, including Metal device detection, cleanup on exit, and CUDA device probing.
The queue is more than feature requests. Issue 29 offers an external audit with 28 proposed bug fixes, CI, and a much larger test suite; those branches are contributor work, not merged project behavior. PR 16 addresses the native endpoint's missing auth check, and issue 18 records the Windows access violation. The passing 75-test lab run is a good base. It is not a substitute for resolving the deployment-specific faults that the current queue makes visible.