llama.cpp b9601: A Build Fix, a Disabled Feature, and the State of Open-Source AI

On June 11, Georgi Gerganov’s llama.cpp project tagged release b9601. The release notes are a single line: a Vulkan build fix for something called eMesaHoneykrisp, patching a break introduced by an earlier pull request. That is the entirety of the code change.

But the release artifacts tell a richer story. The project ships 23 downloadable binaries across macOS, Linux, Windows, Android, and iOS, targeting CPU, Vulkan, CUDA 12, CUDA 13, ROCm 7.2, OpenVINO 2026.0, HIP, and SYCL backends. Three builds are explicitly marked DISABLED: macOS Apple Silicon with KleidiAI, Ubuntu x64 with SYCL FP32, and Windows x64 with SYCL. A fourth platform, openEuler, is listed with a single word: DISABLED.

A routine patch release for an open-source project that has been starred 116,000 times on GitHub. Yet b9601 is a useful document of the forces shaping the most widely deployed inference engine in the world.

The KleidiAI Disablement

The most interesting disabled build is macOS Apple Silicon with KleidiAI enabled. KleidiAI is Arm’s micro-kernel library for AI inference, released in 2024. It promises hand-tuned matrix multiplication routines for Arm CPUs, particularly Apple’s M-series chips. Arm claims KleidiAI can deliver up to 2x throughput improvements on certain transformer operations compared to generic kernels.

llama.cpp integrated KleidiAI support in early 2025. The project’s maintainers have been iterating on it since. But b9601 ships without it. The disablement links to pull request #23780, which as of this writing has not been merged.

The reason is not disclosed in the release notes. But the pattern is familiar: a bleeding-edge optimization library introduces build complexity, platform-specific bugs, or performance regressions on certain chip variants, and the maintainers decide to ship a stable build without it rather than delay the release.

This is the fundamental tension of llama.cpp. The project’s value is universal portability. A single codebase runs on a Raspberry Pi, an iPhone, a MacBook Pro, a Linux server with four NVIDIA H100s, and an AMD workstation with a Radeon GPU. That breadth is what made the project explode in popularity after its July 2023 launch. It is also what makes maintenance a nightmare.

Every new hardware backend, every vendor-specific acceleration library, every compiler flag introduces a combinatorial explosion of test configurations. The project’s CI system must validate builds across CPU architectures (x86_64, arm64, s390x), GPU APIs (Vulkan, CUDA, ROCm, OpenVINO, SYCL, HIP, Metal), and operating systems (macOS, Windows, Linux, Android, iOS). A single broken header in a vendor SDK can stall the entire release pipeline.

The Platform Sprawl Problem

b9601 ships binaries for 19 distinct platform configurations. That is down from some earlier releases that included more. The disabled builds are a canary. SYCL, Intel’s unified programming model for CPUs and GPUs, has two disabled builds in b9601. openEuler, a Chinese Linux distribution, is entirely disabled.

These are not failures of the llama.cpp team. They are failures of the hardware ecosystem to provide stable, well-documented, cross-platform compute abstractions. Every GPU vendor wants developers to use their proprietary stack. NVIDIA pushes CUDA. AMD pushes ROCm. Intel pushes OpenVINO and SYCL. Arm pushes KleidiAI. Apple pushes Metal Performance Shaders.

llama.cpp sits in the middle, trying to abstract all of them through ggml, its custom tensor library. ggml is a remarkable piece of engineering. It implements matrix multiplication, attention, and other transformer operations from scratch, optimized for each backend. But it is a single project maintained by a small core team. Every new backend is a permanent tax on that team’s attention.

The result is a release like b9601. A one-line build fix, 23 binaries, three disabled builds, and a quiet acknowledgment that the project cannot keep every platform green simultaneously.

What This Means for AI Builders

For developers building on llama.cpp, b9601 is a reminder that the project’s breadth is both its superpower and its weakest point. If you target CUDA on Windows x64, you get a first-class experience. If you target SYCL on Ubuntu, you are on your own. If you want KleidiAI on macOS, you wait.

This is not a criticism of the maintainers. It is a structural fact about open-source infrastructure in a fragmented hardware market. The llama.cpp project has 116,000 stars and thousands of contributors. It is the foundation for countless applications, from local AI assistants to enterprise RAG pipelines. Yet its release process is still a handful of people debugging vendor SDKs.

The deeper question is whether this model scales. As AI inference moves to more diverse hardware, from automotive chips to edge microcontrollers to mobile NPUs, the demand for universal runtimes will only grow. llama.cpp is the closest thing the ecosystem has to a universal runtime. But every new platform adds surface area for bugs, build failures, and performance regressions.

b9601 is a minor release. It fixes a Vulkan build. It disables a few features. But it is also a signal. The open-source AI infrastructure that the industry depends on is running on a maintenance model that assumes hardware diversity will stay manageable. That assumption is getting harder to sustain with every new vendor SDK.

The project will keep shipping. Gerganov and the maintainers are among the most productive engineers in the field. But b9601 is worth reading as a document of what it takes to keep universal AI inference alive. One line of code, 23 binaries, and a quiet acknowledgment that some platforms just have to wait.