llama.cpp v1.0.0 Turns Version Numbers Into a Compatibility Contract

ggml-org shipped llama.cpp v1.0.0 on November 13, 2026, giving the C/C++ local AI inference project its first formal compatibility contract after 3.5 years of development. The underlying ggml tensor library hit v1.0.0 the same day, and the project now reports support for more than 150 model-architecture variants and all mainstream speculative-decoding methods.

For downstream developers, the headline change is procedural, not technical: version numbers now mean something specific. 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. Bug fixes without an API change trigger a patch bump.

Why does versioning matter now?

The policy exists because dependence on the project's library interfaces has grown. llama.cpp provides multimodal LLM inference through libllama; 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.

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

In plain words: the project has made breakage something it must announce in advance.

What changed in the release itself?

The v1.0.0 release notes pair the contract with a substantial cleanup:

• Removal of the deprecated public API, including 35 deprecated functions.
• Promotion of the NextN speculative-decoding API from the llama-ext.h extension header into the public llama.h header, placing it under the new versioning rules.
• OCP 8-bit floating-point (FP8) key-value caches for inference.
• A host-memory cache for mixture-of-experts (MoE) models with a configurable CPU share.
• 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.

The llama-server component received security and feature work. 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, and the Android chat editor can open the virtual keyboard.

What about hardware backends?

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 now be compiled as a dynamic library and optionally loaded at runtime, letting installations 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.

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 enabling more self-hosted runners across major hardware platforms. The maintainers are also integrating LLMs into their development cycle, 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 — and the expanded CI and hardware-runner program will determine whether routine releases stay dependable across the models and hardware those projects use.