llama.cpp v1.0.0: What a Stable libllama and libggml Mean for Local AI

llama.cpp reached version 1.0.0 on November 13, 2026. The Hugging Face post llama.cpp v1.0.0: A stronger foundation for the local AI ecosystem says both libllama and libggml now ship at 1.0.0, and that the project will signal API and ABI incompatibilities through major-version bumps. The tag is also live on the GitHub releases page as v1.0.0, published at 10:20 UTC.

The announcement is mainly a promise about how the project changes. The release itself is not empty, though: per the GitHub notes, it also removes deprecated public API, so the jump from v0.9.0 is a breaking one for code that still used those functions. This post explains what the promise covers, what the tag actually changes, and how to upgrade.

TL;DR

What did the team actually promise?

The announcement says the project is about 3.5 years old, counting from its first commit. Until now the numbering did not tell downstream users much. Builds were tagged continuously, and a developer who linked against the C headers had to read commits to learn whether a function had changed shape.

Version 1.0.0 changes that contract. The team says it will be "stricter about making those boundaries visible to downstream consumers." Concretely, the rules apply to all ggml-org projects and follow semantic versioning:

Two libraries carry the promise. libllama has its headers in llama.cpp/include/. libggml, the tensor library underneath, has its headers in ggml/include/. The split matters. Many projects, from desktop apps to language bindings, link one or both directly.

Our own earlier coverage shows why the change helps. In the v0.9.0 and ggml 0.29.0 write-up, a minor-looking release added a new tensor type, new copy APIs and a communicator interface. Under the new rules, additions like those are MINOR. A removal or signature change would force a MAJOR bump and a visible warning.

What does the v1.0.0 tag itself change?

The GitHub release notes cover the changes since v0.9.0. Highlights from that page:

• API cleanup. llama.h drops llama_set_warmup, 35 deprecated functions, and defrag_thold with its --defrag-thold flag. The NextN speculative API moves from llama-ext.h into llama.h, and llama_set_embd_state_src is renamed llama_set_ctx_state_src. clip.h is removed and folded into mtmd. ggml 1.0.0 also prunes its deprecated public API.
• New features. FP8 KV caches (-ctk/-ctv f8_e4m3), a host-memory MoE expert cache with a configurable CPU share, and loading of external PLE shards from separate GGUF files.
• Models. Three new text architectures (Kimi-K3.1-Pro, Ripple-65B-Preview and xing4_0), drama-3 TTS, and MageVL-Cowork and Kimi-K3.1 vision.
• Server. Security fixes for CORS origins, DNS rebinding and SSRF, new opt-in flags for unauthenticated tools and private media URLs, MCP tool-call cancellation, and an OpenAI-compatible /v1/audio/speech endpoint.
• Web UI. Chat groups, a live-preview markdown editor and a mobile-friendly layout.

If your code calls any removed function, it will not build against 1.0.0. That is the point of a major version, and it is the first thing to check.

What is not promised

Read the promise narrowly. The announcement does not say that output will be identical between versions, that every GGUF file will load forever, or that command-line flags will stay fixed. The versioning rules apply to the public C API and, by the team's wording, to API and ABI boundaries. The command-line tools, the server and the model-conversion scripts are not named in the rules we could verify.

That gap is normal for a first stable release, and it tells you what to test. If you pin a version and script llama-server flags, run your own smoke test after each upgrade. Treat the semantic-versioning guarantee as protection for compiled integrations, not for shell scripts.

Why does a version number matter for local AI?

Local inference has grown into a stack. A model file in GGUF format sits on top of ggml kernels. A runtime such as llama.cpp loads the file. Apps, editors, agents and chat front ends sit on top of the runtime. Our guide to what llama.cpp is walks through that stack for newcomers.

When the runtime changes an API without a signal, every layer above it can break. Packagers on Debian, Homebrew or conda-forge then have to guess which release is safe to ship. A major-version signal lets them hold back a breaking update, and it lets app developers declare a compatible range instead of a single commit.

The effect shows up in the ecosystem around the project. Recent posts on this site cover tools that wrap or reimplement it: PS5LM, which runs llama.cpp on a jailbroken console, Tensorfold, a Zig inference engine, and InferSSD, which targets an 800B model on consumer hardware. Each depends on stable behavior from the core runtime, or competes with it.

Where can you get it?

The announcement lists the distribution channels, which is a useful snapshot of how far the project has spread:

A sensible default is to use the channel you already trust for other tools. On macOS or Linux, Homebrew is the shortest path. On Windows, Winget is the equivalent. App developers on Apple platforms can take the XCFramework. If you build from source, check out the v1.0.0 tag so your build matches what packagers ship.

How is the project run behind the scenes?

The announcement includes a few facts about project health that explain why the team felt ready to call it 1.0.

• Continuous testing. Continuous integration uses Hugging Face Buckets and HF Jobs to test every change merged to master.
• Hardware partners. NVIDIA, AMD, Qualcomm, Arm, IBM and Intel contribute self-hosted runners, so backends are tested on real hardware.
• Backends as plugins. ggml runs on many hardware types through dedicated backends, which can be built as dynamic libraries and loaded at runtime.
• Model coverage. The project supports more than 150 architecture variants and all mainstream speculative decoding methods.
• Use of LLMs. The team says it uses LLMs in its development process but will keep control of architecture and code quality.
• Desktop apps. The same team builds the Llama desktop apps for macOS and Windows.

Hugging Face's earlier work on Transformers matching llama.cpp on GGUF performance shows how closely the two projects now work together. The 1.0 post is published on the Hugging Face blog under the ggml-org organization, which reflects the same relationship.

What should you do before upgrading?

Here is a practical checklist, based on what the announcement and release page say.

1. Check how you consume llama.cpp. If you only run the command-line tools, upgrade on your normal schedule. If you link libllama or libggml, read the release notes for any API changes made before the 1.0 tag.
2. Pin a major version. In your build files, set a compatible range such as 1.x rather than a floating latest tag. That is the main benefit the new rules buy you.
3. Test your models. Load the GGUF files you rely on and run a fixed prompt set. Compare outputs and speed to your current build.
4. Test your backend. Backends such as CUDA, Metal and Vulkan are loaded as libraries. Confirm the one you use still initializes on your driver version.
5. Watch for the next MAJOR. A future 2.0 is the signal to schedule migration work. Subscribe to releases on the repository.

If you run a hybrid setup, such as a laptop with unified memory versus a desktop with a discrete card, our comparison of MacBooks and dedicated GPUs for local LLMs explains which hardware fits which model size. The runtime release does not change that math.

How does this compare with other local runtimes?

Most competing local runtimes already use version numbers in a similar way, but few build on a single C library that many other tools embed. That embedding is what makes llama.cpp's contract matter. A change in libggml can ripple into tools that never mention llama.cpp by name. Our llama-modchip GGUF inference guide covers another project built close to that layer.

We did not run side-by-side benchmarks for this post, and the announcement does not provide any. Treat any claim of a speed-up from the version number alone as unverified. If you benchmark v1.0.0 against v0.9.0 on your own hardware, record the model, the quantization, the backend and the driver version, so the result is repeatable.

What are people asking?

Is 1.0 a sign the project is finished? No. The team describes a "foundation," and the minor-version rules explicitly allow new features, backends and models. The project keeps moving at the same pace. The difference is how breaking changes are announced.

Will my old GGUF files still work? The announcement does not make a file-format promise. The v0.9.0 notes show that new file types get added over time, and nothing we found says old files stop loading. Verify with your own files.

Does this affect agent tools that use local models? Indirectly. Agent harnesses that call a local server depend on its HTTP interface rather than the C API. For example, the Hermes Agent v0.22.0 release added one-click local models. A steadier runtime makes those integrations easier to maintain, but the HTTP surface is not covered by the C API rules.

Why now? The announcement gives no single trigger. Three and a half years of history, a broad packaging footprint and hardware partners running CI are the context it offers. We do not know the internal reasoning, so we do not guess at it.

Bottom line

llama.cpp v1.0.0 is a trust signal. It tells builders that the C libraries will change in labeled steps, and it clears out old API to start from a clean base. We ran no benchmarks, so we make no speed claims. If you ship software on libllama or libggml, pin a major version and add the checklist above to your release process. If you run models for yourself, upgrade through your usual package manager and keep your own smoke tests.

Details are accurate as of November 13, 2026. Check the official release page for the latest notes.

Related reading

• What is llama.cpp and how to run models locally
• llama.cpp v0.9.0 and ggml 0.29.0 release breakdown
• Hugging Face Transformers now matches llama.cpp on GGUF
• MacBook vs dedicated GPU for local LLMs
• PS5LM: llama.cpp on a jailbroken PS5
• Tensorfold: Zig local LLM inference
• Official announcement on Hugging Face
• llama.cpp on GitHub