llama.cpp v1.0.0 Sets a Stable Public API

The llama.cpp project has shipped libraries v1.0.0 for both libllama and libggml, according to a Hugging Face blog post published on 13 November 2026 and a GitHub release tagged at 10:20 GMT the same day. After three and a half years, the authors say, enough downstream applications depend on the interfaces that a stable public API has become “paramount.”

The point of the 1.0 label, in their telling, is not a marketing anniversary. “Moving forward, both llama.cpp and ggml will reflect API and ABI incompatibilities with major-version bumps,” the blog says. In plain terms, a developer who pins llama.cpp v1.0.0 is being promised that a later 1.x release should not break the public C API, and that a jump to 2.0.0 will be the signal if it does.

What llama.cpp v1.0.0 changes in the public API

The semantic-versioning rules, which the blog says apply to all ggml-org projects that use them, are narrow. A MAJOR bump means a breaking change to the public C API in ./include. A MINOR bump is a backward-compatible feature, backend update, model-support addition or API addition. A PATCH is a bug fix with no API change.

The GitHub release notes spell out what landed in this cut. llama.cpp v1.0.0 “removes the deprecated public API and promotes the NextN/speculative API to llama.h.” It adds OCP FP8 key-value caches, a host-memory mixture-of-experts expert cache with a configurable CPU share, and the loading of external PLE shards. It hardens llama-server against server-side request forgery, cross-origin issues, DNS rebinding and MCP tool cancellation, and it updates ggml itself to v1.0.0. Those are the project’s own descriptions of a security and interface cleanup, not a claim that every deployment is now safe by default.

Coverage is the other half of the 1.0 pitch. The blog says llama.cpp “supports more than 150 architecture variants as well as all mainstream speculative decoding methods,” and that ggml backends can be compiled as dynamic libraries and loaded at runtime. Distribution now runs through pre-release artifacts, Docker, Debian, Homebrew, conda-forge, MacPorts, Winget and XCFramework, covering Linux, macOS, Windows, Android and iOS in various combinations. Continuous-integration hardware support is credited to NVIDIA, AMD, Qualcomm, Arm, IBM and Intel. The blog also points packaging teams to a discussion on how to add ggml-org projects to their own release pipelines, which is the practical counterpart of a 1.0 library: a versioned artifact that someone else can redistribute without guessing at the ABI.

The same release is still a feature drop, not only a freeze. It adds three text architectures — Kimi-K3.1-Pro, Ripple and xing4_0 — plus drama-3 text-to-speech and vision support for MageVL-Cowork and Kimi-K3.1, according to the notes. It ships an OpenAI-compatible /v1/audio/speech endpoint, a redesigned web UI with chat groups and a markdown editor, and further API work in the mtmd headers, including a helper that resamples raw PCM to a model’s sample rate. The multimodal stack is being tidied as well: the notes say clip.h has been removed and that model and subcontext infrastructure now sit in mtmd. Those additions sit under the new MINOR rule if they are backward-compatible, and they are listed in the same tag that removes 35 deprecated functions from llama.h.

None of that makes llama.cpp a new foundation model. It is the C and C++ inference stack on which a lot of local and private AI products already sit. The blog is explicit about the intended audience: “the most lightweight, versatile and sensible platform for building cross-platform and private AI products,” written by the llama.cpp team at Hugging Face. A reader who only wants a runtime to pin, and a reader who wants the new speech endpoint or a newly listed architecture, are looking at the same tag for different reasons. The versioning rules are how those two uses are supposed to stay compatible.

A 1.0 tag is a contract with the apps already built on it

The useful way to read llama.cpp v1.0.0 is as a promise about breakage, not as proof that local inference has suddenly become easy. Open-weight models that TSN has already described as being meant to run on a device — Tether’s BotPsy-0.8B for on-device agents, Recursive’s Flint coding model built to run locally, and Liquid AI’s LFM3 small open-weight models — still need a runtime that will not quietly change the C API under them. A 1.0 release is how a library tells those downstreams when they should expect to rewrite, and when they should not.

That contract is only as good as the project’s later discipline. The same post says the team will be “stricter about making those boundaries visible to downstream consumers.” The test will be the next major bump, if and when a public-header break actually appears, and whether minor releases stay inside the published rules. Until then, v1.0.0 is best treated as a baseline: a dated, inspectable C API, a ggml tensor library on the same versioning scheme, and a long list of packaging channels that make the stack easier to pin.

The GitHub tag also shows the project is still adding models and server features in the same breath as it freezes old APIs. That is normal for a 1.0 in a fast field, but it is a reminder that “stable interface” and “finished product” are not the same thing. Anyone packaging llama.cpp for a product should read the release notes for the removed functions, not only the version number on the box.

The next thing to watch is not a new architecture count. It is whether the first minor and patch releases after v1.0.0 keep the public C API untouched, exactly as the new rules describe.