llama.cpp v0.2.0 Makes Stable and Nightly Different Promises
llama.cpp now has semantic releases beside nightly builds. Its first stable tag shares code with a build tag, showing that channel names describe policy rather than quality.
llama.cpp has spent years shipping build-number tags almost as quickly as its code changes. On August 21, the project added a second track: the v0.2.0 release begins a consistent semantic-versioning line for slower, stable releases, while b[NUM] tags remain the fast nightly or development channel.
That does not make every local-inference upgrade safe. It gives downstream teams a clearer version to pin—and a deliberate choice when a newer GPU, model, or performance fix exists only in a nightly build.
Use a vX.Y.Z release when reproducibility and downstream compatibility matter more than the latest change. Use a b[NUM] build when a specific, verified commit is required for your hardware or workload. Pin the exact tag and commit in both cases, verify any downloaded binary, and run the same smoke test before promotion.
Stable and nightly are two release policies, not quality grades
The new tag names describe cadence and audience. llama.cpp’s release says stable vX.Y.Z tags arrive more slowly and are recommended for downstream distribution and casual users. The existing b[NUM] tags are created on or near most commits, expose current functionality sooner, and may be less stable.
The project’s more detailed release and versioning policy adds an important packaging boundary. A stable llama.cpp tag is cut when its internal copy of ggml matches a released ggml version. That lets a downstream distributor build llama.cpp against a system-installed ggml with a defined compatibility point. Nightly builds continue to use llama.cpp’s internal development copy, which can diverge from the separately released library.
This is already more than a naming exercise. Homebrew switched its llama.cpp formula to the v0.2.0 tag and exact commit, builds with development mode off, and links against the packaged system ggml. The same formula retains master as its opt-in head build. Stable and current development therefore coexist as different dependency choices.
| Question | Choose stable vX.Y.Z |
Choose nightly b[NUM] |
|---|---|---|
| What forces the upgrade? | A planned maintenance window or supported release policy | A named model, backend, driver, security, or regression fix absent from stable |
| How much change can the team absorb? | A reviewed release delta on a slower cadence | An exact commit delta, with faster follow-up changes possible |
How is ggml consumed? |
A system library or downstream package benefits from the release compatibility point | The build carries llama.cpp's current internal ggml copy |
| What evidence is required? | Release notes plus workload and packaging tests | The motivating pull request or commit plus the same full test gate |
| What gets recorded? | Semantic tag, full commit, artifact digest, build flags, backend, and model revision | Build tag, full commit, artifact digest, build flags, backend, and model revision |
| What is the rollback? | The previous accepted semantic release and its artifacts | The last accepted nightly or stable baseline, kept separately from the candidate |
A nightly is not automatically faster, and stable is not a claim that all regressions are gone. The labels say how the code was selected and released. Performance and correctness still depend on the model, quantization, backend, compiler, driver, hardware, prompt mix, context length, and server settings.
v0.2.0 and b10566 point to the same code, but serve different jobs
The first stable release exposes a useful wrinkle. The v0.2.0 and b10566 tags both resolve to commit bb4caa7540188872173c44d161602d9271386413. The stable page establishes the semantic release and links to nightly b10566; the b10566 release carries the prebuilt macOS, Linux, Android, Windows, and iOS artifacts for that commit.
That distinction changes what should be pinned:
- A downstream source build or package should identify
v0.2.0and its full commit. The tag communicates the stable release contract. - A team consuming one of the project’s prebuilt archives should record
b10566, the exact filename, and its digest because those binaries live on the build-tag release. - A later nightly should not be described as “v0.2.0 plus fixes” without examining its exact commit range. By August 24 in Jakarta, the repository had already published b10603 at a different commit.
The release notes also show why version-level performance promises would be misleading. The v0.2.0 change range contains backend, server, model-support, memory, build, and release-engineering work. Some changes are specific to Metal, SYCL, OpenCL, Vulkan, CUDA, or particular model architectures; others are reverts. No single speed number can summarize that mixture.
Verify provenance before testing performance
The b10566 binary release links to a GitHub artifact attestation and publishes SHA-256 digests for its files. An artifact attestation is a signed statement connecting an artifact to its source repository and build workflow. GitHub’s attestation documentation is explicit about the limit: provenance helps establish where and how an artifact was built; it does not prove that the code is secure or regression-free.
Download only the exact platform archive from the project’s release page, then verify it before extraction. With a current GitHub CLI, the documented command shape is:
gh attestation verify ./llama-b10566-bin-ubuntu-x64.tar.gz \
--repo ggml-org/llama.cppThe GitHub CLI reference explains the verification policy and output. A successful result should be stored with the deployment record alongside the expected repository, artifact filename, SHA-256 digest, tag, and commit. A failed or absent verification is a stop condition, not a reason to retry with an untracked mirror.
Pinning only master, latest, head, or a package manager’s moving channel makes a later incident harder to reconstruct. A tag is better, while the exact commit identifies the source independently of the channel name.
Stable and nightly answer different maintenance needs
The unusual v0.2.0 and b10566 pairing makes the distinction concrete: the tags point to the same source commit, but the semantic release communicates a stability contract while the build tag carries the downloadable artifacts. A later nightly may contain a needed backend or model fix, but it also moves away from the exact code the stable release selected.
That makes “stable versus nightly” a maintenance decision, not a benchmark conclusion. The model, quantization, hardware, backend, context, and workload can dominate performance, while provenance can only establish where an artifact came from—not that it is secure or regression-free.
The most useful signal from llama.cpp’s new release policy is therefore organizational: downstream users finally have a semantic anchor without losing access to fast-moving builds. Whether that anchor is the right deployment still depends on the capability or fix a specific workload requires.