Qwen3.8-27B brevity chat templates

These are drop-in chat templates for Qwen3.8-27B that tell the model to keep its final answer short. Only the template changes, so no weights are included. They work with any GGUF of the model through llama.cpp's --chat-template-file.

llama-server -m Qwen3.8-27B-<quant>.gguf --jinja --chat-template-file chat_template_brief.jinja

Why a template instead of a system prompt

llama-server has no flag for a server-side system prompt. Many harnesses also send their own system message, so you can't inject one there. The fork appends a single instruction to the template's reasoning_instructions, which the stock template renders before the client's (merged) system message. The harness's system prompt is kept, and the brevity line reaches all four branches (tools / no tools × system / no system).

Measurements

Setup: Qwen3.8-27B UD-IQ3_XXS on llama.cpp, on an M2 MacBook Air with 16 GB. There is one task: "Write a complete Python implementation of a doubly linked list with insert, delete, search, and reverse methods. Include docstrings and a small demo in __main__." Each cell has 1–3 runs. These are directional results, not a benchmark. Token counts are used because timing on this machine is too noisy to compare.

reasoning_effort=low, temp 0.6:

At this effort level, brief removes the prose (the 286 is its one permitted caveat line) and leaves thinking in stock's range. It cuts the code by about 1.3×. Total tokens fall within stock's run-to-run spread, so any token saving here is too small to see. brief_v1 cuts ~2.4× but gets there partly by writing about half as much code.

reasoning_effort=xhigh, temp 1.0 (the model card's sampling):

At xhigh the scoping in brief does not stop the instruction from reaching the reasoning. The model thinks briefly, then writes a complete implementation. On this task that is at least a 6× reduction in output. Whether the shorter thinking ever costs quality on harder tasks has not been benchmarked (see the note on daily use below).

Daily use. brief at xhigh / temp 1.0 / top_p 0.95 / top_k 20 has been the author's everyday agentic-coding configuration for about two weeks, with no quality regression noticed. That is anecdotal, not a controlled comparison.

Other findings:

• Capping max_tokens does not do the same thing. A cap truncates. At 800 tokens the answer was cut off mid-statement with finish_reason: "length" and an unclosed code fence. To get shorter answers, instruct for them and keep max_tokens only as a backstop against runaway output.
• The same idea as a system prompt (not these template files) cut a coding turn from 3152 to 752 tokens (4.2×). In a multi-turn PR-review session it went from 61.7 to 50.9 min (−17.5%) at an identical decode speed, so the entire saving was ~22% fewer tokens. It still made the same catch.

Notes

• reasoning_effort in the stock template has branches only for xhigh (with high mapped to it) and low. medium injects nothing.
• For coding, the setup above used temp 0.6. Temp ≤ 0.3 at xhigh circled without converging to an answer.

License

Apache-2.0, the same as the base model. LICENSE is copied verbatim from Qwen/Qwen3.8-27B. The template is derived from Qwen's original and includes fixes by Unsloth.