Skip to content
audiotale.net
Sign in
NewsNews

llama.cpp 1.0.0 and ggml 1.0.0: removed APIs, new server flags, what to change

llama.cpp and ggml reached 1.0.0 on 13 November 2026, removing deprecated functions and adopting strict semantic versioning for the C API.

audiotale.net team

· 6 min read

Written by AI from the sources linked below. How we use AI

On this page
  1. Key points
  2. What to do
  3. What happened
  4. Background
  5. How it works
  6. What it means
  7. What we don't know yet
  8. What to watch next
  9. Sources

llama.cpp, the C/C++ engine behind much of the local AI ecosystem, shipped version 1.0.0 on 13 November 2026, together with its tensor library ggml. The release removes a long list of deprecated functions, so anyone who builds on libllama or libggml should read the removals before upgrading. It also changes two server defaults for security, and it promises that from now on breaking changes to the public C API will be signalled by a major version bump.

Key points

  • llama.cpp v1.0.0 and ggml v1.0.0 were released on 13 November 2026, announced in a Hugging Face post by the ggml-org team.
  • From now on, a breaking change to the public C API in ./include means a MAJOR bump; backward-compatible features, backend updates and model support mean MINOR; bug fixes without API change mean PATCH.
  • The release removes the deprecated public API, including llama_set_warmup and 35 other deprecated functions, the defrag_thold parameter and the --defrag-thold option, and clip.h (folded into mtmd).
  • The server now needs explicit flags for unauthenticated tool use (--allow-unauthenticated-tools) and private media URLs (--media-allow-private-urls), and HF_TOKEN is sent only to huggingface.co hosts.
  • The project says it supports more than 150 model architecture variants, and lists eight distribution channels, from Homebrew and Winget to Docker and an XCFramework.

What to do

  • If you only run models (the CLI or llama-server): update, then check your launch scripts. Remove --defrag-thold if you pass it. If you used tool calling without authentication, or fetched images from private network addresses through the server, add the new flags deliberately instead of by habit.
  • If you embed the library (bindings, apps, plugins): build against v1.0.0 in a branch and fix compile errors. Look for llama_set_warmup, the other deprecated functions, llama_set_embd_state_src (renamed llama_set_ctx_state_src), the NextN API (moved into llama.h) and any use of clip.h.
  • If you ship binaries or containers: pin the version. The semantic versioning rules mean a MAJOR bump is the signal to retest.
  • If you use a Hugging Face token with llama.cpp to download gated models: nothing changes for huggingface.co, but the token is no longer sent to other hosts.

What happened

The announcement appeared on the Hugging Face blog on 13 November 2026, written by Daniel Bevenius, Georgi Gerganov, merve and colleagues from the ggml-org team. It says the project has grown over its 3.5 years of existence, that many downstream applications depend on it, and that "a flexible but stable API" matters for them. For that reason both llama.cpp and ggml now reflect API and ABI incompatibilities with major version bumps.

The post names two releases: llama.cpp v1.0.0, which provides libllama with headers in llama.cpp/include/, and ggml v1.0.0, which provides libggml with headers in ggml/include/. The rules it sets for all ggml-org projects using semantic versioning are short: a breaking change to the public C API in ./include raises the MAJOR number, a backward-compatible feature, backend update, model support or API addition raises MINOR, and a bug fix without API change raises PATCH.

The GitHub release notes, published the same day, give the detail. They list what the release removes and renames:

  • the deprecated public API, including llama_set_warmup and 35 other deprecated functions;
  • the defrag_thold parameter and the --defrag-thold command-line option;
  • llama_set_embd_state_src, renamed to llama_set_ctx_state_src;
  • the NextN API, moved from llama-ext.h into llama.h;
  • clip.h, removed and consolidated into mtmd;
  • in ggml, a pruned deprecated public API, the legacy DIAG_MASK ops, the non-fused GDN paths and the ubatch-dependent graph node budget;
  • model loading is stricter: projector and patch embedding tensors and a 2x2 spatial merge are now required.

The release notes also add features. For memory and caching, they list FP8 KV caches (selected with -ctk and -ctv set to f8_e4m3), a host-memory cache for mixture-of-experts weights with a configurable CPU share, and loading of external per-layer embedding shards with --shard and --ple. They add support for the models Kimi-K3.1-Pro, Ripple-65B-Preview, xing4_0 and the drama-3 text-to-speech model, with vision support for MageVL-Cowork and Kimi-K3.1. The server gains an OpenAI-compatible /v1/audio/speech endpoint, an --sleep-idle-seconds option and cancellation of MCP tool calls on disconnect or timeout. The web UI is redesigned with chat groups, a live-preview Markdown editor and a mobile-friendly layout. On Windows, model loading is now unbuffered, mirroring the Linux DirectIO path. We have not tested any of these features ourselves; they are taken from the release notes.

Background

llama.cpp began as a way to run large language models on ordinary hardware through a portable C/C++ implementation and quantization. The Hugging Face post describes it today as supporting "a wide range of hardware" from consumer machines to enterprise servers, through backends that each compile as a dynamic library and can be loaded at runtime.

Until now, anyone depending on the library had to track a stream of changes without a clear signal of which ones would break their code. The semantic versioning rules in this release are meant to fix that: a number now says whether an upgrade can break the build.

How it works

The project lists eight ways to get its software:

Platforms covered by each llama.cpp distribution channel (count of platforms)platforms
Platforms covered by each llama.cpp distribution channel (count of platforms) (platforms)
platforms
Pre-release artifacts (GitHub)5
conda-forge3
Homebrew2
Docker1
Debian1
MacPorts1
Winget1
XCFramework2

Source: Hugging Face, llama.cpp v1.0.0 announcement

Per the post, pre-release artifacts cover Linux, macOS, Windows, Android and iOS; Docker and Debian cover Linux; Homebrew covers macOS and Linux; conda-forge covers Windows, macOS and Linux; MacPorts covers macOS; Winget covers Windows; the XCFramework covers iOS and macOS. The chart counts the platforms the post lists for each channel; it says nothing about popularity.

The development section of the post is also worth a read. The team says it continues "to adapt and integrate LLMs" in its own development cycle, but that code quality, control of the architecture and understanding of implementation details stay the top priorities. To keep pace, it invests in continuous integration: Hugging Face's HF Buckets and HF Jobs provide capacity to test every change that lands on the master branches, and hardware support from NVIDIA, AMD, Qualcomm, Arm, IBM and Intel lets the project enrol more self-hosted runners across the major hardware platforms.

What it means

For application developers, the immediate cost is one porting pass; the benefit is that future breaks should be announced by a MAJOR number rather than found at compile time. Pinning to 1.x becomes a meaningful promise for the C API.

For people running local models, the server changes are the ones to notice. Requiring explicit flags for unauthenticated tool use and private media URLs, and the release notes' mention of fixes for SSRF, CORS and DNS rebinding, move defaults towards safer behaviour for anyone exposing llama-server beyond their own machine. Restricting HF_TOKEN to huggingface.co hosts means the token is not sent to other hosts.

For packagers and distributors, the post points to a ggml-org discussion on adding the projects to packaging and release pipelines, and says the team wants to widen distribution. A stable version number makes that easier.

For the wider ecosystem, a 1.0 label from a project this widely embedded is a signal of maturity, not a change in capability: most of the new features, from FP8 KV caches to new model support, are ordinary MINOR-type additions.

What we don't know yet

  • How many downstream projects will break. The release notes list removals but no count of affected dependants, and we found no independent outlet reporting migration experience yet.
  • Whether the new server flags will be set widely by default in wrappers and desktop apps.
  • Performance effects. Neither the post nor the release notes give benchmark figures for FP8 KV caches or the MoE expert cache, so we do not quote any.
  • The post does not give contributor counts, download numbers or a roadmap for 1.x.

What to watch next

Watch for patch releases (1.0.x) that fix upgrade problems, for binding libraries and apps announcing 1.0 compatibility, and for the first MAJOR bump, which will be the first real test of the new versioning promise.

Sources

Written by

audiotale.net team

The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.