HTTP 200, empty answer

What you see

The request completes. The server streams tokens and returns a success status. The client gets no answer text at all. The report names the symptom in its title:

HTTP 200, empty answer

In the per-request quality records every such request has the same shape:

nonzero reasoning characters and zero answer characters

Every conventional serving metric looks healthy while it happens. Status is 200. Time to first token is excellent, because the first token is reasoning. Tokens generated is high, because the model did work. The only counter that catches it is answer tokens, the ones after the reasoning block closes, and almost nobody collects it. A usage field that merges the two hides the failure.

Where we saw it

Strix Halo, llama.cpp Vulkan pinned by digest, single stream, frozen corpora. Two model families reproduced it: Qwen3.6-35B-A3B with reasoning enabled at a 1024-token completion budget, and Gemma-4-26B in its default operating mode, on a chat template that does not even expose a reasoning toggle. Report published 2026-08-14. The exact runtime build and model digest are on the claim pages linked below.

Cause

A thinking pass and a token budget share one completion window. When the model emits a reasoning block, it writes that block before the answer. When the budget runs out before the reasoning block closes, generation stops and no answer token is ever produced. The transport succeeded, so the server reports success. The report calls the failure rate a budget-starvation curve rather than a model defect: the rate is a property of the model × budget × corpus cell.

Fix

The report gives two settings and one check, no command line:

• 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.” Size the completion budget for the pair.
• Or turn reasoning off for everyday traffic. On the Strix Halo box, disabling the reasoning block cut the first-answer wait from tens of seconds to the value on the claim page, with task success unchanged on these workloads. The paired cells are in the reasoning cost comparison.
• Monitor answer tokens. Count tokens after the reasoning block closes and treat an empty answer as a failed request even when the transport succeeded. That is why our harness counts TTFA separately from TTFT and keeps answerless requests in the denominator.

Still open upstream?

Not tracked by us. Neither source names an upstream issue; the report files the failure rate under budget starvation, not a runtime or model defect.

Evidence

• Report: HTTP 200, empty answer: the failure mode your monitoring cannot see
• Glossary: answerless request
• Claim pages: Qwen3.6 answerless share at the tested budget, Gemma-4 answerless share in default mode
• Per-request quality records: botAGI/agmind-lab
• Related configuration: Strix Halo × llama.cpp Vulkan × Qwen3.6-35B-A3B
• Related symptom: thinking stream starts immediately, the answer comes late or never