The ggml-org team released llama.cpp v1.0.0 and ggml v1.0.0 on November 13, 2026, formalizing how the projects will signal breaking changes. For developers building local AI products, the main change is a compatibility policy: major versions will identify API and ABI incompatibilities, minor versions will add backward-compatible functionality, and patch versions will cover fixes without API changes. The team outlined the rules in its official announcement.
The first upgrade deserves attention. The v1.0.0 release notes remove deprecated functions, move the NextN speculative-decoding API into the main public header, and rename an interface. An application that still uses those older entry points may need changes before it builds against 1.0.
The milestone concerns the inference software used to run models. llama.cpp provides a portable C/C++ inference stack, while ggml supplies its underlying tensor-computation engine. Their compatibility rules matter to applications, language bindings and packages that depend on those layers.
What Major, Minor and Patch Mean
The announcement defines the following rules for ggml-org projects using semantic versioning:
| Version component | Published rule | Practical consequence |
|---|---|---|
| Major | Breaking changes to the public C API in ./include | Plan for integration changes and a compatibility review. |
| Minor | Backward-compatible features, backend updates, model support or API additions | Existing public API use should remain compatible, but new functionality still needs validation. |
| Patch | Bug fixes without an API change | Expect the same API surface, while checking relevant behavior fixes. |
The team separately states that both llama.cpp and ggml will reflect API and ABI incompatibilities through major-version bumps. Its release table identifies libllama and libggml, alongside their respective public-header directories. These are the interfaces downstream consumers should watch. The announcement makes that scope important.
API compatibility concerns the source-level contract: function names, declarations and the types an application compiles against. ABI compatibility concerns the compiled interface between binaries, including exported symbols and data layouts. A wrapper can therefore encounter trouble during compilation, while an already-built application can encounter trouble when loading or using a replacement shared library.
I’d treat this as an improvement to dependency planning. A visible major-version boundary gives maintainers a reason to schedule migration work instead of discovering an interface change during a routine dependency refresh.
The policy’s scope also deserves care. Public C-library compatibility is one layer of a complete deployment. Command-line arguments, server configuration, model behavior and application-specific workflows still need their own checks. A compatible library interface cannot tell a packager whether every surrounding integration behaves as expected.
The 1.0 Migration Starts With Removed Interfaces
The release notes identify several changes worth checking before enabling new features:
- Deprecated functions are removed. The API-change list names
llama_set_warmupand 35 deprecated functions. - Defragmentation settings disappear. The release removes
defrag_tholdand the--defrag-tholdcommand-line option. - NextN moves into the main public header. Its API is promoted from
llama-ext.htollama.h. - A state-related function is renamed.
llama_set_embd_state_srcbecomesllama_set_ctx_state_src. - Multimodal integration loses an older header. The release removes
clip.hand consolidates model and subcontext infrastructure intomtmd.
These changes are documented in the GitHub release notes. They create several distinct migration tasks, even though they arrive under one version number.
Function removals can affect direct C/C++ callers and bindings that declare or resolve those functions. Header changes can affect include paths and generated bindings. A removed CLI option can affect a launch script even when the application itself never links to libllama.
The NextN change deserves particular attention in wrappers that expose speculative decoding. Check both the header dependency and the renamed function reference. Updating one while leaving the other untouched can leave an integration only partially migrated.
These recommendations are analysis of the published documents, without independent code inspection or testing. The sources identify the changed interfaces, but they do not establish which third-party applications still depend on them.
FP8 and MoE Features Add Configuration Choices
Version 1.0 includes inference features alongside the compatibility work. The release notes add FP8 key-value caches, selectable with the f8_e4m3 cache type through -ctk and -ctv, with optional static per-tensor scales.
A key-value, or KV, cache stores attention data from previously processed tokens so generation can reuse it. Its representation matters because this stored state contributes to inference memory use. The new FP8 option gives integrators another cache-format choice; the release notes do not provide a controlled comparison showing a universal speed or quality improvement.
The release also adds a host-memory cache for mixture-of-experts model experts, with a configurable CPU share. The public llama_context_params structure gains moe_cache_size and moe_cache_cpu_share. The notes describe cache-replacement work and CPU handling for cache misses, making this a configuration area to evaluate against the intended model and hardware.
External PLE/engram data can also load from separate GGUF shards through --shard and --ple. These capabilities and controls are listed in the release notes.
For an existing product, I’d separate feature evaluation from the compatibility migration. First establish that the application builds, loads and completes its usual workflows. Then evaluate cache settings or additional model assets. That order makes it easier to distinguish an interface regression from a newly selected inference configuration.
Server Operators Have a Separate Upgrade Checklist
The server changes reach beyond the C headers. The release notes list fixes involving server-side request forgery, CORS, DNS rebinding and child-instance access. They also restrict HF_TOKEN use to huggingface.co hosts and add the --allow-unauthenticated-tools and --media-allow-private-urls opt-ins.
For Model Context Protocol integrations, llama-server now cancels tool calls when a client disconnects or times out and notifies the MCP server. It also gains an OpenAI-compatible /v1/audio/speech endpoint and a temperature option for /tts. These are documented in the server and API changes.
A successful library build will not exercise these deployment paths. Operators should check browser access, remote media retrieval, authentication, tool cancellation and audio requests wherever their application uses them.
Frequently Asked Questions
4 questions
1Does llama.cpp 1.0 Introduce a New Model?
The milestone is a library release and versioning commitment. Its release notes also add support for several model architectures, alongside inference, server and interface changes.
