In this article
Empty visible content does not prove no generation occurred. Validate output limits and length termination alongside model semantics and usage.
A short output limit can produce a surprising combination: successful HTTP status, empty content and finish_reason set to length. A handler requiring nonempty text for every valid response may classify this as transport failure. Reasoning models can spend the budget differently from client expectations. Providers should test limit meaning, termination shape and accounting as related but separate properties.
Establish the limit’s scope
The OpenRouter parameter documentation notes that max_tokens covers reasoning and visible output together on most relevant providers. It also describes length with empty content under a small budget. This documents a particular external interface rather than establishing identical support for every model.
Your service contract should identify the parameter name, unit and scope. Do not equate max_tokens with maximum context length. One limits output, while the other concerns the broader model resource and prepared input.
Separate text from performed work
The API usage fields include total completion counts and optional details. Visible text is only the observable portion of a result. Retokenizing content therefore may not recover all work counted by the engine.
Do not add detail counts to totals without defining inclusion. State whether reasoning is part of overall output or a separate quantity in the chosen implementation. A missing field does not establish zero consumption, particularly across response versions.
Build a budget ladder
Choose one short synthetic input and several bounded output limits. Preserve model, revision, other parameters and warmup conditions. At every step record HTTP outcome, finish_reason, text presence and usage. Do not select settings based on one attractive response.
The ladder values are experiment settings rather than recommended commercial limits. Stop when the total test budget is reached or the result is sufficiently clear. This is a small contract check, not an exhaustive model-load study.
Classify different outcomes
Empty content with length should be interpreted under the declared model semantics. Validation rejection before generation belongs to another branch. An SSE truncation without final completion cannot be explained by the same rule merely because the client also saw no text.
Include an ordinary stop fixture and an invalid-parameter rejection fixture. They verify that the classifier does not accept every empty result as legitimate budget exhaustion. Preserve the original envelope; its fields matter more than a convenient message generated by a client library.
Check application interpretation
Applications should distinguish an exhausted budget, incomplete delivery and an unsupported capability. Automatically repeating the same request with the same small limit can simply reproduce the outcome. Increasing the budget also needs an explicit decision rather than secretly bypassing the stated constraint.
Related guides cover usage accounting and max-model-len. They explain different boundaries: work counters and context capacity. A technical result matching documentation does not establish integration approval or future request traffic.