llama.cpp 1.0 Shipped. Local Inference Just Grew Up.

llama.cpp 1.0 landed on November 13, 2026, and the headline isn’t a feature.

It’s a promise about version numbers.

The ggml-org team put out llama.cpp v1.0.0 and ggml v1.0.0 on the same day. The C/C++ inference library and the tensor math sitting underneath it. The announcement on Hugging Face says both projects “will reflect API and ABI incompatibilities with major-version bumps.” If you’re gonna run models on your own hardware, read that sentence twice. Because it’s the thing that turns local inference into software you can build against instead of a repo you have to babysit.

To be clear about what this isn’t: it’s an inference-library release, not a new foundation model, as reports describe it.

And there’s real cargo in the release besides the number.

The deprecated public API is gone, llama-server got hardened, OCP FP8 KV caches arrived, a host-memory mixture-of-experts cache showed up, new architectures landed including Kimi-K3.1-Pro. And the web UI got redesigned, per the official release notes. All useful.

But the stability promise is what changes what you’re allowed to build on top.

The Versioning Contract Inside llama.cpp 1.0

The headline feature is a paragraph, and it comes with three definitions. A major release is a “Breaking change to the public C API in ./include”. A minor release is a “Backward-compatible feature, backend updates, model support, or API addition”. A patch is a “Bug fix with no API change” under the announced policy. The policy literally names a directory. That’s how specific it gets.

For operators the translation is short: the version number is now a tripwire.

Anything that stays 1.x and only moves the second or third digit is safe to pull.

The next 2.0 becomes a scheduled migration with a date you pick.

And v1.0.0 spends the promise immediately.

The deprecated public API didn’t get hidden. It got removed. The official release states the removal in general terms, while a contemporaneous report counts 35 deprecated functions. The NextN/speculative API got promoted into llama.h in the same pass. The kind of housekeeping that looks boring right up until your build breaks on it.

Freight went through this decades ago.

Once shipping containers settled on standard sizes, every port and every truck could handle every box without a custom plan drawn up for each one.

Semantic versioning is that same trick applied to a library: the box changes, the interface to it doesn’t. And your upgrade stops needing a custom plan.

Boring discipline is the feature, honestly.

A solo operator can’t sit there reading diffs.

And semver is the difference between reading a changelog on your own schedule and finding breakage in production. Most 1.0 announcements are marketing.

This one’s a support policy.

What llama.cpp 1.0 Shipped Besides the Version Number

The feature list earns its place next to the bump — full notes here.

OCP FP8 KV caches: the KV cache eats a big chunk of memory in long-context local sessions.

And a smaller numeric format is exactly the kind of change that decides whether a long run fits on your hardware at all.

A host-memory MoE expert cache with a configurable CPU share gives you an actual knob for trading CPU work against expert storage. Loading of external PLE shards landed too, and the NextN/speculative API moved into llama.h.

New architectures: Kimi-K3.1-Pro, Ripple, and xing4_0 for text.

Yes, xing4_0, a name nobody would make up.

Plus drama-3 for text-to-speech (intelligibberish). Vision and audio got MageVL-Cowork and Kimi-K3.1 vision support, plus Gemma 4 streaming audio input (accessallgpt).

The web UI was redesigned as well: chat groups, a live-preview Markdown editor, mobile layout changes.

The server line needs its own paragraph.

The release notes say v1.0.0 “hardens llama-server (SSRF, CORS, DNS rebinding, MCP tool cancellation) and adds a /v1/audio/speech endpoint.” SSRF and DNS rebinding are precisely the attacks that apply when a server on your network can be coaxed into fetching or answering things it shouldn’t. Hobby projects ship features. Software that intends to survive patches its attack surface. And the security work landing in the same release as the 1.0 stamp tells you which one this is.

The speech endpoint matters in its own quiet way.

A server that produces audio out, not just text in, supports a different class of app than the chat-only local setups did.

What llama.cpp 1.0 Means for Solo Builders and Small Teams

For solo builders and small businesses, this is the point where local inference stops being a science fair project.

You get a support posture instead of a repository: pin 1.x, expect minors to stay compatible, treat a future 2.0 as a planned migration.

It’s the same discipline you already apply to everything else you deploy. And it now extends to the thing that runs your models.

Notice what the weak link actually was, though. Model quality was never the blocker for running sensitive workloads on your own hardware — breaking API churn was.

A versioning contract attacks that directly, which is why I care more about the policy paragraph than about any single feature listed above.

How to Upgrade to llama.cpp 1.0 Safely

Do you know which parts of your code touch the C API directly?

If the answer’s no, that’s the first thing to find out, as the deprecated public API is removed, not hidden. And one report counts 35 functions in that removal.

Then the boring part, in order:

– Pin the version you deploy and write down where it lives, since the pin only means something now that the policy exists.
– Audit every direct C API call against the removal list before you bump anything.
– Rebuild against v1.0.0 and fix what the compiler flags. The NextN/speculative promotion lives in llama.h now.
– Test the rebuilt binary before you swap out the old one.
– Upgrade llama-server promptly if other machines can reach it, since the SSRF, CORS, and DNS rebinding fixes aim at exactly that exposure.

And if you’d written local inference off on the grounds that the stack breaks too often, that objection just got weaker.

llama.cpp 1.0 FAQ: Breakage, Compatibility, and Server Security

Does llama.cpp 1.0 break existing code?

Yes, if that code calls the deprecated public C API directly — it’s removed in v1.0.0.

And one report counts 35 functions in the removal. Code that stays within the supported 1.x surface is meant to pull cleanly.

Will llama.cpp 1.x releases stay backward-compatible?

That’s the policy.

Minors are a “Backward-compatible feature, backend updates, model support, or API addition”, patches are a “Bug fix with no API change”. And breakage is reserved for majors, which “will reflect API and ABI incompatibilities with major-version bumps.”

Is llama-server safe to expose after 1.0?

Safer, not safe by default. v1.0.0 “hardens llama-server (SSRF, CORS, DNS rebinding, MCP tool cancellation)”. And those fixes target exactly the coaxed-fetch exposure. But hardened isn’t the same as “put it on the open internet.”

Is llama.cpp 1.0 a new model? No. It’s an inference-library release, not a new foundation model. So the version bump concerns the software underneath your models rather than the models themselves.

Is upgrading worth it this week?

If llama-server is reachable from other machines, yes. If you call the C API directly, audit first and then bump. Otherwise pin and upgrade on your own schedule.

That’s the entire point of having a contract.

Local inference doesn’t mature through keynote demos.

It matures when the boring layer underneath gets a version contract, a security pass.

And a cleanup of everything it promised to remove, and llama.cpp 1.0 did all three on November 13, 2026.

Pin your version, audit your API calls, and give your next private workload a local home.