A user message whose content is an empty mapping renders as empty content in the official
encoder: _render_content_segments iterates `for part in content`, which for {} is zero iterations.
Any non-empty mapping iterates its keys instead and dies on part["type"]. The template rejected
every mapping, so it refused a request the model's own encoder accepts.
Found by scoring the template against a 1451 case corpus built independently of our own fixtures.
That corpus now reports 1409 exact, 0 mismatches, 40 cases where both implementations correctly
reject the input, and 2 remaining differences, both a deliberate decision: a schema dict with
mixed int and str keys makes CPython's json.dumps(sort_keys=True) raise TypeError, which is an
incidental sort crash rather than a validation rule, and cannot arrive over a JSON API where
object keys are always strings.
platform.kimi.ai documents reasoning_effort as K3's top-level Chat Completions field:
"supports low, high and max, with max as the default", and "when migrating from K2.x to K3,
remove the K2.x thinking configuration and use top-level reasoning_effort as needed".
The template previously read only thinking_effort, which is the name the local Python encoder
uses as a kwarg. A client following Moonshot's own documentation sends reasoning_effort, so every
such request silently ran at max with no way to lower it.
Behaviour now:
- reasoning_effort low, high or max is honoured.
- thinking_effort wins if both are supplied, so nothing that worked before changes.
- reasoning_effort none disables thinking, matching what llama.cpp already does with that value
in tools/server/server-common.cpp before the template runs.
- values K3 does not define, such as OpenAI's medium and minimal, fall back to the default rather
than raising, since they arrive in a foreign namespace. The encoder's own thi…
The rendered output is unchanged: this template is byte-identical to the previous one on
every input tested (227 fixtures under transformers' jinja environment, the same sweep through
llama.cpp's engine, and a separate 1189 case corpus, all producing identical bytes before and
after).
Only the Jinja comments are gone. 60 comment blocks removed, 33389 characters down to 24534.
Comments are not free in this file: it is embedded in GGUF metadata and in tokenizer_config.json,
and llama.cpp's common_chat_try_specialized_template substring matches the raw template source
including comments when it picks a per model handler.
A four line header remains, recording the two deliberate differences from the Python reference
that exist for llama.cpp compatibility.
Update chat_template.jinja to match the official encoder
The previous template diverged from tokenization_kimi.TikTokenTokenizer.apply_chat_template
for every conversation that declares tools, and in several other places.
This version is verified byte for byte against apply_chat_template (not against the lower level
build_chat_segments, which sits below the thinking_effort and image_prompts defaults). Coverage:
227 fixtures under transformers' own jinja environment plus the same sweep through llama.cpp's
engine via llama-server /apply-template, and a separate 1189 case corpus.
What changed:
- tool and response schema JSON is now recursively key sorted with compact separators, so the
prompt bytes match. This alone accounted for every tools conversation differing.
- parallel tool result runs are reordered by tool_call_id, and a matched assistant call now
overrides a stale name on the result message.
- whitespace only reasoning content renders an empty think body instead of leaking through.
- JSON string tool arguments are decoded and re…
