froggeric-template-trial

froggeric/Qwen-Fixed-Chat-Templates (chat_template_froggeric.jinja, v22.4,

Apache-2.0) — a "universal" drop-in Jinja chat template for Qwen 3.5/3.6/3.8

archs, evaluated 2026-08-26. REJECTED WITHOUT LOADING ANY MODEL. Decision was

the user's after a content review showed it is not clearly better than what the

box already runs.

What it is: a *maximal rewrite*, not a minimal patch. It does fix the

non-first-system raise_exception('System message must be at the beginning.')

guard (renders any-position system as its own ChatML turn — the box's #1 Qwen

gotcha, [[jinja-system-guard-tool-parser]]) and pre-opens inspect after

assistant (matches the qwen3-thinking streaming fix at templates/

qwen3-thinking-2507.jinja). Then it ADDS, unprompted: reasoning_effort steering

(default medium, vs Qwen3.8's shipped xhigh), <|think_on/off/xhigh|>

control tokens parsed from message text, tool_call_format selection (default

xml), a ~400-char <IMPORTANT> tool-call instruction block every tool turn,

consecutive-tool-failure escalation (injects "⚠️ SYSTEM WARNING" after 1-2

errors), max_tool_arg_chars/max_tool_response_chars truncation, multi-format

reasoning extraction (inspect/<thinking>/etc.), preserve_reasoning

toggles, auto_disable_thinking_with_tools. Audio content is NOT handled —

render_content raises 'Unexpected item type' on anything but image/video/text.

Why rejected (the load-bearing reasons):

1. The one real bug it fixes, the box already fixed — surgically and proven.

Per-model patches (chat-templates/qwen35moe-nonfirst-system-256k.jinja,

fable-711-256k.jinja, qwen3.8-27b-nonfirst-system.jinja, bonsai-256k.jinja,

templates/qwen3-thinking-2507.jinja) are byte-identical to the stock template

except the single guard line, and they are validated by the grill corpus.

Froggeric's headline feature is redundant here.

2. Most unpatched models never had the bug. Per [[jinja-system-guard-tool-parser]]

the embedded templates of qwen3-coder-next, qwen3-vl-30b and the MTP qwen3.6

variants are CLEAN (merge system messages, no guard) — they run with no

--chat-template-file at all. For them froggeric only adds overhead + risk.

3. Tool-format mismatch — the biggest concrete risk. Froggeric defaults to

xml (<function=>/<parameter=>), matching the qwen3_coder parser

(qwen3-coder, qwen38-awq, qwen38-mtp, qwen36-35b, bonsai-awq, fable-711-gptq,

thinkingcap) but MISMATCHING the hermes parser models (qwen3-vl-thinking,

qwen3-vision, qwen3vl, qwen3-thinking, qwen3-instruct, omni), whose trained/

repo template instructs JSON-in-<special> (confirmed in qwen3-thinking-2507.jinja).

Apply froggeric default → template says <function=> → model may follow it →

hermes returns tool_calls: null. A manufactured regression. A fair hermes test

needs tool_call_format=json via --chat-template-kwargs; llama.cpp HAS the

flag, vLLM 0.26.0 --help | grep chat-template returned NOTHING — support

unconfirmed, so hermes models may be untestable on vLLM at all.

4. It invalidates the grill corpus. Every published score was measured with

the CURRENT template; switching means none describe the served model until

re-grilled. A smoke battery catches gross breakage, not quality drift (n=1,

[[single-run-scores-are-unreliable]]).

5. Smaller risks: omni breaks on audio input; ~400 chars/turn tool bloat on a

bandwidth-bound box tuned for token efficiency (MTP/draft acceptance); the

effort-default shift is mostly neutral on qwen38 (we already set

--chat-template-kwargs '{"reasoning_effort":"medium"}').

How to apply: do NOT install froggeric on llama-swap.yaml. If it is revisited,

the only honest path is a *focused pilot* with per-model tool_call_format (json

for hermes, xml for qwen3_coder), not a blanket apply — and re-grill, not just

smoke. The repo stays on disk at chat_template_froggeric.jinja (root) should it

ever be wanted. Distinct from the per-model minimal patches, which stay. See

[[jinja-system-guard-tool-parser]], [[grill-does-not-validate-real-use]],

[[single-run-scores-are-unreliable]].