Llama.cpp V1.0.0 Sets API Stability Rules for Local AI Tools

ggml-org announced llama.cpp v1.0.0 on November 13, 2026, giving the C/C++ local AI inference project a formal compatibility contract for downstream developers. The underlying ggml tensor library also reached v1.0.0, with the project reporting support for more than 150 model-architecture variants and all mainstream speculative-decoding methods.

Versioning Becomes a Public Contract

Both projects will signal future source-level API incompatibilities and ABI, the binary interface used by compiled applications, through major-version increases. Breaking public C API changes trigger a major bump. Backward-compatible features, backend updates, model support and API additions trigger a minor bump, while bug fixes without an API change trigger a patch bump.

The policy follows 3.5 years of development and growing dependence on the project’s library interfaces. llama.cpp provides multimodal LLM inference through libllama, while ggml supplies the machine-learning tensor layer through libggml. The software uses quantization, optimized backends and portable C/C++ code to target hardware from consumer machines to enterprise servers.

That gives package maintainers and application developers a version signal for assessing whether an upgrade can break their integration. The maintainers’ August 7, 2026 release-process discussion adds a related safeguard: an official llama.cpp release tag is created only when its internal ggml copy is identical to the released ggml copy. The condition is intended to keep release-tag builds compatible with a system-wide ggml installation, the arrangement used by the Debian and Homebrew packages described in the document.

Runtime, Model and Server Changes

The llama.cpp v1.0.0 release notes pair that contract with a substantial cleanup. The release removes its deprecated public API, including 35 deprecated functions, while promoting the NextN speculative-decoding API from the llama-ext.h extension header into the public llama.h header. The move places this speculative-decoding interface inside the public API covered by the new versioning rules.

New inference facilities include OCP 8-bit floating-point (FP8) key-value caches, a host-memory cache for mixture-of-experts (MoE) models with a configurable CPU share, and loading of external PLE or engram data from separate GGUF shards. Model additions cover the Kimi-K3.1-Pro, Ripple and xing4_0 text architectures, drama-3 text-to-speech, and vision support for MageVL-Cowork and Kimi-K3.1.

For llama-server, the release addresses server-side request forgery, cross-origin resource sharing and DNS-rebinding issues, and restricts HF_TOKEN to huggingface.co hosts. MCP tool calls are cancelled when a client disconnects or times out, with notification to the MCP server. A new OpenAI-compatible /v1/audio/speech endpoint extends the server’s audio interface.

The redesigned web interface adds named chat groups and a live-preview Markdown editor. Mobile layouts use device safe areas and full-screen dialogs, while the Android chat editor can open the virtual keyboard.

Hardware Backends and Release Infrastructure

The companion ggml v1.0.0 release removes deprecated APIs and legacy DIAG_MASK operations, adds configurable YaRN truncation and FP8 support, and avoids uploading scheduler inputs that are not read. CUDA and Metal gain few-row quantized matrix multiplication and MoE fusion work. Other backend additions include an Intel Vulkan prefill FlashAttention kernel, a device-side SYCL MoE scheduler, decomposed Adreno FlashAttention in OpenCL, new WebGPU kernels and expanded Hexagon operation coverage.

Each ggml backend can be compiled as a dynamic library and optionally loaded at runtime, allowing installations to select hardware-specific code. Pre-release artifacts cover Linux, macOS, Windows, Android and iOS, with Docker, Debian, Homebrew, conda-forge, MacPorts, Winget and XCFramework providing additional distribution channels whose platform coverage varies.

To support the development pace, the team says Hugging Face Buckets and Jobs are scaling continuous-integration capacity for changes landing on the master branches. Hardware support from NVIDIA, AMD, Qualcomm, Arm, IBM and Intel is also enabling more self-hosted runners across major hardware platforms. The maintainers are integrating LLMs into their development cycle as well, while identifying code quality, architectural control and understanding of implementation details as their priorities.

For downstream projects, the release turns compatibility into an explicit development obligation for a fast-moving open-source library. Version rules can communicate breakage; the expanded CI and hardware-runner program helps determine whether routine releases remain dependable across the models and hardware those projects use.