serve: carry Kimi K3 tool-call structure on the shared codec instead of the text channel

[JustVugg]

serve: carry Kimi K3 tool-call structure on the shared codec instead of the text channel

Corrected scope. This issue originally proposed doing GLM and Kimi K3 together. That was wrong, and checking the two engines rather than assuming they were symmetric is what showed it:

• Kimi K3: <|open|>, <|close|>, <|sep|>, <|end_of_msg|> are real special tokens — chat_special() resolves them to ids held in sp[0..3] (kimi_k3.c:2126, :2203). The engine therefore knows whether a structural marker was generated by the model or merely looks like one.
• GLM: <tool_call> does not appear in colibri.c at all. The markers are ordinary text rendered into the prompt and recovered by parse_tool_calls in openai_server.py. The engine has no ground truth to preserve, so a sideband would carry nothing better than the text already does. GLM's exposure is inherent to its format and can only be narrowed in the parser, which _unclosed_tail already does for the lenient path.

So: K3 only.

What it would fix. #1144 ships K3 tool calling with the structural run re-emitted as literal text for the gateway to pattern-match (option (a) from #1143). That discards a distinction the engine holds: a user prompt that gets the model to echo <|open|>call tool="…"<|sep|> as ordinary characters is, downstream, indistinguishable from a real call. The gateway reports tool_calls and never executes — the client application decides what to run — so this is a trust-boundary weakness rather than code execution, but a client acting on our tool_calls field is acting on a statement of fact we would be getting wrong.

Why the codec makes this cheap. c/serve_codec.h owns both directions since the framing migration finished (#1087, #1090, #1096, #1116), each engine landed behind a byte-exact wire-transcript freeze, and Inkling already rides an engine-specific structured payload on it (audio, as an opaque extension). A tool-call record is the same shape: one file, one new record type, an existing test that proves nothing else moved.

Not urgent, and not user-visible. The wire between engine and gateway is internal; the OpenAI tool_calls contract clients see is identical either way, so this can land whenever without a migration for anyone.

Context: #1143 (design), #1144 (implementation), #1029 (original gap).

[JustVugg]

Rewrote the scope above. The original version proposed doing GLM and K3 together, and that was wrong: I checked the two engines instead of assuming they were symmetric, and they are not. K3's delimiters are real special tokens the engine resolves to ids; GLM's <tool_call> does not exist in colibri.c at all and is pure text handled in Python. A sideband gives GLM nothing, because its engine has no ground truth to carry.

This also removes one of the three reasons I gave for merging #1144 rather than holding for the sideband. I argued, among other things, that doing K3 specially would leave the gateway maintaining two mechanisms until GLM followed — but GLM cannot follow, structurally, so that concern was empty. The merge still stands on the two reasons that survive verification: the gateway reports tool_calls rather than executing them, and the engine-to-gateway wire is internal, so moving K3 to a record later breaks nothing for anyone. Worth stating plainly rather than leaving a bad argument on the record.

[ZacharyZcR]

Completed by #1226 (, implementation commit ). Current emits an authoritative zero-byte declaration for K3 chat, routes only engine-proven special-token structure through the TOOL sideband, and keeps marker-looking DATA as ordinary content. Revalidated today: serve codec, Kimi framing, K3 chat tools, and all 155 tests pass.

[ZacharyZcR]

This is completed by #1226 (merge 613ebe6, implementation 798d55a). Current dev emits an authoritative zero-byte TOOL declaration for K3 chat, routes only engine-proven special-token structure through the TOOL sideband, and keeps marker-looking DATA as ordinary content. Revalidated today: serve codec, Kimi framing, K3 chat tools, and all 155 openai_server.py tests pass. The issue remains open only because this account does not have CloseIssue permission on the upstream repository.

[JustVugg]

Completed by #1226 (merge 613ebe6, implementation 798d55a), on main and in v1.9.0.

K3 tool calls now travel as engine-proven special-token structure on the shared codec sideband, with an authoritative zero-byte TOOL declaration for chat, instead of being reconstructed from the text channel. Text stays the text channel.

Thanks to @bherald for taking this one from the description to a working implementation.