A version number that is finally a contract
For most of its life, llama.cpp did not really have versions in the sense library users expect. It had build tags, arriving almost daily, and downstream projects pinned specific tags without a stated compatibility policy behind them. That was tolerable while the project was young. The announcement is blunt about why it no longer is: many downstream applications already depend on the library interfaces, so a flexible but stable API is now, in its word, paramount.
Version 1.0.0 is the project's answer. The rule set is simple enough to print on one line. Break the public C API and the major number moves. Add something backward-compatible and the minor number moves. Fix a bug and only the patch number moves. The version number now signals the intended compatibility of the public interfaces; deployments still need testing.
Read that as a promise about future behavior, not as a fact about the past. The project also says it will be stricter about making API and ABI boundaries visible. Stricter is a direction, not a guarantee: future releases will show whether incompatible changes are consistently accompanied by major-version bumps. Nothing in the announcement sets a support window for older major versions, so teams that need long-term stability still have to pin and test for themselves.
The 1.0 release breaks things, on purpose
There is a certain honesty in how this milestone was shipped. Rather than freezing whatever API happened to exist, the project used the major bump to clear the cupboard. Thirty-five deprecated functions are gone, along with llama_set_warmup, the defrag_thold setting and its command-line flag. The NextN speculative-decoding API moves into the main header, one context-state function is renamed, and ggml removes its deprecated API and its legacy DIAG_MASK ops in the same step. Code that references the removed functions or fields will need changes before building against 1.0. That is the point of doing it now, under a major number, instead of letting the dead surface accumulate.
The RPC change deserves a line of its own for anyone running ggml across machines. RPC v9 rejects incompatible peers. Check protocol compatibility across participating processes when upgrading, rather than discovering a mismatch at runtime.
The server grew up in the same release
The part of 1.0.0 most likely to matter this week is not the versioning at all. It is the llama-server hardening. The release adds explicit opt-ins for unauthenticated tools and private media URLs. It fixes CORS origin handling, DNS rebinding and a CORS proxy SSRF path, restricts the Hugging Face token to huggingface.co hosts, and cancels MCP tool calls when a client disconnects or times out.
That list matches how the server is deployed beyond a single laptop: on a network, wired to tools, fetching media. These changes deserve particular attention in network-exposed deployments. If you expose llama-server beyond localhost, read the security section of the notes before you upgrade, because the new defaults are the feature.
Underneath, the release still does the project's usual work. FP8 KV caches and a host-memory cache for MoE experts both aim at fitting larger workloads into less GPU memory, and the notes publish no benchmark figures for either, so treat the size claims as mechanisms to test rather than results. Backend work spans CUDA, Metal, Vulkan, SYCL and OpenCL in the same release, the breadth of hardware coverage that has kept this runtime in use.
Sources
- [1] Hugging Face / ggml-org, "llama.cpp v1.0.0: A stronger foundation for the local AI ecosystem" (November 13, 2026)Read source
- [2] ggml-org, llama.cpp v1.0.0 release notes (GitHub, November 13, 2026)Read source
- [3] ggml-org, ggml v1.0.0 release notes (GitHub, November 13, 2026)Read source