An empty completion is a failure, not an answer

Most model-chain failures are loud. A rate limit returns 429, a bad request returns 400, a dead endpoint times out. The chain sees the error, rotates to the next arm, and the pipeline carries on. The failure that does damage is the quiet one: the provider returns HTTP 200, a well-formed JSON body, and an empty string where the answer should be.

What we measured

On 29 August 2026 we ran one of our production prompts through nineteen free-tier model arms on a 36-point scoring battery, three repeats each. The same model at the same reasoning effort scored 16.7 of 36 with a 8,192-token completion budget and 30.0 of 36 at 32,768. Nothing about the prompt changed. The low score was not weaker reasoning; it was completions that returned finish_reason: length with content: "", because the model’s hidden reasoning is drawn from the same budget as the visible answer and the budget ran out before the answer started.

The next day a 550-billion-parameter arm returned HTTP 200 with empty content on 15 of 15 long-form calls at the full 32,768 budget, with zero HTTP errors, while answering a shorter prompt perfectly. A floor on the budget is necessary. It is not sufficient.

Why chains get this wrong

A fallback chain is usually written as “try arm A; on error, try arm B”. An empty string is not an error to the HTTP client, so the chain treats it as success, stops rotating, and passes "" downstream. The parser fails on the empty input, or worse, a lenient parser returns a default and the pipeline publishes a blank.

The rule we build to

1. Treat an empty or whitespace-only completion as a chain-level failure. Rotate exactly as you would on a 5xx.
2. Set the completion budget floor at 32,768 tokens for any arm that reasons before it answers. The budget is a cap, not a cost: arms that do not reason pay nothing for the headroom.
3. Cap per model where the provider hard-fails on an over-budget request instead of clamping it, or a blanket floor silently darkens that arm.
4. Log the empty as its own failure class, separate from timeouts and rate limits, so the ranking in the next note can see it.

A green response code is a transport fact. Whether you got an answer is a content fact, and the chain has to check it.