Ask a reasoning model a simple question with a tight output limit and it will sometimes return nothing at all. Not an error, not a refusal. An empty response, billed in full. We hit this in production, went looking for the cause, and found that 107 of the 456 models currently on OpenRouter cannot be told to stop reasoning.
What is actually happening
Reasoning models spend tokens thinking before they answer. That budget comes out of the same allowance as the reply. Give a model a 20-token ceiling and ask it something that triggers a chain of thought, and it can spend all 20 tokens reasoning and have nothing left to say.
From the outside this looks like the model broke. It did not. It did exactly what it was told, in a configuration that made a visible answer impossible.
We reproduced this deliberately while adding models. Probing five new releases with a 20-token cap, every one returned an empty string. Given 400 tokens and the same prompt, all five answered normally and well. The models were fine; the test was wrong.
reasoning.mandatory, meaning the endpoint rejects a request that tries to disable reasoning. On these models, "just turn thinking off to save tokens" is not an available option. Sending effort: 'none' returns a 400 and fails the whole call.
Why this bites hardest on the retry path
The obvious fix for a blank response is to retry with reasoning turned down. That is what we built, and on nearly a quarter of the catalogue it makes things worse: the retry is rejected outright, so a recoverable blank becomes a hard failure.
Worse, the failure is silent in the place you would look. The model appears in the catalogue, it accepts ordinary requests, and it only breaks on the specific path you added to handle breakage. We had one model in this state for eighteen days before an audit caught it, and nothing in our error monitoring flagged it, because the failures were being handled as ordinary blank responses.
If you run any kind of blank-response fallback, check whether your models accept the override before you ship it. The catalogue publishes this, so it is one API call to find out rather than a guess.
Practical rules
Give reasoning models room
A hard output cap under a few hundred tokens is a trap on a reasoning model. If you need short answers, ask for short answers in the prompt rather than enforcing it with the token limit. The limit truncates the thinking; the instruction shapes the reply.
Do not benchmark with tiny caps
A smoke test that sends "say OK" with a 20-token ceiling will report reasoning models as broken. We nearly shipped exactly that conclusion. If you are testing whether a model works, give it enough room to think and then answer.
Check the flag rather than assuming
Whether reasoning can be disabled varies by model and changes between versions. It is published per endpoint. Read it rather than inferring it from the model family, because siblings differ.
Expect the effort levels to differ too
Among models that mandate reasoning, the lowest available setting is not the same everywhere. Some accept a minimal level, others floor at low. If you are lowering effort to control cost, the floor is per-model.
The cost angle nobody mentions
Reasoning tokens are billed as output tokens. A model that thinks for 1,000 tokens before writing a 200-token answer bills you for 1,200 tokens of output, and you see 200 tokens of value.
That is not a scandal, it is how these models work, and the thinking is usually what you are paying for. But it does mean per-token price comparisons between a reasoning model and a non-reasoning one are misleading. The reasoning model's effective cost per useful word is higher than its rate card suggests, sometimes several times higher.
It is also why we price usage on measured tokens rather than a flat per-message rate. A flat rate has to assume the worst case, which means quiet users subsidise heavy ones.
Frequently Asked Questions
How do I know if a model mandates reasoning?
The OpenRouter model endpoint publishes a reasoning object with a mandatory flag and the effort levels the endpoint supports. Query it rather than relying on documentation or on the model's family, because it varies between siblings and between versions of the same model.
Is a blank response my fault or the model's?
Usually the configuration. The most common causes are an output limit too small for the model to think and answer within, or a prompt long enough that reasoning consumes the remaining budget. Try the same prompt with a much larger limit before concluding the model is at fault.
Does this affect me if I only use chat interfaces?
Less, because a decent interface sets sane limits for you. It still shows up as an occasional empty or truncated answer on hard questions. On Deepest we surface a plain-language note when a model returns nothing, rather than showing you an empty panel and leaving you to guess, because an empty box is indistinguishable from a model that had nothing to say.
