There is a failure mode in local reasoning models that no availability dashboard will ever show you. The server accepts the request, streams tokens, returns HTTP 200 — and the user receives nothing, because every token the model produced was reasoning, and the budget ran out before the first character of the actual answer. We call a request that ends this way an answerless request, and we measure it as a first-class outcome: an empty answer is a failure that stays in the denominator.
How often it actually happens
On Qwen3.6-35B-A3B with reasoning enabled and a 1024-token completion budget, the share of everyday requests that came back answerless was 58.3% of requestsunit_replicated on the human-task corpus — messages, emails, explanations, plans. On the older self-referential benchmark corpus the same cell produced 75.0% of requestsrepeated. More than half of ordinary requests, silently unanswered, while the server reported success on every one of them.
A second model family reproduces the mechanism. Gemma-4-26B in its default operating mode returned 8.3% of requestsrepeated of requests answerless — a far lower rate, but nonzero, on a model whose chat template does not even expose a reasoning toggle. This is not one model’s quirk; it is what happens whenever a thinking pass and a token budget share one completion window.
Why your dashboard says everything is fine
Every conventional serving metric looks healthy while this happens:
- HTTP status is 200 — the request completed.
- TTFT is excellent: Gemma-4’s first token of any output arrived at a median of 282msrepeated. But that token is reasoning, not answer — the first token of the actual answer arrived at 10768msrepeated, and on the answerless share it never arrived at all.
- Tokens generated is high — the model worked hard. It just spent the entire budget on text the user never asked to read.
The only metric that catches it is one almost nobody collects: answer tokens — tokens after the reasoning block closes. That is why our harness counts TTFA separately from TTFT and treats an empty answer as a failed request even when the transport succeeded.
What to do about it
- Budget for the reasoning, not just the answer. A 1024-token window that would fit any answer in our corpus fits almost no reasoning-plus-answer pair. The failure rate is a budget-starvation curve, not a model defect.
- Or turn reasoning off for everyday traffic. On the same box, disabling the reasoning block cut the first-answer wait from tens of seconds to 210msunit_replicated with task success unchanged on these workloads — see the reasoning cost comparison.
- Monitor answer tokens. If your serving stack cannot tell reasoning
tokens from answer tokens, you cannot see this failure.
usagefields that merge them hide it.
Limits
- Two model families, one box (Strix Halo, llama.cpp Vulkan pinned by digest), frozen corpora, single stream. Rates are properties of the model × budget × corpus cell, not universal constants.
- The mechanism claim — reasoning consumes the shared budget before any answer token — is verified per-request in the public quality records: every answerless request shows nonzero reasoning characters and zero answer characters.
- We did not measure vendor-hosted APIs; their budget handling differs.
Every number above has a permanent page with scope, limitations and sealed run evidence — the claim registry. The term is defined in the glossary.