thinking stream starts immediately — it is just not addressed to the user

What you see

A reasoning model behind a streaming chat endpoint. The first token arrives at once, but what streams is the reasoning block. The reply begins much later; on a small token budget it often never begins, and the request ends with a success status and an empty answer field. The two reports put the observable in three sentences:

thinking stream starts immediately — it is just not addressed to the user
The user watches tokens stream for that entire time — they are the model thinking out loud, not the reply.
the caller gets HTTP 200 and an empty string

Where we saw it

• Beelink GTR9 Pro (Ryzen AI Max+ 395, Radeon 8060S / gfx1151, 128 GB unified); llama.cpp server-vulkan-b9049, pinned by image digest; Qwen3.6-35B-A3B Q4_K_M from ggml-org, hash-verified.
• Workload interactive-assistant-v1 @ 2026-08-02, frozen EN and RU prompts; concurrency 1, context 8192, temperature 0, prompt cache off.
• Three settings: reasoning on at a 1024-token budget, on at 4096, off via the chat template at 1024. Timing client-side; server timings would have hidden the effect.
• Reasoning-cost report published 2026-08-20: a second interactive corpus plus a strict-JSON workload, same hardware, runtime and artifact; the exact runtime build, model digest and unit count are on the claim pages it links.

Cause

The model writes a reasoning block before the answer and the stream starts with it, so the first token of anything lands at the same moment whether the box answers at once or never. The answer’s first token comes only after the block ends. Below the budget the reasoning pass needs, it eats the whole budget before the answer begins and the endpoint returns success with an empty answer, which a status-code check records as a success. Server-side timing hides all of it.

Fix

Clock time to first answer token, client-side. Time to first token of anything is not a usable number for a reasoning model.

Count empty answers as failures, in the error rate and in the denominator of every latency statistic. The token budget is a correctness setting; if reasoning stays on, budget for the pass.

Switch reasoning off where the workload allows. On our box it was disabled via the chat template; the source pages name the setting, not the flag. Verify against the running server, not the docs: ask it what template and settings it resolved, then send one request and check whether a reasoning block appears. Off, the answer started with the stream and still passed the language and repetition gates; the word-budget gate failed in every setting, on or off, which the report attributes to the model’s verbosity, not the toggle. On everyday chat and strict-JSON automation reasoning bought nothing our gates could detect; hard multi-step problems are outside our corpora, untested by us.

Still open upstream?

Not tracked by us. The source pages name no upstream issue; the fault is in the metric, not the runtime.

Evidence

• Time-to-first-token does not describe a thinking model — client-side timing, per-request records.
• Should you turn thinking off? — the on/off trade and the verification check.
• Thinking vs no-thinking, side by side — named by the second report.
• Run bundles: botAGI/agmind-lab; values re-derived by queries in the claim registry.