What happened
The llama.cpp project and its ggml engine both reached version 1.0.0 on November 13, 2026. The biggest change is not a new feature. It is a promise: the version number will now tell developers when an upgrade can break their code.
The team announced the milestone in a post on the Hugging Face blog. The byline lists llama.cpp creator Georgi Gerganov, Daniel Bevenius and merve under the ggml-org account. Gerganov also shared the release on X.
llama.cpp is a C/C++ project that runs large language models, including multimodal ones, on a wide range of hardware. That range spans consumer machines and enterprise servers. The project relies on quantization, optimized backends and portable code. ggml is the tensor library underneath it.
The team says many downstream apps now depend on the project, which started about three and a half years ago. A stable interface matters more as that user base grows.
What changes for you
Developers who build on the libraries
The release covers two libraries. libllama is the inference library, with public headers in llama.cpp/include/. libggml is the machine learning tensor library, with headers in ggml/include/. Both now follow semantic versioning, and the same rules apply to all ggml-org projects.
| Version part | Example | When it changes |
|---|---|---|
| MAJOR | 1.x.x to 2.0.0 | A breaking change to the public C API in ./include |
| MINOR | 1.0.x to 1.1.0 | A backward-compatible feature, backend update, new model support or API addition |
| PATCH | 1.0.0 to 1.0.1 | A bug fix with no API change |
The post adds that future major bumps will signal both API and ABI incompatibilities. An API break means you must change your code. An ABI break means an app built against an older library may not work with a newer binary, even if the source still compiles.
For a developer, the rule of thumb is simple. A minor or patch update should not require code changes. A new major version is the cue to read the changelog before upgrading.
People who run local models through apps
Nothing changes overnight for users of apps built on llama.cpp. The new rules target the developers who package the engine into those apps. The project also lists several official ways to get it:
- Pre-release builds for Linux, macOS, Windows, Android and iOS
- Docker and Debian packages for Linux
- Homebrew for macOS and Linux
- conda-forge for Windows, macOS and Linux
- MacPorts for macOS and Winget for Windows
- An XCFramework for iOS and macOS apps
The team wants to add more channels. It has opened a GitHub discussion on packaging and release pipelines for that work.
What ggml 1.0 removes
The 1.0 label also comes with real clean-up. The ggml v1.0.0 release notes on GitHub list changes since version 0.29.0. The team pruned deprecated public API functions. It also removed two legacy operations, DIAG_MASK_INF and DIAG_MASK_ZERO.
The RPC protocol moved to version 9. ggml uses RPC to spread work across machines. The new version rejects incompatible peers, loads faster and fails gracefully when an endpoint is unreachable or a handshake fails.
Two groups should pay attention here. Code that still calls deprecated ggml functions may stop compiling. Setups that mix RPC nodes from different releases may refuse to connect.
How to prepare for the upgrade
- Search your code for deprecated ggml calls and for the two removed DIAG_MASK operations before you move to 1.0.
- Pin your build to the 1.x major version, so a future 2.0 does not arrive by surprise.
- Upgrade every machine in an RPC setup together, since version 9 rejects incompatible peers.
- Check the public headers in each library’s include folder, because those files define the stable API.
Under the hood: testing, backends and models
More testing on real hardware
The team says it is spending more on continuous integration to keep pace with development. It uses Hugging Face’s HF Buckets and HF Jobs to scale capacity and check every change that lands on the master branches. Nvidia, AMD, Qualcomm, Arm, IBM and Intel provide hardware support. With that help, the team is adding self-hosted test runners across major platforms.
The post also addresses AI-assisted coding. The team says it uses LLMs in its development cycle, but with care. Its stated priorities remain code quality, control of the architecture and a clear grasp of implementation details.
Backends and model support
ggml aims to run on nearly any hardware. Each hardware backend lives in its own module. A backend can be compiled as a dynamic library and, optionally, loaded at runtime.
The ggml 1.0 notes list work on many of these backends. CUDA gains OCP FP8 support and fused NVFP4 matrix operations. Metal gets fused mixture-of-experts routing. Vulkan adds an Intel FlashAttention prefill kernel. OpenCL, SYCL, WebGPU, Hexagon and CPU code paths also received new kernels and fixes.
On the model side, llama.cpp supports more than 150 architecture variants. It also supports all mainstream speculative decoding methods. These methods speed up text output by drafting tokens cheaply and then verifying them with the main model. The team commits to continued support for all model architectures.
What remains unclear
The announcement leaves a few questions open. It does not say how long an older major version will get bug fixes after a new one ships. The versioning rules cover the public C API in the include folders. The post does not say whether the llama-server HTTP interface follows the same rules.
The llama.cpp releases page also still lists frequent pre-release builds with numbered tags such as b12207. The post does not explain how those builds will line up with the new 1.x versions. Developers who track those builds should watch for guidance from the maintainers.
