llama.cpp 1.0 sets major-version rules for C API changes

By Tom Whitfield

llama.cpp and ggml released version 1.0.0 on Nov. 13, making the public C API’s compatibility rules explicit for developers building local AI applications. The paired release defines how maintainers will classify interface changes.

Breaking changes to interfaces in the ./include directory will now trigger a major-version increase. Backward-compatible features and new model support will receive minor releases, while bug fixes will use patch releases.

The project is an open-source C/C++ engine that runs large language models on laptops, phones and servers. ggml, the tensor library beneath it, reached the same version in the coordinated release.

Project creator Georgi Gerganov wrote with co-authors Daniel Bevenius and Merve Noyan: “Every new integration means more developers depending on our library interfaces and therefore having a flexible but stable API is paramount.” Gerganov created the project about three and a half years earlier.

Version 1.0 does not freeze development. Maintainers can still add functions and model architectures through minor releases, while users gain a clear signal when an edit will break existing code.

What does version 1.0 actually change?

The release combines header cleanup with new caching paths, model support and server protections. The work spans the public interface, runtime memory and the network-facing server rather than a single layer.

• Header cleanup: Version 1.0 removes 35 deprecated functions. It also removes the warmup and defragmentation-threshold settings from llama.h.
• Speculative decoding: The NextN speculative-decoding API moves into the main header.
• Memory features: The release adds OCP FP8 key-value caches and a host-memory cache for mixture-of-experts weights, also described as an MoE expert cache. The latter has a configurable CPU share.
• Architecture support: The release adds three new text architectures, including Kimi-K3.1-Pro.
• Server hardening: llama-server gains protections against server-side request forgery and DNS rebinding, alongside CORS controls.
• Speech and interface: A new /v1/audio/speech endpoint and a redesigned web UI join the release.

Developers should review any code that depends on the deleted functions or settings before moving to 1.0. The release information provides no benchmark figures for the new caches, so their effects on speed and memory use cannot be quantified.

In short, version 1.0 concentrates on interface stability, cache control and server protection.

How broad is the model and backend support?

The project reports support for more than 150 model architecture variants. Developers can compile dedicated ggml backends as dynamic libraries and load them at runtime.

Model count and backend design cover different parts of portability. Architecture support determines which model definitions the engine recognizes, while runtime-loaded backends determine which hardware-specific implementations are available.

The GitHub repository had about 135,000 stars when version 1.0.0 shipped. That measures repository visibility, not shipments, revenue or installed base.

The project says Nvidia, AMD, Qualcomm, Arm, IBM and Intel supply hardware for its self-hosted test runners. Hugging Face Buckets and Jobs scale the continuous integration work.

That split gives maintainers a way to test on hardware from several vendors and scale project jobs separately. In short, the stable API now rests on broad model, backend and test coverage.

Who maintains and distributes the project?

Gerganov’s company ggml.ai and its team joined Hugging Face in February. The llama.cpp and ggml projects remain open source under that arrangement.

The staffing change does not change the projects’ open-source status. Hugging Face also supplies the Buckets and Jobs services used in continuous integration.

The project says builds ship through these package channels and an Apple framework format:

• Docker, Debian, Homebrew, conda-forge, MacPorts and Winget.
• An XCFramework for Apple platforms.

These routes cover container deployment, package management, Windows installation and Apple application integration. Developers can install the engine through several common workflows without changing its core interfaces.

In short, version 1.0 combines a formal interface promise with several established delivery paths.

What does stability change for adopters?

For teams embedding local models, 1.0 offers a clear upgrade path. Compatible work stays within minor releases, defects remain in patch releases, and interface-breaking changes require a major release.

The release does not report pricing changes or production shipment targets. Its measurable claims concern API versioning, cache and model additions, architecture coverage, security controls and distribution reach.

The next competitive test is whether that stability retains integrations as developers adopt more of the supported model architectures and runtime backends.