llama.cpp, the free engine behind a lot of local AI, has finally reached version 1.0. The ggml-org team released llama.cpp v1.0.0 and its ggml library v1.0.0 on 13 November 2026, three and a half years after the project started. The big change isn't speed. It's a promise: from now on, anything that breaks programs built on llama.cpp gets a new major version number.
I run llama.cpp on my 8 GB RTX 4060 Ti, and I think this release is a good moment to say it out loud: if you use LLMs, llama.cpp isn't a strange hacker tool anymore. It's the normal way to run a model on your own PC.
What is llama.cpp?
llama.cpp is an open-source program that runs large language models on ordinary hardware: Windows, Mac and Linux PCs, phones, and graphics cards from NVIDIA, AMD, Intel and others. You download a model file (a GGUF), and llama.cpp runs it, either in a terminal or through llama-server, which gives you a chat page in your browser and an OpenAI-style API.
Many popular local AI apps are built on top of it. The project page on GitHub has about 135,000 stars.
What does "v1.0" actually mean?
It means stability. Until now llama.cpp shipped as numbered builds, often several a day, and the programming interface could change at any time. The Hugging Face announcement says that "moving forward, both llama.cpp and ggml will reflect API and ABI incompatibilities with major-version bumps." In plain words:
| Version part | When it goes up | What it means for you |
|---|---|---|
| Major (1.x.x → 2.0.0) | A breaking change to the public C API | Apps built on llama.cpp may need updating |
| Minor (1.0 → 1.1) | New features, new models, backend updates | Safe to upgrade |
| Patch (1.0.0 → 1.0.1) | Bug fixes only | Safe to upgrade |
For someone who just runs llama-server, this changes little day to day. For people building apps on top of llama.cpp, it's a big deal. They can now tell from the version number whether an upgrade might break their code. To make room for that promise, v1.0.0 removed 35 old, deprecated functions in one go.
The daily builds aren't stopping, by the way. v1.0.0 matches build b12359, and the team has already published newer builds since.
What's new in llama.cpp v1.0.0?
The GitHub release notes list a lot. The parts I think matter most for home users:
- MoE expert cache: a cache in normal system memory for the "experts" of mixture-of-experts models, with a setting for how much work the CPU takes when an expert isn't on the GPU. This is aimed at exactly my situation: big MoE models on a small graphics card.
- FP8 KV cache: a new option (
-ctk/-ctv f8_e4m3) to store the conversation memory in 8-bit floating point. - Faster model loading on Windows: unbuffered loading, matching what Linux already had.
- Graphics card work in ggml 1.0.0: faster small-batch quantized maths and MoE fusion on CUDA and Metal, a Vulkan FlashAttention path for prompt processing, and work on SYCL, OpenCL, WebGPU and Qualcomm Hexagon.
- New models: Kimi-K3.1-Pro, Ripple-65B-Preview and xing4_0, the drama-3 text-to-speech model, and Kimi-K3.1 and MageVL-Cowork vision.
- A safer server: fixes for CORS, DNS rebinding and SSRF, opt-in switches for unauthenticated tools and private media URLs, and the
HF_TOKENnow only goes to huggingface.co. - A new web UI: chat groups, a live markdown editor, PDF previews, and proper phone layouts.
- Speech: an OpenAI-compatible
/v1/audio/speechendpoint inllama-server.
One honest note: neither the announcement nor the release notes give before-and-after speed numbers. They describe the performance work, but don't put a percentage on it.
Has llama.cpp really got faster?
In my daily use, yes, a lot, over the last few months. This is my experience, not a benchmark. I didn't re-test old and new builds side by side for this post.
What I can show is how fast the project moves. My PC has llama.cpp build b11540 from 10 October and b11643 from 15 October. v1.0.0 is build b12359, released on 13 November. That's more than 800 builds in about five weeks.
That pace shows up in real life. In October, the MiniCPM-V 4.7 vision model wouldn't load in Ollama at all, but a llama.cpp build from a few days earlier ran it on my 8 GB card at about 225 to 255 tokens per second. On the same card, my Underdog Saluki 27B test ran at 12.1 tokens per second on the CUDA build against 3.3 on Vulkan, so picking the right build mattered as much as the model.
For me, these improvements are what make local LLMs practical on an 8 GB card, not just something to try once.
Should you upgrade to llama.cpp v1.0.0?
If you already use a recent build, there's no rush. v1.0.0 is a milestone, not a different program. Upgrade when you want one of the new features, or a model that needs it. If you build an app on libllama, check your code against the removed functions before you move to 1.0. From now on, you can trust the version number to warn you.
If you've never tried local AI, this is a good time to start. Windows builds come for CUDA, Vulkan and CPU, and llama.cpp is also on Winget, Homebrew, Docker and conda-forge.
Read next
- MiniCPM-V 4.7 1B on an 8GB GPU: tested against 4.6 and 4.5
- Underdog Saluki 27B on an 8GB GPU: why I got 4.7 tokens/s
- AI photo search on an 8GB GPU: 7,600 photos tagged locally
- Ripple-65B Preview, one of the new models llama.cpp v1.0 supports
Sources: ggml-org, "llama.cpp v1" on the Hugging Face blog (13 November 2026); the llama.cpp v1.0.0 release notes on GitHub; GitHub's release pages for builds b11540, b11643 and b12359; and the ggml-org/llama.cpp repository page. The speed improvement is my own experience from daily use on an RTX 4060 Ti 8 GB, not a measured benchmark; the MiniCPM-V and Saluki figures come from my earlier tests linked above. Checked 15 November 2026. The images were made locally with Qwen Image 2.1, and AI helped me with the research and the English.
