Module runtime_capabilities 

What the engine underneath gglib can do — the mirror of GgufCapabilities.

gglib has always had rich detection for what a model can do: GGUF metadata drives capability flags, which drive launch flags and request shaping. It has had none for what llama-server can do. The version was read at install time, printed to the console, and discarded.

That gap is why compensation accumulates. Every behaviour gglib applies to work around a llama.cpp limitation — dialect normalization, grammar origination, reasoning-tag stripping — is hardcoded as unconditionally on, because there has never been a way to ask is this still needed?. Upstream ships the fix, gglib keeps compensating, and nobody finds out.

RuntimeCapabilities closes that loop: probe the binary once, record what it is, and let a capability be a question with an answer rather than an assumption baked into a call site.

Unknown means gglib compensates

A version string this module cannot parse yields RuntimeCapabilities::unknown — no build number, no flags — and every compensation stays on. This is the same discipline ModelContext::catalog_resolved applies to models: an empty capability set means nobody knows, not the feature is absent, and the safe response to not knowing is to keep doing the work ourselves. Deferring to native behaviour on a runtime we failed to identify would trade a known cost for an unknown risk.

Resolved once, held for the run

A probe result is taken when a server is launched and held for that process’s lifetime. Nothing re-probes mid-request, and nothing switches strategy mid-stream: a request that starts under one set of capabilities finishes under the same set.

This is deliberate. Hot-swapping parsing or constraint strategy partway through a response — on the evidence of a residue hit, say — would make failures depend on when within a stream the evidence arrived, which is precisely the class of bug that cannot be reproduced from a recording. The observation layer’s job is to log divergence between what a runtime claimed and what it delivered. Acting on that log is a deliberate change to a threshold in this module, made between runs with the evidence in hand — not an automatic reaction inside one.

Adding a capability

1. Add a const MIN_BUILD_* with a doc comment citing the upstream release, PR, or issue that establishes the build.
2. Add the matching RuntimeFlags bit.
3. Set it in RuntimeCapabilities::from_build.
4. Add a test pinning both sides of the threshold.

Note what step 4 buys: the threshold is the claim, and the test is what stops it drifting into folklore.

Structs

RuntimeCapabilities

What the llama-server binary underneath gglib is, and what it can do.

RuntimeFlags

Capabilities of the llama-server binary gglib is running against.

Constants

MIN_BUILD_PEG_NATIVE_TOOL_CALLS 🔒

First llama.cpp build whose PEG-native chat parser handles delimited (“constructed”) tool-call dialects — the XML-style envelopes gglib’s own DelimitedToolCallParser was written for — natively.

MIN_PLAUSIBLE_BUILD 🔒

Smallest build number treated as a real llama.cpp release.

Functions

leading_number 🔒

The leading run of ASCII digits in s, parsed.

parse_build_number 🔒

Extract the llama.cpp build number from a --version banner.

parse_commit 🔒

Extract the commit sha from a --version banner.

version_line 🔒

The most informative single line of a version banner.