Name and Version
b10236
Operating systems
Linux
Which llama.cpp modules do you know to be affected?
libllama (jinja caps), llama-server
Problem description & steps to reproduce
minja doesn't support numeric dotted attribute access (x.0); Jinja2 treats it as x[0]. A template using it makes the caps probe throw, and caps_get then returns all capabilities false rather than keeping what the successful probes found.
GLM-5.3-Flash's template uses x.0 in 4 places, which gives two symptoms with one cause: /props shows supports_tools: false (also reported in #27754, no reply), and any request with tools returns Unable to generate parser for this template.
Repro, no weights:
cmake -B build -DGGML_CUDA=OFF -DLLAMA_BUILD_SERVER=OFF -DLLAMA_CURL=OFF
cmake --build build --target llama-template-analysis -j
./build/bin/llama-template-analysis --template-file GLM-5.3-Flash.jinja
supports_tools, supports_tool_calls, supports_parallel_tool_calls and supports_string_content all come back false. Changing only .0. → [0]. (4 occurrences) flips all four to true. GLM-4.7-Flash.jinja is in-tree, has no x.0, and passes.
Once supports_object_arguments is false, func_args_not_string() never runs in chat.cpp, so tool arguments stay a JSON string and the autoparser dies calling .items() on it — that's the line in the error, but it isn't the cause. supports_string_content: false is the giveaway that this isn't tools-specific.
No template in models/templates/ uses ident.0., so this looks untested. Fix is either parsing x.0 as x[0], or not discarding inferred caps when one probe throws.
First Bad Commit
Not bisected; GLM-5.3-Flash support is itself unmerged (#27754).
Relevant log output
Unable to generate parser for this template. Automatic parser generation failed:
While executing CallExpression at line 163, column 57 in source:
...c.arguments %}{% for k, v in _args.items() %}<arg_key>{{ k }}</arg_key>...
Name and Version
b10236
Operating systems
Linux
Which llama.cpp modules do you know to be affected?
libllama (jinja caps), llama-server
Problem description & steps to reproduce
minja doesn't support numeric dotted attribute access (
x.0); Jinja2 treats it asx[0]. A template using it makes the caps probe throw, andcaps_getthen returns all capabilities false rather than keeping what the successful probes found.GLM-5.3-Flash's template uses
x.0in 4 places, which gives two symptoms with one cause:/propsshowssupports_tools: false(also reported in #27754, no reply), and any request withtoolsreturnsUnable to generate parser for this template.Repro, no weights:
supports_tools,supports_tool_calls,supports_parallel_tool_callsandsupports_string_contentall come back false. Changing only.0.→[0].(4 occurrences) flips all four to true. GLM-4.7-Flash.jinja is in-tree, has nox.0, and passes.Once
supports_object_argumentsis false,func_args_not_string()never runs in chat.cpp, so tool arguments stay a JSON string and the autoparser dies calling.items()on it — that's the line in the error, but it isn't the cause.supports_string_content: falseis the giveaway that this isn't tools-specific.No template in
models/templates/usesident.0., so this looks untested. Fix is either parsingx.0asx[0], or not discarding inferred caps when one probe throws.First Bad Commit
Not bisected; GLM-5.3-Flash support is itself unmerged (#27754).
Relevant log output