finish_reason
A field in LLM API responses that identifies the reason a model stopped generating output. Common values include natural completion (stop/end_turn), length truncation (length/max_tokens), and content filtering (content_filter/SAFETY), allowing callers to determine whether the model completed its output normally.
Core Facts
Timeline (last 90 days)
Finish reason (finish_reason/stop_reason) is a model response metadata field indicating why generation ended: normal completion, reaching the max_tokens limit, triggering content filtering, or a tool call request, etc.
If finish_reason is length while the client still treats the content as a complete answer, this falls under the truncation_ambiguity failure classification.
Checking response integrity should verify both that finish_reason is stop and that the key data structure matches expectations (e.g., items is a non-empty list).
Common values of the finish_reason field include stop (natural end) and length (truncated upon reaching the maximum token count).
Production routing logic should not look only at the HTTP status code, but should also check whether finish_reason and content are non-empty, and treat finish_reason of length with empty content as a hard failure rather than a parseable result.
Streaming output combined with incremental validation can trigger an immediate alert or retry upon detecting finish_reason: length, without having to wait for the entire response to return.
A finish_reason value of length or MAX_TOKENS means the model was forcibly interrupted rather than concluding on its own.
Author Serguey Asael Shinder recommends reading the stop reason after every LLM call, just as one would read an HTTP status code.
finish_reason should be logged together with call costs and plotted on the same monitoring dashboard to improve observability.
Only responses with a finish_reason of stop or tool_calls should be cached; responses truncated by length or those that errored should not be cached.
2 more timeline events
All Facts (12)
A finish_reason value of length or MAX_TOKENS means the model was forcibly interrupted rather than concluding on its own.
65%VerifiedOpenAI's API uses the finish_reason field, with values including stop, length, content_filter, and others.
65%UnverifiedFinish reason (finish_reason/stop_reason) is a model response metadata field indicating why generation ended: normal completion, reaching the max_tokens limit, triggering content filtering, or a tool call request, etc.
50%UnverifiedIf finish_reason is length while the client still treats the content as a complete answer, this falls under the truncation_ambiguity failure classification.
50%UnverifiedCommon values of the finish_reason field include stop (natural end) and length (truncated upon reaching the maximum token count).
50%UnverifiedChecking response integrity should verify both that finish_reason is stop and that the key data structure matches expectations (e.g., items is a non-empty list).
50%UnverifiedProduction routing logic should not look only at the HTTP status code, but should also check whether finish_reason and content are non-empty, and treat finish_reason of length with empty content as a hard failure rather than a parseable result.
50%UnverifiedStreaming output combined with incremental validation can trigger an immediate alert or retry upon detecting finish_reason: length, without having to wait for the entire response to return.
50%UnverifiedAuthor Serguey Asael Shinder recommends reading the stop reason after every LLM call, just as one would read an HTTP status code.
50%Unverifiedfinish_reason should be logged together with call costs and plotted on the same monitoring dashboard to improve observability.
50%UnverifiedOnly responses with a finish_reason of stop or tool_calls should be cached; responses truncated by length or those that errored should not be cached.
50%UnverifiedWhen large language model APIs return responses, they typically include a finish_reason field with common values including stop, length, and tool_calls.
50%