The input fits the context window, so why does the answer stop early?
An accepted input only shows that the request did not immediately exceed its input limit; it does not guarantee enough room for the answer. Read the service's stop reason first, then distinguish an output cap, a stop string and a network interruption.
Start troubleshooting here
An accepted input only shows that the request did not immediately exceed its input limit; it does not guarantee enough room for the answer. Read the service's stop reason first, then distinguish an output cap, a stop string and a network interruption. For local Transformers, check max_new_tokens and the compatibility parameter max_length rather than treating the context window as the output allowance.
Distinguish a length limit from an interrupted response
Use this process when a long report stops halfway through, JSON lacks its final bracket, or a task repeatedly ends at a similar length. Save the complete request and raw response, including system instructions and conversation history. A visible character count is not necessarily the token count: tool descriptions and text assembled by the application may also consume input space.
Check input and output budgets separately
First confirm that the response has ended rather than the front end still waiting for its final chunk. If the service reports a length limit, record input and actual output tokens separately and check the requested output budget. For a normal stop, check whether a stop string occurred in the answer. Similar parameter names from different providers are not automatically interchangeable.
Reproduce the cutoff by changing only the output budget
Keep the original input and change only the output allowance for the same short task, then compare the cutoff. If the required input and output together approach the available window, remove irrelevant history or generate report sections with a shared outline. In Transformers, max_new_tokens limits only newly generated tokens; check another runtime's definitions before applying the same configuration.
Verify completeness and the actual stop reason
Retest the original cutoff case. Check that all required sections are covered, structured output parses completely, and the final stop reason is recorded. A longer answer is only an intermediate observation: confirm that essential material is present and the latter part is not filled with repetition.
There is no single length limit for every service. Available budgets vary by model version, reasoning mode and product allowance; thinking tokens may also consume the output budget. Without raw response records, you can establish that visible text is incomplete but cannot precisely attribute the failure to a model limit. Front-end and network failures remain possible.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.