llama.cpp and ggml Hit v1.0.0: Semantic Versioning, 36 Removed C API Symbols and a llama-server That Refuses Unsafe Setups
llama.cpp and ggml v1.0.0 promise major-version bumps for breaking C API changes, remove deprecated symbols and --defrag-thold, add FP8 KV caches, and make llama-server refuse unauthenticated tools on network addresses.
The ggml-org maintainers tagged llama.cpp v1.0.0 and ggml v1.0.0 on November 13, 2026. The number matters less than the promise behind it. In the Hugging Face announcement, the team says that from now on both libraries “will reflect API and ABI incompatibilities with major-version bumps.” The same release also removes a batch of deprecated APIs, and its llama-server now refuses some configurations the previous build only warned about.
If you link libllama, maintain bindings, or run llama-server behind a local coding agent, this is an upgrade to plan rather than one to pull blind.

What the 1.0 promise covers
The announcement sets out the rules that now apply to ggml-org projects:
| Bump | Trigger |
|---|---|
| MAJOR | Breaking change to the public C API in ./include |
| MINOR | Backward-compatible feature, backend update, model support or API addition |
| PATCH | Bug fix with no API change |
The maintainers explain the change by pointing to adoption: “many downstream applications already depend on our work,” and a stable API is now “paramount.” Tbreak’s coverage adds a useful caution. The 1.0 tag is a promise to developers, and none of the sources says it changes any app people use today.
The nightly bNNNNN builds keep shipping alongside the stable tags. The GitHub releases page shows v1.0.0 marked Latest, with b12362 through b12373 pre-releases published later the same day. ComputingForGeeks found that the v1.0.0 release ships no binaries of its own. It contains only a nightly-tag.txt file, which pointed to build b12359. That binary reports 1.0.0-dev, so confirm the build number and commit rather than the version string.
The breaking changes
The v1.0.0 release notes list these API changes:
llama_set_warmup, 35 deprecated functions, thedefrag_tholdfield and the--defrag-tholdflag are removed (#30565).- The NextN speculative-decoding API moves from
llama-ext.hintollama.h, andllama_set_embd_state_srcis renamedllama_set_ctx_state_src. moe_cache_sizeandmoe_cache_cpu_shareare added tollama_context_params.clip.his removed, and its functionality is consolidated into mtmd.
ComputingForGeeks compared the v1.0.0 build with v0.9.0 and measured the effects. The libllama soname changed from libllama.so.0 to libllama.so.1, and exported llama_* functions dropped from 255 to 237. The net drop is 18, but 36 symbols were removed, because the NextN API and the renamed function were added back to the export list. The tester found that the old functions have long-standing replacements, such as llama_model_load_from_file and llama_init_from_model. llama_set_warmup has no replacement. Because old bindings fail with an undefined symbol at build or load time, you find out at startup, not through wrong output.
The flag removal will cause the most trouble for anyone running llama-server as a service. On 1.0, --defrag-thold exits with error: invalid argument, where the old build only logged a deprecation warning. ComputingForGeeks also found that the LLAMA_ARG_DEFRAG_THOLD environment variable is silently ignored. A compose file that sets the variable keeps working, but a systemd unit that passes the flag will crash-loop on its next restart.
# Before swapping binaries: find the removed flag in units, compose files and wrappers
grep -rnE -- '(-dt |--defrag-thold)' /etc/systemd/system ~/compose ~/bin 2>/dev/null
# After unpacking: confirm the soname your bindings must target
readelf -d ./libllama.so | grep SONAME
llama-server security now fails closed
For anyone exposing llama-server to agents, the server changes matter more. The release notes list fixes for --cors-origins, DNS rebinding, SSRF through the CORS proxy, and access to child instances. They also restrict HF_TOKEN to huggingface.co hosts and cancel MCP tool calls when a client disconnects or times out. Two new opt-in flags, --allow-unauthenticated-tools and --media-allow-private-urls, show what the server now refuses by default.
ComputingForGeeks confirmed both refusals:
- Tools on a network address without a key. Starting with
--host 0.0.0.0 --tools allnow exits, and the error message offers three fixes: set--api-key, bind to 127.0.0.1, or pass--allow-unauthenticated-tools. The tester noted that the exposed tool list includesexec_shell_commandandwrite_file. An API key is the right fix for nearly every LAN setup. - Private media URLs. An
image_urlthat points to 127.0.0.1 now returns HTTP 400 with “host is not a public address.” Vision pipelines that pull images from an internal store need--media-allow-private-urls, but that flag reopens the SSRF exposure for every caller.
The tester also notes that the web UI’s CORS proxy is now limited to public addresses with no opt-out. If you pointed its MCP proxy at a LAN server, expect it to stop working.
If you run a local model behind a coding agent, see our llama-server remote access guide. An SSH tunnel or a tailnet keeps the server on loopback, which avoids both the refusal and the exposure.
New capabilities, and a CPU caveat
The release adds OCP FP8 KV caches (-ctk f8_e4m3 -ctv f8_e4m3), a host-memory MoE expert cache with a configurable CPU share for cache misses, external PLE shard loading, an OpenAI-compatible /v1/audio/speech endpoint, new model architectures and a redesigned web UI.
ComputingForGeeks measured the FP8 cache with Gemma 3 1B at a 32K context. The KV cache took 91.5 MiB, against 183 MiB for f16 and 97 MiB for q8_0. On a GPU-less EPYC VM, though, an FP8 V cache made prompt processing roughly 2.9 to 3.3 times slower. The tester recommends q8_0 for CPU-only boxes and treats FP8 as a GPU feature. That is one VM and one small model, so benchmark your own hardware before changing any defaults. Our llama-server flags guide covers how to prove which cache type actually loaded.
Upgrade checklist
| Step | Why |
|---|---|
Resolve the tag through nightly-tag.txt and record the build number |
The binary reports 1.0.0-dev |
| Unpack to a new directory | Each archive ships many shared libraries |
Remove -dt/--defrag-thold |
Passing it is now a fatal error |
Add --api-key where tools or MCP run on a non-loopback address |
The server otherwise refuses to start |
| Test vision clients that use private image URLs | They now get HTTP 400 |
Upgrade bindings built for libllama.so.0 |
The soname and 36 symbols changed |
After this, the tag track and the nightly track mean different things. Services other people depend on can pin vX.Y.Z and treat a major bump as the signal to rework integrations. Anyone who follows nightlies for new architectures still has no API guarantee between two bNNNNN builds. If you handled the earlier v0.7.0 port change, the same rule applies: read the release notes before you restart the service.