Skip to main content

Module template_caps

Module template_caps 

Source
Expand description

llama-server’s per-template capability self-report, and the tri-state gglib holds it in.

ADR 0007’s observation: the pinned build computes, per loaded chat template, a chat_template_caps structure (jinja::caps, common/jinja/caps.h) by executing the template with instrumented variable access, and publishes the result unconditionally on GET /props. gglib reads that self-report rather than building a detector of its own — a gglib reimplementation could only ever disagree with the renderer it is trying to predict, and every disagreement would be a bug on gglib’s side by construction.

§A report, not a conservative baseline

Five of the nine bools default true upstream (caps.h:11-14,23), so an absent field must never be read as false — which is why every field here is Option<bool> and none carries a #[serde(default)]-to-false. On the measured pinned build (b1-10bf611) the distinction never arises on the wire: all nine keys are serialized verbatim with explicit true/false on every config, including the no-template fallback. The Option exists for the build where that stops holding.

§The tri-state is never collapsed

TemplateCapsState mirrors BaselineState in gglib-proxy’s props module: “nobody has read it yet”, “the read failed, and here is why”, and “here is what was read” are three different facts, and collapsing the first two into the third’s negative is exactly how unknown starts to gate (ADR 0007, Consequences). reasoning_effort_support applies the same rule one level down: a caps object whose field is absent answers Support::Unknown, never Support::No.

Structs§

TemplateCaps
The nine bools of chat_template_caps, as GET /props reports them.

Enums§

Support
One capability’s answer, with unknown kept distinct from no.
TemplateCapsState
What gglib currently holds about a model’s template caps.

Functions§

reasoning_effort_support
Whether a model’s template reads reasoning_effort, from its recorded caps.