Local AI engine llama.cpp reaches 1.0 and drops 35 deprecated functions

The team behind llama.cpp released version 1.0.0 on November 13 and set a rule for future updates to the software, which runs open AI models on personal computers and private servers. Changes that break the public C interface or the way a compiled program links to the library will raise the first number in the version. Version 1.0.0 itself removes 35 functions previously marked for retirement in the public header.

Developers who embed the engine in an app can now tell from a release number what kind of compatibility the maintainers intend to preserve. An app that still calls one of the functions removed since 0.9.0 will need changes and a new build to move to 1.0.0. The team also released version 1.0.0 of ggml, the underlying library that handles numerical operations.

What changes for apps moving to 1.0

The public C interface defines how an app calls the library, including function names and the inputs they take. A compiled app also expects the library to present those calls in a particular form when the program runs. The release policy covers both cases. Source code can still compile while a previously built copy of the app needs a rebuild to work with a replacement library.

Alongside the 35 deprecated functions, the maintainers dropped a separate function for configuring model warmup and removed a setting for memory defragmentation. They also moved parts of the speculative decoding interface from an extension header into the main public header. That technique proposes likely next tokens and checks them before including them in the response. Apps that used the relevant functions through the extension header may need to update where they import them from.

The release notes also list support for the Kimi K3.1 Pro model architecture. In the bundled web chat, users can organize conversations into named groups and preview Markdown as they type. When those features appear in another app depends on which engine build its developer ships. Users still need a compatible model file, and memory requirements vary with the model.

What the three numbers tell developers

Under the published rules, a breaking change to the public interface raises the first number. Support for a new model or a new public feature that preserves compatibility raises the middle digit. Bug fixes that leave the public interface intact raise the last digit. Those distinctions give teams that distribute the library a way to judge the scope of an update before opening its release notes.

The project continues to put out frequently updated development builds with a separate sequence of numbers. The 1.0.0 release page points to development build b12359, which was built from the same commit and lists downloads for platforms including macOS, Windows and Linux. The project also offers a desktop app for Mac and Windows 11, with model controls in the menu bar or system tray. Its distribution notes say the app currently uses development builds.

Packagers that use a system-wide copy of ggml have another dependency to account for. For an official llama.cpp tag, the team checks that the bundled ggml matches the separately released ggml. This lets distributions such as Debian and package managers such as Homebrew link to the installed library. In the project’s distribution discussion, a Homebrew maintainer said its checks also exercise packages that depend on the libraries when either is updated. Development builds use the copy included in the project at the time of each build, which can contain changes ahead of an official ggml release.

The Llama desktop app bundles the ggml copy from its engine build, according to the project’s distribution notes. On November 13 the project kept the official source tag and the platform builds under separate release entries.