llama.cpp, the C++ inference engine running underneath Ollama, LM Studio, GPT4All, and most of the local AI ecosystem, tagged v1.0.0 on November 13 after 3.5 years of weekly churn and no stable API guarantees. The features matter less than the promise: semantic versioning now governs the public C API, and breaking changes arrive only with a MAJOR version bump. If you have ever had a llama.cpp update silently wreck your build on a Friday afternoon, that era is over.
The Semver Contract #
Both libllama and libggml now follow explicit rules: a MAJOR bump signals a breaking change to the C API in ./include, MINOR covers backward-compatible additions and new model support, PATCH is bug fixes only. That sounds obvious, but llama.cpp skipped this convention for three and a half years. The project moved so fast that semver would have felt like a straitjacket. Now the ecosystem is wide enough that unpredictable breaks are costing real engineering time downstream.
The practical upside: enterprise vendors and Linux distros can now package libllama like they package libssl or libcurl — with a formal expectation that the next soname change will be announced, not discovered at compile time.
What Breaks in v1.0.0 #
This release itself carries breaking changes — it is the final cleanup before the stability promise kicks in. Thirty-six C API symbols were removed. If your code calls any of them, it will not compile against v1.0.0. The most common ones developers will hit:
- `llama_n_embd(model)` → use`llama_model_n_embd(model)`
- `llama_n_ctx_train(model)` → use`llama_model_n_ctx_train(model)`
- `llama_token_cls(vocab)` → use`llama_vocab_bos(vocab)`
-
llama_set_warmup→ removed entirely, no replacement -
llama_set_embd_state_src→ renamed tollama_set_ctx_state_src -
--defrag-tholdCLI flag → gone The libllama shared library also changed its soname fromlibllama.so.0tolibllama.so.1. Any dynamically linked binary or package that pins the old soname needs updating before the upgrade lands. ComputingForGeeks has a tested upgrade walkthrough if you want step-by-step guidance.
Who Needs to Act #
The affected surface area depends on how you use llama.cpp. Command-line users running llama-server or llama-cli can upgrade on their normal schedule — no source changes needed. C API consumers, meaning anyone who links libllama directly in custom code, Ollama internals, or llama-server wrappers, need to audit their symbol usage against the removed list before upgrading. Python binding users (llama-cpp-python) should wait until the binding package tags a compatible release rather than upgrading the underlying library directly.
The practical migration checklist is short: search your codebase for the 36 removed symbols, swap in the current API equivalents, update any soname references, recompile, and run your tests. The release notes on GitHub list every removed symbol with its replacement.
New Capabilities in v1.0.0 #
The breaking changes get the attention, but v1.0.0 also ships useful additions. OCP FP8 KV cache (f8_e4m3 type, controlled via -ctk/-ctv flags) reduces memory usage for long conversations. A new host-memory MoE expert cache with configurable CPU share lets mixture-of-experts models run on machines without massive VRAM — think running Kimi-K3.1-Pro locally without a data-center GPU. Three new model architectures land: Kimi-K3.1-Pro, Ripple, and xing4_0. The server also gains an OpenAI-compatible /v1/audio/speech endpoint and security fixes for CORS, DNS rebinding, and HF_TOKEN scoping.
What It Signals #
Georgi Gerganov pushed the first commit to llama.cpp in March 2023 to run Meta’s leaked Llama model on a MacBook with no GPU and no dependencies. It was a weekend project. It became the runtime underneath tools with over seven million combined active users. In February 2026, the team joined Hugging Face full-time. v1.0.0 is not a feature release — it is an infrastructure signal. The local AI stack is maturing past the “fun experiment” phase into something you can build a product on.
The next breaking change will announce itself. That is new.