chat_template.jinja diverges from encoding_k3.py on every tool-declaring conversation (repro + fix)
Thanks for getting a K3 template up this fast, it's currently the only one on the Hub, which is also why I went looking at it closely: whatever lands here is what the GGUF conversions will carry.
K3 is unusual in that equivalence is checkable rather than arguable. encoding_k3.py is stdlib-only and side-effect free, so it can be imported and driven directly as an oracle, with no weights and no GPU. Diffing this template against it:
unsloth/Kimi-K3@105c5bb3184f/chat_template.jinja
sha256 9f91ca7aa32898b566b522dd64a2f771f6abb173431b67bf39e8ddb8ffc10b45
conversations that declare tools: 0/1176 byte-exact
conversations without tools: 419/824 byte-exact
49 ChatLint conversation shapes: 134/296 byte-exact
Reproduce it in one command, the script fetches this exact revision, so it does not depend on my copy of anything:
git clone https://github.com/dimondevceo/ChatLint && cd ChatLint
pip install -e .
HF_TOKEN=... python findings/kimi-k3/compare_hub.py --repo unsloth/Kimi-K3
The tool declaration difference is bigger than it looks
The header calls the key order and separator differences cosmetic, and that's fair as a statement about JSON. But the declaration block is prompt text: with any tool declared, the token sequence differs from what apply_chat_template produces. That is 0/1176 above, and for an agent workload it's every request.
deep_sort_dict + separators=(",", ":") is reproducible in Jinja as tojson(sort_keys=true, separators=(',', ':')) — json.dumps(sort_keys=True) sorts nested dicts recursively, so that one call covers the deep sort. Note that minja (llama.cpp) accepts neither keyword, so if this template is also meant to survive GGUF conversion it needs the sorting done manually over dictsort. There's a worked version of that in the file I mention at the end.
Three differences the header doesn't mention
1. Parallel tool results returned out of call order are attached to the wrong tool. This is the one I'd prioritise.
{"role": "assistant", "tool_calls": [
{"id": "a", "type": "function", "function": {"name": "get_weather", "arguments": {"city": "Zurich"}}},
{"id": "b", "type": "function", "function": {"name": "get_time", "arguments": {"tz": "CET"}}}]},
{"role": "tool", "tool_call_id": "b", "content": "14:00"}, # b finished first
{"role": "tool", "tool_call_id": "a", "content": "18C"},
reference: <|open|>message role="tool" tool="get_weather" index="1"<|sep|>18C
this file: <|open|>message role="tool" tool="get_weather" index="1"<|sep|>14:00
normalize_xtml_tool_result_messages matches each run of consecutive tool messages to the most recent preceding assistant tool_calls by tool_call_id, sorts the run into call order, and takes each result's tool from the matched call. Here the names and indices follow the rendered position but the contents stay in arrival order, so the labels and the payloads come apart and the model reads the clock's answer as the weather tool's. Results arriving in completion order rather than call order is the normal case whenever tool calls are executed concurrently.
One subtlety worth preserving: the reference reorders a run only if every message in it matches by id. A partially matched run is left exactly as it came in.
2. An explicit name on a tool message overrides the matched call.
assistant calls get_weather as call_1; tool message replies to call_1 with name="search"
reference: role="tool" tool="get_weather"
this file: role="tool" tool="search"
This one is deliberate upstream... encoding_k3.py says the matched call is authoritative precisely so that "an explicit (and possibly stale) tool/name" cannot drift out of sync with the reordered position.
3. Whitespace-only reasoning reaches the think channel.
{"role": "assistant", "reasoning_content": " ", "content": "hi"}
reference: <|open|>think<|sep|><|close|>think<|sep|>
this file: <|open|>think<|sep|> <|close|>think<|sep|>
Offer
I have a template that is byte-exact against encoding_k3.py, 24000 randomised conversations, 1176/1176 with tools, plus 29 scalar JSON encodings, and separately verified under minja by a compiled llama.cpp engine so one file covers both stacks:
https://github.com/dimondevceo/ChatLint/blob/main/findings/kimi-k3/chat_template.jinja
It's yours if you want it wholesale; no attribution needed and I'll open it as a second PR here on request. Or take the four fixes above into this file if you'd rather keep your own... happy either way, I just don't want the GGUFs to inherit this.
Verification for whichever you pick, same script, same probes:
python findings/kimi-k3/compare_hub.py --local path/to/chat_template.jinja