llama.cpp 1.0.0 locks in a stable public API after three and a half years

llama.cpp declares its API stable at 1.0.0

The local inference engine llama.cpp shipped version 1.0.0 on November 13, 2026, and the milestone is defined by a promise rather than a benchmark. According to a dev.to post covering the release, the project's public API is now considered stable, and breaking changes will only arrive with a major version bump.

The release ends roughly three and a half years of versioning builds by raw commit number, a scheme that gave developers no signal about whether an upgrade would break their integration. From 1.0.0 onward, llama.cpp follows semantic versioning tied to the public C API exposed in the project's include directory.

What version 1.0 removes

The dev.to write-up reports that the release uses the major-version moment to prune the deprecated public API: 35 deprecated functions have been deleted, along with the warmup setter (llama_set_warmup) and the defragmentation-threshold option. The NextN speculative-decoding API has also moved from the llama-ext.h extension header into the main llama.h header, which places it inside the API now covered by the stability rules.

The companion tensor library ggml shipped its own v1.0.0 at the same time, with its deprecated API and legacy operations removed as well.

The versioning contract is spelled out concretely: a MAJOR bump signals a breaking change to the public C API, a MINOR bump covers backward-compatible features, backend updates, model additions or API additions, and a PATCH release is a bug fix with no API change. Project creator Georgi Gerganov, quoted in the post, framed the motivation as dependence: every new integration means more developers relying on the library interfaces, so a flexible but stable API is paramount.

New features shipped alongside the contract

According to the dev.to post, the release carries substantive technical changes too:

• Support for an OCP FP8 KV-cache through the f8_e4m3 type, with optional static per-tensor scales, reducing memory footprints for long conversations.
• A host-memory MoE expert cache with a configurable CPU share, improving mixture-of-experts models on machines without large GPUs.
• Three new text architectures: Kimi-K3.1-Pro, Ripple and xing4_0.
• Security hardening in llama-server, including fixes for SSRF, CORS and DNS-rebinding attacks, with HF_TOKEN now limited to huggingface.co hosts.
• A new /v1/audio/speech endpoint and a redesigned web UI for llama-server, the OpenAI-compatible API server that many applications target.
• Official quick-start installation scripts for Unix-like systems and Windows.

The project now supports more than 150 model-architecture variants, and pre-built artifacts cover Linux, macOS, Windows, Android and iOS, with distribution channels including Docker, Debian, Homebrew, conda-forge, MacPorts, Winget and XCFramework listed in the release notes.

A caution before upgrading

The post warns that 1.0 is a stable contract but not a drop-in upgrade for every existing application. Code that calls any of the 35 removed deprecated functions will fail at compile time. Developers are advised to check the release notes and fix those call sites, after which future upgrades should not require the same churn without a major-version warning.

Why it matters

llama.cpp is not a model but the open-source C and C++ inference engine, built on ggml, that runs GGUF-packaged models on CPUs, phones, GPUs and servers. As the dev.to post notes, it sits underneath much of the local AI ecosystem, including Ollama and LM Studio, so its API policy effectively sets the floor for a large share of desktop AI tools, private chatbots, coding assistants and OpenAI-compatible local servers.

A stable API changes the economics of building on it: instead of pinning a commit hash and hoping nothing shifts, developers can plan upgrades, and downstream projects can vendor the library without constant rework. That matters as local inference matures from a curiosity into a production path, with the privacy of on-device data, no per-token billing, offline operation and immunity to a provider changing the model or terms overnight. The 1.0 release does not mean the engine is finished — it means the ecosystem around it can finally build long-term on top of it.