llama.cpp v1.0.0 lands: stable APIs, CPU-only builds, a thinking-model trap

The 1.0 label is less about new features than about a promise: from now on, breaking changes to the public C API bump the major version, feature additions bump the minor, and bug fixes bump the patch. Before this, llama.cpp versions were commit numbers like b12359, which told dependent app developers nothing about compatibility. The cleanup that came with the release — removing 35 deprecated functions and options such as llama_set_warmup and --defrag-thold — means apps leaning on the old API need to migrate now.

The hands-on test paints a practical picture. On a shared 8GB Linux machine with no GPU and only 1–2GB of free memory, the build completed in 11 minutes 45 seconds, llama-server was listening about 1.6 seconds after loading the model, and the OpenAI-compatible endpoints returned JSON. Generation ran at roughly 12–15 tokens per second for the 0.8B–1B models, with memory peaking near 971MiB for Qwen3.5-0.8B and 937–960MiB for Gemma-3-1b-it — model file plus roughly 400MB of overhead, which suggests a 7B-class model at about 4–5GB could fit on an 8GB PC, though the test machine could not try it.

The clearest caution is Qwen3.5-0.8B, a thinking model that spends its token budget on reasoning. With -n 256 it answered the France capital question in English, but with -n 64 it ran out; for the Japanese capital question it exhausted the budget at both 256 and 512 tokens, looping on the same sentence without answering. Adding /no_think did not stop the reasoning either — the model reasoned about the instruction itself and hit the 128-token limit. The test could not isolate whether the model or the chat template is at fault, and notes that llama.cpp's own reasoning controls, such as --reasoning-format, were not tested.