llama.cpp and ggml hit 1.0.0 with a stable-API promise

The llama.cpp project has published its first 1.0.0 release, marking both llama.cpp and ggml as 1.0.0 libraries and committing that any future break in the public C API will be signalled by a major-version bump. For the applications that already link against the project, that turns a fast-moving dependency into a stated compatibility contract.

What shipped in llama.cpp v1.0.0?

According to the Hugging Face Blog post announcing the release, two libraries moved to 1.0.0 together on November 13, 2026: llama.cpp v1.0.0, described as LLM inference in C/C++ and published as libllama with public headers under llama.cpp/include/, and ggml v1.0.0, the tensor library for machine learning, published as libggml with headers under ggml/include/. The post is credited to the ggml-org team, with Daniel Bevenius, Georgi Gerganov and merve listed as authors.

The pitch itself is unchanged: a portable C/C++ implementation that, with quantization and optimized backends, runs multi-modal LLMs on hardware from consumer machines to high-end enterprise servers. What is new is the framing. The team notes the project is three and a half years old, that many downstream applications already depend on it, and that every new integration adds another developer relying on its library interfaces — which is why a flexible but stable API is now treated as a priority.

What do the new semantic versioning rules change?

The post sets out rules for all ggml-org projects using semantic versioning. A breaking change to the public C API in ./include forces a MAJOR bump. A backward-compatible feature, a backend update, added model support or an API addition counts as MINOR. A bug fix with no API change is a PATCH.

From a downstream maintainer's chair, the division of labour is the interesting part. New model architectures and new backends — historically the most frequent reason to update — are explicitly minor events, so tracking the library should not mean bracing for breakage each time a model lands. Only API and ABI incompatibilities pull a major version, and the team says it will be stricter about making those boundaries visible to downstream consumers as adoption grows.

Where can you get the libraries?

The post lists distribution channels by platform. Pre-release artifacts cover Linux, macOS, Windows, Android and iOS. Beyond that: Docker on Linux, Debian on Linux, Homebrew on macOS and Linux, conda-forge on Windows, macOS and Linux, MacPorts on macOS, Winget on Windows, and an XCFramework for iOS and macOS.

The team frames this as a starting point rather than a finished list, and points packagers to a discussion thread about adding ggml-org projects to their own packaging and release pipelines. If your platform is missing, that is the thread the maintainers have nominated.

How much hardware and how many model architectures does it cover?

ggml, the engine underneath llama.cpp, is designed to run on virtually any hardware through dedicated backends. Each backend can be compiled as a dynamic library and optionally loaded at runtime — the mechanism that lets one build reach several accelerators instead of forcing a rebuild per device. The post links a complete list of currently implemented backends.

On the model side, the team states that llama.cpp supports more than 150 architecture variants, plus all mainstream speculative decoding methods. Two videos published with the post map those two axes: the hardware coverage video shows the devices the backends reach, and the model coverage video shows the architectures currently supported. Neither carries benchmark figures; they are coverage maps, not performance claims.

How is the team scaling development and CI?

Supporting every backend and every architecture makes the test matrix grow quickly, and the post is direct about the infrastructure cost. The team says it is investing more in CI, using Hugging Face's HF Buckets and HF Jobs to scale the capacity needed to verify each change that lands on the master branches. It also continues to enrol self-hosted runners across major hardware platforms, with hardware support from NVIDIA, AMD, Qualcomm, Arm, IBM and Intel.

On tooling, the post acknowledges how fast AI software engineering has advanced and says the project integrates LLMs into its development cycle in a measured way. Its stated priorities remain a high-quality codebase, staying in control of the architecture, and understanding implementation details — a pointed emphasis for a project whose selling point is that you can read exactly what it does to your model.

What does the 1.0 milestone mean in practice?

For developers embedding llama.cpp, the practical change is a promise about labelling, not a new capability. Pinning to a major version should now carry information: expect minor releases to bring new architectures, backends and API additions, and treat a major release as the cue to re-read the headers.

For everyone else, the milestone is about durability. A library that has underpinned local and private AI tooling for three and a half years now has an explicit compatibility policy and more install paths, including the Llama desktop apps for macOS and Windows that the team links alongside the release. The post makes no performance or quality claims, so nothing here should be read as a benchmark result.

Where Grafy fits

Grafy runs cloud models side by side rather than on your own machine, so llama.cpp is a complement rather than a rival. The direct connection is code: Grafy Code is an AI coding studio that installs packages and runs your code, which makes it a practical place to try the 1.0.0 headers — write a small program against libllama, build it, and check whether the API surface described in the release notes matches what you get. How the studio handles that loop is covered in An AI coding studio that installs packages and runs your code.

Quantization is the shared thread, and it is where local and hosted inference meet. Grafy News has reported on recent work finding that extra passes over a model beat extra bits at 6-bit for small local LLMs: Extra passes beat extra bits at 6-bit for small local LLMs. If you are weighing a local deployment against a hosted one, Grafy Chat is a quick way to put both options side by side and argue the tradeoffs through.

Frequently asked questions

Does llama.cpp v1.0.0 support more than 150 model architecture variants?

Yes. The release post states that llama.cpp currently supports more than 150 architecture variants, and that all mainstream speculative decoding methods are supported too. The team also commits to continuous support for all model architectures, and published a model coverage video with the release. Under the new rules, added model support and backend updates count as minor-version changes.

Will a breaking change to the public C API trigger a major-version bump?

Yes. Under the semantic versioning rules published with the release, which apply to all ggml-org projects, a breaking change to the public C API in ./include requires a MAJOR bump for both llama.cpp and ggml. Backward-compatible features, backend updates, model support and API additions are MINOR, and bug fixes with no API change are PATCH. The team says it will be stricter about making those boundaries visible downstream.

Which hardware companies provide runners for llama.cpp CI?

According to the release post, the project enrols self-hosted runners across all major hardware platforms with hardware support from NVIDIA, AMD, Qualcomm, Arm, IBM and Intel. Those runners back a CI setup the team is expanding with Hugging Face's HF Buckets and HF Jobs, in order to guarantee correctness for every change that lands on the master branches of the projects.

---

Source: Hugging Face Blog — llama.cpp v1.0.0 : A stronger foundation for the local AI ecosystem