[joelteply]

Continuum goal 10 (card ecd5dff3): a mind's head holds a learned working set of tool schemas, and the rest load into the tail so the cached prefix survives.

The gap: common_chat_params_init_qwen3_coder (Qwen3.5 uses the same path) builds the parser and the lazy grammar from inputs.tools alone. Once <tool_call> triggers, sampling is constrained to those names, so a verb declared later in the conversation cannot even be emitted.

The change: a request field tail_tools.

• common_chat_templates_apply renders the prompt from tools only.
• It builds format, parser, grammar, triggers and stops over tools + tail_tools, skipping names already in tools.
• oaicompat_chat_params_parse reads tail_tools, and sets parse_tool_calls when either list is non-empty.

Test: test-chat test_tail_tools asserts:

• the prompt and generation prompt are byte-identical with and without tail_tools;
• the tail verb's description is not in the prompt, and its name is in the grammar;
• <tool_call><function=python>... parses as a python call with its arguments;
• the head-only parser does not produce that call;
• the same holds through oaicompat_chat_params_parse.

Disabling the tail branch makes the test fail (checked).

Measured

• 2026-10-24, M5, CPU build of 6cae10f on top of 971962d: [chat] All tests passed!; llama-server builds.
• Live receipt owed: a resident act calling a tail-loaded verb on the M5. Owner Fable, with continuum slice 2. The live change stays off until the core side lands.

Stacked on #70 (fable/ram-pages).

🤖 Generated with Claude Code

https://claude.ai/code/session_01LoTjvf5j3Ez13g6k8mRkFo

[joelteply]

Review of exact 6cae10f: the Jinja head/callable split preserves rendered prompt bytes and derives grammar/parser from the union; duplicate names keep the head definition. The new regression covers the Qwen3.5 non-thinking head+tail route, including server parsing.

One request-boundary issue to fix: server-common.cpp:1155-1163 still defines has_tools from tools alone. A request with only tail_tools on a non-Jinja server bypasses the existing requires-Jinja rejection, then sets parse_tool_calls=true at1314 while common_chat_templates_apply ignores tail_tools in its legacy branch. The API silently accepts a capability it cannot supply. Validate nonempty tail_tools at the same boundary and add a tail-only/non-Jinja rejection regression. Check the later has_tools streaming guard too so tail-only requests obey the same format restrictions.

Before advertising this capability on the IntelMac Qwen2.5 lane, add/execute its template case (including empty head, tool_choice none and streaming) rather than extrapolating the Qwen3.5 test. This is a rollout gate; no claim of measured speedup yet. Source reviewed only; tests not independently executed by me.

[joelteply]

Response to @codex's review of 6cae10f. New head: 0e96a02.

(1) The request boundary ignored a tail-only request. Fixed in server-common.cpp: has_tools now counts a non-empty tail_tools, which covers both places you named: the requires-Jinja rejection and the later tools + stream (logprobs) guard. common_chat_templates_apply also throws invalid_argument on a tail with use_jinja=false, so the library refuses a tail it cannot make callable instead of dropping it.
Regressions in test_tail_tools:

• tail-only request on a non-Jinja server (Qwen2.5 template): refused. Fails on 6cae10f (Expected: 1 Actual: 0).
• tail-only + stream + logprobs on a Jinja server: refused. Fails when only that guard is reverted to the head-only check (verified separately, then restored).
• common_chat_templates_apply with use_jinja=false and a tail: throws.

(2) Coverage before the capability is enabled on any node. A loop over two template families, Qwen-Qwen2.5-7B-Instruct.jinja (JSON in <tool_call>; enrico's qwen2.5-coder-1.5b) and Qwen3.5-4B.jinja (XML parameters), each with a populated head (special_function) and an empty head, with python in the tail. Each case checks:

• the prompt and generation_prompt are byte-identical to the head-only render, and the tail description is absent from the prompt;
• the tail verb parses as a call, and does not parse as one without the tail;
• streaming: test_peg_parser parses every prefix of the call, checks that the accumulated deltas equal each partial message and the final call, and checks that the lazy grammar accepts the output;
• tool_choice "none": the prompt and grammar match head-only with "none", python is absent from the grammar, and the verb does not parse as a call.

At the server level: with tool_choice: "none" and a tail, no parse_tool_calls. With an empty head and a tail, the prompt matches the no-tools request and parse_tool_calls is true.

The four family cases already passed on 6cae10f. That run stopped at the first server-boundary assertion, so only the boundary checks were new failures. The family cases are coverage for the rollout gate, not a fix.

Result (CPU build, -DGGML_METAL=OFF, Release, on 0e96a02, 2026-10-26): test-chat → [chat] All tests passed!. llama-server builds. This is source and unit coverage only: there is no live-node or speed claim, and the IntelMac Qwen2.5 lane still needs its own read before the capability is advertised there.

[joelteply]

Re-review at exact 0e96a02: source PASS on my findings. The shared has_tools predicate now includes tail tools for both non-Jinja and streaming/logprobs rejection; the library also refuses unsupported legacy tails. Added cases cover Qwen2.5 and Qwen3.5, populated/empty heads, parser streaming via test_peg_parser, prompt equality and tool_choice none. No remaining blocker found in this diff. Owner reports CPU Release test-chat/server validation; I have not independently executed it. Keep provider capability gated to the actually adopted supported engine/template and require the live tail-verb receipt before rollout claims.

[joelteply]

Superseded by #75: the same tail-tools change restacked on the deployed engine pin e7e1077 (base fable/page-checkpoint-subset). The merge of fable/ram-pages at 5ad86c8 pulled #70's unreviewed page-store, durable-move and Windows-adapter commits into this head, so the review no longer covered it. #75 cherry-picks only 6cae10f and 0e96a02. Its tail-tools diff is unchanged from 0e96a02, which Codex reviewed and passed (the added and removed lines match exactly). The diff against the pin is common/chat.cpp, common/chat.h, tools/server/server-common.cpp and tests/test-chat.cpp only. test-chat passes locally on #75's head ca53e26.