Products & Tools

llama.cpp v1.0.0 turns versioning into a public compatibility contract

ggml-org shipped llama.cpp v1.0.0 on November 13, 2026, formalizing API stability rules: major bumps signal breakage, and ggml v1.0.0 reaches 150-plus model architectures.

Llama.cpp V1.0.0 Sets API Stability Rules for Local AI Tools
Llama.cpp V1.0.0 Sets API Stability Rules for Local AI ToolsStockSnap / pixabay
By Rebecca Stone4 min read

Why it matters

  • ggml-org announced llama.cpp v1.0.0 and ggml v1.0.0 on November 13, 2026.
  • Major-version bumps now signal source and ABI breakage; the policy follows 3.5 years of development.
  • ggml reports support for more than 150 model-architecture variants and all mainstream speculative-decoding methods.
  • The release removes 35 deprecated functions and promotes the NextN speculative-decoding API into the public llama.h header.
  • Official release tags require an identical internal ggml copy, per the August 7, 2026 release-process discussion.

ggml-org released llama.cpp v1.0.0 on November 13, 2026, giving the C/C++ local AI inference project a formal compatibility contract that signals source-level and binary breakage to downstream integrators through major-version bumps. The underlying ggml tensor library reached v1.0.0 in the same announcement, with the project reporting support for more than 150 model-architecture variants and all mainstream speculative-decoding methods.

The release matters well beyond one repository. llama.cpp provides multimodal LLM inference through libllama, while ggml supplies the machine-learning tensor layer through libggml. Package maintainers and application developers have depended on those library interfaces for 3.5 years without a version signal telling them whether an upgrade could break their integration. That gap now closes.

What does the new versioning policy promise?

Both projects will signal future source-level API incompatibilities and ABI — the binary interface used by compiled applications — through major-version increases. The rules split cleanly across three tiers:

  • Major bump: breaking public C API changes.
  • Minor bump: backward-compatible features, backend updates, model support and API additions.
  • Patch bump: bug fixes without an API change.

The policy follows growing dependence on the project's library interfaces. The software uses quantization, optimized backends and portable C/C++ code to target hardware from consumer machines to enterprise servers, which makes a predictable version signal a practical necessity for anyone shipping llama.cpp inside a larger product.

A related safeguard comes from the maintainers' August 7, 2026 release-process discussion. An official llama.cpp release tag is created only when its internal ggml copy is identical to the released ggml copy. The 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.

What changed in the codebase itself?

The llama.cpp v1.0.0 release notes pair the versioning contract with a substantial cleanup. The release removes its deprecated public API, including 35 deprecated functions. It also promotes the NextN speculative-decoding API from the llama-ext.h extension header into the public llama.h header, placing that 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.
  • 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 breadth tracks with the project's reported 150-plus architecture variants — support that has made llama.cpp a default substrate for local inference tooling.

What is new in llama-server?

The server component received security and functional changes. 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 sent 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.

How does ggml v1.0.0 fit in?

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.

Backend work concentrates on performance. 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, allowing installations to select hardware-specific code. Pre-release artifacts cover Linux, macOS, Windows, Android and iOS. Docker, Debian, Homebrew, conda-forge, MacPorts, Winget and XCFramework provide additional distribution channels whose platform coverage varies.

Who is backing the build infrastructure?

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 enabling more self-hosted runners across major hardware platforms.

The maintainers are integrating LLMs into their own development cycle as well. They identify code quality, architectural control and understanding of implementation details as their priorities — a signal that accelerated, AI-assisted development is being paired with explicit quality controls rather than left ungoverned.

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.

Source: unite.ai

Share this article:

More from Rebecca Stone

Rebecca Stone

Show full bio

Correspondent covering companies, deals and strategy in artificial intelligence and machine learning at AI In Context.

602 articles

Related articles

  1. llm-d 1.0 arrives to tame production AI inference at scale
  2. llm-d 1.0 arrives: Google's open inference stack cuts median TTFT 85%
  3. Google Ships Gemini 3.1 Pro, More Than Doubling Reasoning Score
  4. TIER IV Open-Sources Five Autonomous Driving Models for Autoware
  5. LangSmith, Langfuse, Opik and Braintrust All Built AI Gateways in 2026

« Previous articleNext article »