llama.cpp v1.0.0 is out, and breaking changes now wait for a major version
The local-model runtime leaves 0.x with a written versioning rule. The 1.0 release also deletes deprecated functions, so anyone on 0.9 has one migration to do first.
On November 13, the ggml-org team at Hugging Face released llama.cpp v1.0.0 and ggml v1.0.0. From now on, breaking changes to the public C API land only on a major version bump, under semantic versioning. My read: the rule matters more than any feature in this release.
What 1.0 breaks on purpose
Version 1.0 is itself a breaking release, and the team planned it that way. That was deliberate. Pull request #32190 lists the API changes. The ones that will break a build are below, and the same pull request notes that ggml 1.0.0 prunes its own deprecated public API too.
| Item | Detail | Source |
|---|---|---|
Deprecated functions removed from llama.h |
35, plus llama_set_warmup |
PR #32190 |
| Renamed function | llama_set_embd_state_src is now llama_set_ctx_state_src |
PR #32190 |
| Removed command-line option | --defrag-thold |
PR #32190 |
| Model architecture variants (team’s count) | More than 150 | Hugging Face post |
The pull request also moves the NextN speculative-decoding API into llama.h.
If your code calls any of those, it won’t build against 1.0 without changes. In the planning discussion, the team said it had kept postponing these removals to avoid breaking third-party projects, and that a major release makes them easier for downstream projects to adapt to. Its author, the GitHub user ggerganov, called the removal “essentially a breaking change for downstreams and hence the major bump.”
The version rules, in one table
| Change type | Version bump | What the rule covers |
|---|---|---|
Breaking change to the public C API in include/ |
MAJOR | Removals and renames, like the 1.0 cleanup |
| Backward-compatible feature, backend update, model support or API addition | MINOR | New architectures, backend work, new API functions |
| Bug fix with no API change | PATCH | Fixes that leave the C API untouched |
That table is the whole policy, and its scope is narrow. The Hugging Face post says the team will be “stricter about making those boundaries visible to downstream consumers” as adoption grows. It covers the C API in the public headers, which means libllama and libggml. The published rules don’t mention llama-server’s HTTP endpoints or its command-line flags. The 1.0 release removed a flag as well. My read: the rule protects less than the headline suggests.
The reaction from people who ship on it
The pressure isn’t new. In GitHub Discussion #9276, a developer whose monitoring tool depends on llama.cpp’s server said an upstream change had broken their project and forced them to update and rebuild production instances. Because llama.cpp used rolling releases instead of semantic versioning, they wrote, third-party projects could not target specific versions. They asked for advance notice of breaking changes.
Replies in that thread pushed back on the framing. One pointed out that every master commit is tagged, so a pinned commit or tag already works, and that nobody should update a production version without testing it first. Maintainers said they had no clear plan for advance notice yet.
My read
I think a version number is the cheapest stability feature a project can offer, and this one is worth having. Before 1.0, pinning llama.cpp meant pinning a moving target and checking for breakage yourself. Now a 1.x pin is a claim the project has written down, and the next major number tells you to read the notes before you update. For someone running a model on their own machine, the change is small. For a team that bundles llama.cpp into an app, it decides whether an upgrade is scheduled or dreaded. That promise covers the C API, though. If your product talks to llama-server over HTTP, keep pinning and keep testing. For a sense of who already sits on this code, our BotPsy model post covers a model whose GGUF builds are meant to run through llama.cpp.
What to watch
The release notes promise more details at 3 PM CET, which is 9 AM Eastern. I haven’t seen that follow-up. Pre-release binaries cover Linux, macOS, Windows, Android and iOS. Packages are listed for Docker, Debian, Homebrew, conda-forge, MacPorts, Winget and XCFramework, so check which version your own channel actually installs. Also, the team says llama.cpp supports more than 150 architecture variants and all mainstream speculative decoding methods. That is their count, and I didn’t count them.
Note on sources: I read the Hugging Face post, the v1.0.0 GitHub release page, pull request #32190 and discussion #30566 directly. Discussion #9276 I read through its opening post and part of the replies, not the full thread. I did not build llama.cpp or test the API changes. Those 150-architecture and 3.5-year figures come from the team’s own post. My searches for wider reaction turned up only aggregator write-ups, with no tech-press or Hacker News coverage of the 1.0 release that I could read. The release page says more detail is coming, and I haven’t seen it yet.
Sources