llama.cpp, software used to run AI models on local computers and servers, released version 1.0.0 on November 13, 2026. It removes retired library calls, requiring changes before upgrading for developers whose applications still use them.
The immediate task falls to teams embedding the library in their products, including maintainers of language bindings—the adapters that let other programming languages use it. The release notes list 35 deprecated functions among the removals. That does not mean every local AI app needs rewriting.
Who needs to change what
One documented replacement is llama_load_model_from_file → llama_model_load_from_file. The v0.9.0 header already marked the old model-loading call as deprecated and named its replacement. The v1.0.0 header retains the supported call and removes the old one.
That offers a staged migration for teams on v0.9.0: they can change this call before upgrading the underlying runtime. It separates that source-code edit from the version change, but does not establish that every removal is a simple rename.
A search for old function names is not enough. The merged change also removes a field from the context-parameter structure, defrag_thold. Bindings that reproduce that structure need checking against the new header, even if their function names are current.
For people using a packaged desktop app, the practical step is to check its maintainer’s release notes and use its supported update—not replace internal library files manually. The upstream release does not establish which third-party apps already support it.
Applications that send requests to llama.cpp’s HTTP server use a separate interface. Removing a C-library function does not itself require renaming an HTTP request. Server operators should still check launch scripts: the same change removes -dt/--defrag-thold, so scripts retaining that retired option need updating.
What the version number promises
In their November 13 announcement, the maintainers say incompatible changes to the public programming and binary interfaces of llama.cpp and ggml will trigger major-version increases. In plain terms, these cover how code calls the libraries and how compiled software connects to them. Compatible additions belong in minor releases; fixes without interface changes belong in patch releases.
Semantic versioning is not new here. The August v0.2.0 release already distinguished stable vX.Y.Z tags from fast-moving b-number development builds. Those channels coexist: the 1.0.0 release page points to b12359 for its corresponding build assets.
The commitment concerns public library interfaces, not guaranteed speed, reliability or compatibility across every endpoint and file format. Saved-session compatibility is a separate issue, as the earlier llama.cpp saved-cache migration illustrates; that October change is not newly introduced by this announcement.
For an embedded integration, choose an exact release with matching headers and bindings, then check model loading, a representative request and shutdown on the intended hardware before replacing the working deployment. For a packaged app, follow its own release channel.